KR20100089005A - Transmitting/receiving system and method of processing data in the transmitting/receiving system - Google Patents

Abstract

PURPOSE: A transmitting/receiving system and method of processing data in a transmitting/receiving system are provided to efficiently perform channel setting by using signaling information. CONSTITUTION: A different FIC(Fast Information Channel) chunk major protocol version from a received broadcasting signal extracts a signaled FIC segments. The number of the corresponding FIC segment, the number of the last FIC segment, the FIC chunk major protocol version information are obtained from each segment header. The FIC chunk including signaling information between the ensemble and the mobile service is restored from the FIC segments.

Description

Transmitting / receiving system and method of processing data in the transmitting / receiving system}

The present invention relates to a transmission / reception system and a data processing method for transmitting and receiving digital broadcasting.

In the digital broadcasting, VSB (Vestigial Sideband) transmission method adopted as a digital broadcasting standard in North America and Korea is a single carrier method, so the reception performance of the receiving system may be degraded in a poor channel environment. In particular, in the case of a portable or mobile broadcast receiver, since the robustness against channel change and noise is further required, when the mobile service data is transmitted through the VSB transmission method, the reception performance is further deteriorated.

Accordingly, an object of the present invention is to provide a digital broadcast transmission / reception system and a data processing method that are resistant to channel changes and noise.

Another object of the present invention is to provide a transmission / reception system and a data processing method for efficiently performing channel setup using signaling information.

Still another object of the present invention is to provide a transmission / reception system and a data processing method for efficiently performing channel setup using a fast information channel (FIC).

In order to achieve the above object, a receiving system according to an embodiment of the present invention may include a receiving unit, a first processing unit, and a second processing unit. The transmission frame according to the present invention consists of a plurality of subframes for receiving at least one ensemble and at least one mobile service, and one subframe consists of a plurality of slots. The receiver receives a broadcast signal including mobile service data and an FIC segment from the at least one slot. The first processor extracts FIC segments signaled by different FIC chunk major protocol versions from the broadcast signal, and the number of the corresponding FIC segment, the number of the last FIC segment, and the FIC chunk major from each segment header of the extracted FIC segments. Obtain protocol version information. The second processor includes signaling information between an ensemble in the transport frame and a mobile service from the payload of the FIC segments based on the obtained number of the corresponding FIC segment, the number of the last FIC segment, and FIC chunk major protocol version information. Restores the FIC chunk.

In one embodiment, the FIC chunk major protocol version identical to the FIC chunk major protocol version configured in the receiving system recovers the FIC chunk from the payload of the FIC segments signaled.

The FIC chunk major protocol version information obtained from the segment header of the FIC segment used to recover the FIC chunk has the same value as the FIC major protocol version information allocated to the chunk header of the FIC chunk.

The FIC chunk consists of a 5 byte chunk header and a variable length chunk payload, and the chunk payload includes signaling information between the ensemble in the transport frame and the mobile service.

The FIC chunk is segmented into 35 bytes and allocated to the segment payload of each FIC segment and received.

The lowest FIC segment number is assigned to the FIC segment number of the segment header of the FIC segment containing the first byte of the FIC chunk.

Transmission parameter channel (TPC) data including identification information for identifying an update of the FIC chunk data structure may be extracted from the broadcast signal.

In the data processing method of the reception system according to an embodiment of the present invention, the transmission frame is composed of a plurality of subframes for receiving at least one ensemble and at least one mobile service, one subframe is a plurality of slots Receiving a broadcast signal comprising a mobile service data and an FIC segment from the at least one slot; Extract FIC segments signaled by different FIC chunk major protocol versions from the broadcast signal, and obtain the number of the corresponding FIC segment, the number of the last FIC segment, and the FIC chunk major protocol version information from each segment header of the extracted FIC segments. Doing; And an FIC chunk including signaling information between an ensemble in the transport frame and a mobile service from the payload of the FIC segments based on the obtained number of the corresponding FIC segment, the number of the last FIC segment, and the FIC chunk major protocol version information. And restoring.

Other objects, features and advantages of the present invention will become apparent from the following detailed description of embodiments taken in conjunction with the accompanying drawings.

According to the present invention, mapping information between an ensemble and a mobile service is signaled using an FIC chunk, and the FIC chunk is divided into FIC segments and transmitted through the FIC, thereby enabling fast service acquisition in a receiving system.

According to the present invention, a plurality of FIC segments divided from FIC chunks are transmitted through one subframe or transmitted through a plurality of subframes, so that the data of the FIC segments in which the data amount of the FIC chunk is transmitted through one subframe is transmitted. If less or more than one, the FIC segments can be prevented from being wasted.

The present invention transmits protocol version information of the FIC chunk corresponding to the FIC segment through the header of the FIC segment, so that even if the FIC chunks of different protocol versions coexist in one M / H frame, the receiving system can transmit the corresponding protocol version. FIC chunks can be accurately reconstructed using the FIC segments composed of

According to the present invention, by transmitting identification information for identifying whether signaling information transmitted in a payload of a corresponding FIC segment is signaling information of a current M / H frame or signaling information of a next M / H frame through a header of the FIC segment. Even if the FIC chunk signaling the ensemble configuration information of the current M / H frame and the FIC chunk signaling the ensemble information of the next M / H frame coexist in one M / H frame, the receiving system may determine the corresponding M / H frame. FIC segments can be used to accurately reconstruct FIC chunks.

In addition, the present invention has the advantage of being resistant to errors and compatible with existing receivers when transmitting mobile service data through a channel. The present invention has the advantage that the mobile service data can be received without error even in a ghost and noisy channel. The present invention can improve the reception performance of the reception system in an environment with a high channel change by inserting and transmitting known data in a specific position of the data area. In particular, the present invention is more effective when applied to portable and mobile receivers in which channel variation is severe and robustness to noise is required.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention that can specifically realize the above object will be described. At this time, the configuration and operation of the present invention shown in the drawings and described by it will be described as at least one embodiment, by which the technical spirit of the present invention and its core configuration and operation is not limited.

Definition of terms used in the present invention

The terms used in the present invention were selected as widely used general terms as possible in consideration of the functions in the present invention, but may vary according to the intention or custom of the person skilled in the art or the emergence of new technologies. In addition, in certain cases, there is a term arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the corresponding description of the invention. Therefore, it is intended that the terms used in the present invention should be defined based on the meanings of the terms and the general contents of the present invention rather than the names of the simple terms.

Among the terms used in the present invention, the main service data is data that can be received by the fixed receiving system and may include audio / video (A / V) data. That is, the main service data may include A / V data of a high definition (HD) or standard definition (SD) level, and may include various data for data broadcasting. Known data is data known in advance by an appointment of the transmitting / receiving side.

Among the terms used in the present invention, M / H (or MH) is the first letter of each of a mobile and a handheld, and is a concept opposite to a fixed form. The M / H service data includes at least one of mobile service data and handheld service data, and for convenience of description, the M / H service data may be referred to as mobile service data. That is, in the present invention, MH, M / H, and mobile are all used in the same meaning. In this case, the mobile service data may include not only M / H service data but also any service data indicating movement or portability, and thus the mobile service data will not be limited to the M / H service data.

The mobile service data defined as described above may be data having information such as a program execution file, stock information, or the like, or may be A / V data. In particular, the mobile service data may be A / V data having a smaller resolution and a smaller data rate than the main service data as service data for a portable or mobile terminal (or broadcast receiver). For example, if the A / V codec used for the existing main service is an MPEG-2 codec, the MPEG-4 codec that has better image compression efficiency as the A / V codec for mobile services. AVC (Advanced Video Coding), SVC (Scalable Video Coding), or the like may be used. In addition, any kind of data may be transmitted as the mobile service data. For example, TPEG (Transport Protocol Expert Group) data for broadcasting traffic information in real time may be transmitted as mobile service data.

In addition, data services using the mobile service data include weather services, transportation services, securities services, viewer participation quiz program, real-time polls, interactive educational broadcasting, game services, drama plot, characters, background music, shooting location, etc. Informational services, information on past sports history, profile and performance of athletes, and information on programs by media, time, or subject that enables product information and ordering. Etc., but the present invention is not limited thereto.

The transmission system of the present invention enables multiplexing of main service data and mobile service data on the same physical channel without any influence on receiving main service data from an existing receiving system.

The transmission system of the present invention performs additional encoding on mobile service data, and inserts and transmits data that is known in advance to both the transmitting and receiving sides, that is, known data.

When the transmission system according to the present invention is used, the reception system enables mobile reception of mobile service data, and also enables stable reception of mobile service data against various distortions and noises generated in a channel.

In addition, according to an embodiment of the present invention, the transmission / reception system operates two data channels. One data channel is an RS frame data channel for content transmission, and the other data channel is a fast information channel (FIC) for service acquisition.

That is, the present invention signals mapping information between an ensemble and a mobile service using an FIC chunk, and divides the FIC chunk into units of an FIC segment and transmits the information through an FIC, thereby enabling fast service acquisition in a receiving system.

According to the present invention, a plurality of FIC segments divided from FIC chunks are transmitted through one subframe or transmitted through a plurality of subframes, so that the data of the FIC segments in which the data amount of the FIC chunk is transmitted through one subframe is transmitted. If less or more, the amount of FIC segments can be reduced.

The present invention transmits protocol version information of the FIC chunk corresponding to the FIC segment through the header of the FIC segment, so that even if the FIC chunks of different protocol versions coexist in one M / H frame, the receiving system can transmit the corresponding protocol version. FIC chunks can be accurately reconstructed using the FIC segments composed of

According to the present invention, by transmitting identification information for identifying whether signaling information transmitted in a payload of a corresponding FIC segment is signaling information of a current M / H frame or signaling information of a next M / H frame through a header of the FIC segment. Even if the FIC chunk signaling the ensemble configuration information of the current M / H frame and the FIC chunk signaling the ensemble information of the next M / H frame coexist in one M / H frame, the receiving system may determine the corresponding M / H frame. FIC segments can be used to accurately reconstruct FIC chunks.

Receiving system

1 is a block diagram illustrating a configuration of a receiving system according to an embodiment of the present invention. In FIG. 1, a solid arrow indicates a data path and a dotted arrow indicates a control signal path.

The reception system of FIG. 1 includes an operation controller 100, a tuner 111, a demodulator 112, an equalizer 113, a known data detector 114, a block decoder 115, and a primary RS frame that control the entire system. The decoder 116 may include a secondary RS frame decoder 117, a signaling decoder 118, and a baseband controller 119. The receiving system may further include an FIC handler 121, a service manager 122, a service signaling handler 123, and a first storage unit 124. The receiving system may further include a primary RS frame buffer 131, a secondary RS frame buffer 132, and a transport packet (TP) handler 133. The receiving system includes an Internet Protocol (IP) datagram handler 141, a descrambler 142, a User Datagram Protocol (UDP) datagram handler 143, and a Real-time Transport Protocol / Real-time Transport Control (RTP / RTCP). Protocol datagram handler 144, NTP datagram handler 145, service protection stream handler 146, second storage 147, ALC / LCT / Asynchronous Layered Coding / The apparatus may further include a Layered Coding Transport stream handler 148, a decompressor 149, an Extensible Mark-up Language (XML) parser 150, and a Field Device Tool (FDT) handler 151. The receiving system may further include an A / V decoder 161, a file decoder 162, a third storage unit 163, a middleware engine 164, and an SG handler 165. The receiving system may further include an EPG manager 171, an application manager 172, and a user interface (UI) manager 173.

For convenience of description, the present invention includes the tuner 111, the demodulator 112, the equalizer 113, the known data detector 114, the block decoder 115, the primary RS frame decoder 116, and the secondary RS. The frame decoder 117, the signaling decoder 118, and the baseband controller 119 will be referred to as a baseband processor 110. The FIC handler 121, the service manager 122, and the service signaling handler ( 123 and the first storage unit 124 will be referred to as a service demultiplexer 120. In addition, the primary RS frame buffer 131, the secondary RS frame buffer 132, and the transport packet handler 133 will be referred to as an IP adaptation module 130, and the IP datagram handler 141 will be described. , Descrambler 142, UDP datagram handler 143, RTP / RTCP datagram handler 144, NTP datagram handler 145, service protection stream handler 146, second storage unit ( 147, an ALC / LCT stream handler 148, a decompressor 149, an XML parser 150, and an FDT handler 151 will be referred to as a common IP module 140. In addition, the A / V decoder 161, the file decoder 162, the third storage unit 163, the middleware engine 164, and the SG handler 165 will be referred to as an application module 160.

The terminology used in FIG. 1 is a general term that is widely used at present. However, in accordance with the emergence of a new technology, the terminology determined by the applicant in the present invention is arbitrarily used, and the meaning of the term is clearly explained in the description. Let's do it. Therefore, in the understanding of the present invention, it is intended that the present invention should be understood as the meaning of terms rather than simple names of terms.

In FIG. 1 configured as described above, the operation controller 119 controls the operation of each block of the baseband processor 110.

The tuner 111 tunes a reception system to a frequency of a specific physical channel (or physical transmission channel, PTC), thereby broadcasting main service data, which is a broadcast signal for a fixed broadcast reception device, and a broadcast for a mobile broadcast reception device. It serves to receive mobile service data which is a signal. At this time, the tuned frequency of the specific channel is down-converted to an intermediate frequency (IF) signal and output to the demodulator 112 and the known data detector 114. The passband digital IF signal output from the tuner 111 may include only main service data, only mobile service data, or may include both main service data and mobile service data.

The demodulator 112 performs automatic gain control, carrier recovery, and timing recovery on the digital IF signal of the passband input from the tuner 111 to form a baseband signal, and then the equalizer 113 and the known data detector ( 114). The demodulator 112 may improve demodulation performance by using a known data symbol string received from the known data detector 114 during timing restoration or carrier recovery.

The equalizer 113 compensates for the distortion on the channel included in the signal demodulated by the demodulator 112 and outputs the same to the block decoder 115. The equalizer 113 may improve equalization performance by using a known data symbol string received from the known data detector 114. In addition, the equalizer 113 may improve the equalization performance by receiving feedback of the decoding result of the block decoder 115.

The known data detector 114 detects the known data position inserted by the transmitting side from the input / output data of the demodulator 112, that is, the data before demodulation or the data of which the demodulation is partially performed, and the position along with the position information. The sequence of the known data generated in the subframe is output to the demodulator 112, the equalizer 113, and the operation controller 119. Also, the known data detector 114 outputs information to the block decoder 115 so that the block decoder 115 can distinguish the mobile service data that has been additionally encoded and the main service data that have not been further encoded at the transmitting side. .

The block decoder 115 is configured to perform data equalization after channel equalization in the equalizer 113 and to perform data transmission of both block encoding and trellis encoding of a serial concatenated convolution code (SCCC) scheme at a transmitting side (that is, an RS frame). My data, signaling data) performs trellis decoding and block decoding on the reverse side of the transmitting side, and if trellis encoding is performed without block encoding (ie, main service data), only trellis decoding is performed. Perform.

The signaling decoder 118 decodes the signaling data input after channel equalization in the equalizer 113. It is assumed that signaling data (or signaling information) input to the signaling decoder 118 is data in which both block encoding and trellis encoding are performed in the transmission system. Such signaling data may be, for example, Transmission Parameter Channel (TPC) data and Fast Information Channel (FIC) data. For example, the signaling decoder 118 performs recursive turbo decoding of parallel concatenated convolution code (PCCC) scheme on the data of the signaling information region among the input data, and then the FIC data and the TPC from the turbo decoded signaling data. Separate data. In addition, the signaling decoder 118 performs RS decoding on the separated TPC data in reverse to the transmitting side and outputs the RS to the operation controller 119. The signaling decoder 118 performs deinterleaving on the separated FIC data in subframe units, performs RS decoding on the reverse side of the transmitter, and outputs the decoded data to the FIC handler 121. The transmission unit of FIC data deinterleaved and RS decoded by the signaling decoder 118 and output to the FIC handler 121 is an FIC segment.

The FIC handler 121 receives FIC data from the signaling decoder 118 and extracts signaling information for service acquisition, that is, mapping information between an ensemble and a mobile service. To this end, the FIC handler 121 may include an FIC segment buffer, an FIC segment parser, and an FIC chunk parser.

The FIC segment buffer buffers the FIC segment group in M / H frame units input from the signaling decoder 118 and outputs the buffer to the FIC segment parser. The FIC segment parser extracts and analyzes the header of each FIC segment stored in the FIC segment buffer, and outputs the payload of the corresponding FIC segment to the FIC chunk parser according to the analysis result. The FIC chunk parser extracts signaling information for service acquisition by restoring and analyzing the FIC chunk data structure from the FIC segment payloads using the results analyzed by the FIC segment parser. The signaling information obtained by the FIC chunk parser is output to the service manager 122.

Meanwhile, the service signaling handler 123 is composed of a service signaling buffer and a service signaling parser, and buffers and analyzes and processes table sections of a service signaling channel transmitted from the UDP datagram handler 143. The signaling information processed by the service signaling handler 123 is also output to the service manager 122.

The service manager 122 constructs a service map using the signaling information collected from the FIC handler 121 and the service signaling handler 123, and collects the service guide (SG) collected from the service guide (SG) handler 165. SG) to write a program guide. In addition, the operation controller 119 is controlled to receive the mobile service desired by the user with reference to the service map and the service guide, and the program guide can be displayed on at least part of the screen according to the user's input.

The first controller 124 stores the service map and the service guide created by the service manager 122. In addition, the first controller 124 extracts necessary data according to the request of the service manager 122 and the EPG manager 171, and transfers the necessary data to the service manager 122 and / or the EPG manager 171.

The operation controller 119 receives the known data position information and the TPC data, receives M / H frame time information, whether a data group exists in the selected parade, whether the known data in the data group is located, power control information, and the like. Is transmitted to each block of the baseband processor 110. A detailed description of the TPC data will be given later.

 Meanwhile, according to the present invention, the transmission system uses the RS frame concept as an encoding unit. The RS frame is divided into a primary RS frame and a secondary RS frame. In the present invention, the division of the primary RS frame and the secondary RS frame according to the importance of the data according to an embodiment.

The primary RS frame decoder 116 receives an output of the block decoder 115 as an input. In this embodiment, the primary RS frame decoder 116 receives only mobile service data encoded with Reed Solomon (RS) encoding and / or cyclic redundancy check (CRC) encoding from the block decoder 115. That is, the primary RS frame decoder 116 receives only mobile service data, not main service data. The primary RS frame decoder 116 performs the reverse process of the RS frame encoder (not shown) of the transmission system to correct errors in the primary RS frame. That is, the primary RS frame decoder 116 collects a plurality of data groups to form a primary RS frame and then performs error correction on a primary RS frame basis. In other words, the primary RS frame decoder 116 decodes the primary RS frame transmitted for the actual broadcast service. The primary RS frame decoded by the primary RS frame decoder 116 is output to the primary RS frame buffer 131. After the primary RS frame buffer 131 buffers the primary RS frame, the primary RS frame buffer 131 configures an M / H TP in units of rows and outputs the M / H TP to the TP handler 133.

The secondary RS frame decoder 117 receives an output of the block decoder 115 as an input. In this embodiment, the secondary RS frame decoder 117 receives only RS encoded and / or CRC encoded mobile service data. That is, the secondary RS frame decoder 117 receives only mobile service data, not main service data. The secondary RS frame decoder 117 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the secondary RS frame. That is, the secondary RS frame decoder 117 collects a plurality of data groups to form a secondary RS frame and then performs error correction on a secondary RS frame basis. In other words, the secondary RS frame decoder 117 decodes the secondary RS frame transmitted for mobile audio service data, mobile video service data, guide data, and the like. The data of the secondary RS frame decoded by the secondary RS frame decoder 117 is output to the secondary RS frame buffer 132. The secondary RS frame buffer 132 buffers the secondary RS frame and configures an M / H TP in units of rows, and outputs the M / H TP to the TP handler 133.

The TP handler 133 is composed of a TP buffer and a TP parser. After buffering the M / H TP received from the primary and secondary RS frame buffers 131 and 132, each header of the buffered M / H TP is extracted. After analyzing, the IP datagram is restored from the payload of the corresponding M / H TP. The restored IP datagram is output to the IP datagram handler 141.

The IP datagram handler 141 includes an IP datagram buffer and an IP datagram parser. After buffering the IP datagram received from the TP handler 133, the IP datagram handler 141 extracts and analyzes a header of the buffered IP datagram. Restores the UDP datagram from the payload of the IP datagram. The restored UDP datagram is output to the UDP datagram handler 143.

If the UDP datagram is scrambled, the scrambled IP datagram is descrambled by the descrambler 142 and then output to the UDP datagram handler 143. For example, when scramble is applied to a UDP datagram among the received IP datagrams, the descrambler 142 receives an encryption key or the like from the service protection stream handler 146 and decodes the UDP datagram. After scrambled, the data is output to the UDP datagram handler 143.

The UDP datagram handler 143 is composed of a UDP datagram buffer and a UDP datagram parser, and buffers UDP datagrams input from the IP datagram handler 141 or the descrambler 142 and then buffers the UDP. The header of the datagram is extracted and analyzed to restore the data transmitted to the payload of the corresponding UDP datagram. At this time, if the restored data is an RTP / RTCP datagram, it is output to the RTP / RTCP datagram handler 144, and if it is an NTP datagram, it is output to the NTP handler 145. Alternatively, if the recovered data is a service protection stream, it is output to the service protection stream handler 146, and if it is an ALC / LCT stream, it is output to the ALC / LCT stream handler 148.

The RTP / RTCP datagram handler 144 is composed of an RTP / RTCP datagram buffer and an RTP / RTCP datagram parser, and after buffering the data of the RTP / RTCP structure output from the UDP datagram handler 143, Extract the audio / video stream from the buffered data. The extracted audio / video stream is output to the audio / video (A / V) decoder 161. The A / V decoder 161 decodes the audio stream and the video stream output from the RTP / RTCP datagram handler 144 using respective decoding algorithms, and outputs the decoded audio stream to the presentation manager 170. For example, the audio decoding algorithm may be an AC-3 decoding algorithm, an MPEG 2 audio decoding algorithm, an MPEG 4 audio decoding algorithm, an AAC decoding algorithm, an AAC + decoding algorithm, an HE AAC decoding algorithm, an AAC SBR decoding algorithm, an MPEG surround decoding algorithm, or a BSAC decoding. At least one of the algorithm may be applied, and the video decoding algorithm may apply at least one of an MPEG 2 video decoding algorithm, an MPEG 4 video decoding algorithm, an H.264 decoding algorithm, an SVC decoding algorithm, and a VC-1 decoding algorithm.

The NTP datagram handler 145 is composed of an NTP datagram buffer and an NTP datagram parser. After buffering the data of the NTP structure output from the UDP datagram handler 143, the NTP datagram handler 145 extracts an NTP stream from the buffered data. do. The extracted NTP stream is output to the A / V decoder 161 and decoded.

The service protection stream handler 146 may further include a service protection stream buffer. After buffering the data for service protection output from the UDP datagram handler 143, the service protection stream handler 146 may be configured to descramble the buffered data. Extract the information. The information for descrambling includes a key value for descrambling such as SKTM, LKTM, and the like. Information for the descramble is stored in the second storage unit 147, and is output to the descrambler 142 if necessary.

The ALC / LCT stream handler 148 is composed of an ALC / LCT stream buffer and an ALC / LCT stream parser. After buffering the data of the ALC / LCT structure output from the UDP datagram handler 143, the buffered data Analyze the header and header extension of the ALC / LCT session. As a result of analyzing the header and the header extension of the ALC / LCT session, if the data transmitted in the ALC / LCT session is an XML structure, it is output to the XML parser 150, and if it is a file structure, it is output to the file decoder 162.

In this case, if data transmitted to the ALC / LCT session is compressed, the compressed data is decompressed by the decompressor 149 and then output to the XML parser 150 or the file decoder 162.

The XML parser 150 analyzes the XML data transmitted through the ALC / LCT session, outputs the analyzed data to the FDT handler 151 if the analyzed data is data for a file-based service, and the SG handler if the data is for service guide. Output to (165).

The FDT handler 151 analyzes and processes a file description table (FDT) of the FLUTE protocol transmitted in an XML structure through an ALC / LCT session.

The SG handler 165 collects and analyzes data for a service guide transmitted in an XML structure and outputs the data to the service manager 122.

The file decoder 162 decodes the data of the file structure transmitted through the ALC / LCT session and outputs the data to the middleware engine 164 or stores the data in the third storage unit 163.

The middleware engine 164 analyzes and executes data of a file structure, that is, an application. The application may be output to an output device such as a screen or a speaker through the presentation manager 170. In an embodiment, the middleware engine 164 is a JAVA based middleware engine.

The EPG manager 171 receives the EPG data from the service manager 122 or the SG handler 165 according to the user's input, converts the EPG data into a display format, and outputs the EPG data to the presentation manager 170.

The application manager 172 performs overall management regarding the processing of application data transmitted in the form of an object, a file, and the like.

The operation controller 100 controls at least one of the service manager 122, the EPG manager 171, the application manager 172, and the presentation manager 170 according to a user's command input through the UI manager 173. By controlling, the function according to the user's command is performed.

The UI manager 173 transmits a user's input to the operation controller 100 through the UI.

The presentation manager 170 may include at least one of audio and video data output from the A / V decoder 161, file data output from the middleware engine 164, and EPG data output from the EPG manager 171. Provide it to the user via the screen.

Data format structure

On the other hand, the data structure used in the mobile broadcasting technology according to the embodiment of the present invention includes a data group structure and an RS frame structure. This will be described below.

2 is a diagram illustrating an embodiment of a structure of a data group according to the present invention.

In the data configuration according to FIG. 2, an example of dividing a data group into ten M / H blocks B1 to B10 is shown. Each M / H block has a length of 16 segments. In FIG. 2, the first five segments of the M / H block B1 and the five segments after the M / H block B10 are allocated only RS parity data to a part of the data group, and are excluded from the areas A to D of the data group.

In other words, assuming that one data group is divided into A, B, C, and D areas, each M / H block is allocated to any one of the A to D areas according to the characteristics of each M / H block in the data group. Can be included. At this time, according to an embodiment of the present invention, each M / H block is included in any one of the A region and the D region according to the degree of interference of the main service data.

Here, the reason why the data group is divided into a plurality of areas is used for different purposes. That is, an area where there is no or little interference of the main service data may exhibit stronger reception performance than an area that is not. In addition, when applying a system for inserting and transmitting known data known to the data group by the promise of the transmitting / receiving party, when a long period of continuous data is to be inserted periodically into the mobile service data, the main service It is possible to periodically insert known data of a certain length into an area where data does not interfere (that is, an area where main service data is not mixed). However, it is difficult to periodically insert known data into the area where the main service data interferes with the interference of the main service data, and also to insert long known data continuously.

The M / H blocks B4 to M / H block B7 in the data group of FIG. 2 show an example in which a long known data string is inserted before and after each M / H block as an area free from interference of main service data. In the present invention, the M / H blocks B4 to M / H block B7 are referred to as an A region (= B4 + B5 + B6 + B7). As described above, in the case of the area A having a known data sequence back and forth for each M / H block, the receiving system can perform equalization using channel information obtained from the known data, and thus the strongest equalization among the areas A to D. You can get performance.

In the data group of FIG. 2, the M / H block B3 and the M / H block B8 are regions in which main service data has little interference, and a long known data string is inserted into only one side of both M / H blocks. That is, due to the interference of the main service data, M / H block B3 is inserted with a long known data column only after the M / H block, and M / H block B8 is inserted with a long known data column only before the corresponding M / H block. Can be. In the present invention, the M / H block B3 and the M / H block B8 will be referred to as a B region (= B3 + B8). As described above, in the case of the B area having only one known data string in each M / H block, the receiving system can perform equalization using channel information obtained from the known data, which is more robust than the C / D area. Equalization performance can be obtained.

The M / H block B2 and the M / H block B9 in the data group of FIG. 2 have more interference of the main service data than the B area, and both M / H blocks cannot insert a long known data string back and forth. In the present invention, the M / H block B2 and the M / H block B9 are referred to as a C region (= B2 + B9).

The M / H block B1 and the M / H block B10 in the data group of FIG. 2 have more interference of the main service data than the C region, and likewise, both M / H blocks cannot insert a long known data string back and forth. In the present invention, the M / H block B1 and the M / H block B10 will be referred to as a D region (= B1 + B10). Since the C / D region is far from the known data stream, the reception performance may be poor when the channel changes rapidly.

The data group also includes a signaling information region to which signaling data (or signaling information) is allocated.

According to the present invention, a part of the first to second segments of the M / H block B4 in the data group may be used as the signaling information region.

According to an embodiment of the present invention, 276 (= 207 + 69) bytes of the M / H block B4 of each data group are used as the signaling information region. That is, the signaling information area consists of 207 bytes which is the first segment of the M / H block B4 and the first 69 bytes of the second segment. The first segment of the M / H block B4 corresponds to the 17th or 173th segment of the VSB field.

Signaling data transmitted to the signaling information region can be largely divided into two types of signaling channel data. One is Transmission Parameter Channel (TPC) data and the other is Fast Information Channel (FIC) data.

The TPC data mainly includes parameters used in a physical layer module and is transmitted without being interleaved, so that the TPC data can be accessed for each slot in the receiving system.

The FIC data is provided to enable fast service acquisition at the receiver and includes cross layer information between the physical layer and the upper layer. The FIC data is interleaved in subframe units and transmitted.

For example, when the data group includes six known data columns as shown in FIG. 2, the signaling information area is located between the first known data row and the second known data row. That is, the first known data string is inserted into the last two segments of the M / H block B3 in the data group, and the second known data string is inserted into the second and third segments of the M / H block B4. The third to sixth known data columns are inserted into the last two segments of the M / H blocks B4, B5, B6, and B7, respectively. The first, third to sixth known data columns are spaced 16 segments apart.

3 is a diagram illustrating a structure of an RS frame according to an embodiment of the present invention.

The RS frame is received for each M / H frame while being switched to the time slicing mode. One RS frame includes IP streams of each mobile service data or signaling data, and service map table (SMT) section data may be present in all RS frames. The SMT section data may be in the form of an IP stream or may be in another form. Data of the RS frame is allocated to the corresponding areas of the plurality of data groups and transmitted.

RS frame according to an embodiment of the present invention consists of at least one M / H TP (Transport Packet). This M / H TP consists of an M / H header and an M / H payload.

The M / H payload may include signaling data as well as mobile service data. That is, one M / H payload may include only mobile service data, may include only signaling data, or may include both service data and signaling data.

According to an embodiment of the present invention, data included in the M / H payload may be distinguished by the M / H header. That is, when the M / H TP has a first M / H header, it indicates that the M / H payload includes signaling data. Also, when the M / H TP has a second M / H header, it indicates that the M / H payload includes signaling data and service data. If the M / H TP has a third M / H header, it indicates that the M / H payload includes service data.

3 shows an example in which IP datagrams (ie, IP Datagram 1 and IP Datagram 2) for two types of mobile services are allocated.

Data transfer structure

4 is a diagram illustrating an example of an M / H frame structure for transmitting / receiving mobile service data according to the present invention.

4 shows an example in which one M / H frame consists of five subframes and one subframe consists of 16 slots. In this case, one M / H frame means five subframes and 80 slots.

One slot consists of 156 data packets (ie, transport stream packets) at the packet level and 156 data segments at the symbol level. Or half of the VSB field. That is, since one data packet of 207 bytes has the same amount of data as one data segment, the data packet before data interleaving can be used as the concept of the data segment. At this time, two VSB fields are combined to form one VSB frame.

5 illustrates an example of a VSB frame structure, in which one VSB frame includes two VSB fields (ie, odd field and even field). Each VSB field consists of one field sync segment and 312 data segments.

The slot is a basic time unit for multiplexing the mobile service data and the main service data. One slot may include mobile service data or may consist only of main service data.

If the first 118 data packets in a slot belong to one data group, the remaining 38 packets become the main service data packet. As another example, if there is no data group in one slot, the slot consists of 156 main service data packets.

Meanwhile, mobile service data in one RS frame may be allocated to all of the A / B / C / D areas in the data group or may be allocated to at least one of the A / B / C / D areas. According to an embodiment of the present invention, mobile service data in one RS frame is allocated to all of the A / B / C / D areas or only to one of the A / B areas and the C / D areas. That is, in the latter case, the RS frame allocated to the A / B area in the data group and the RS frame allocated to the C / D area are different. According to an embodiment of the present invention, the RS frame allocated to the A / B region in the data group is called a primary RS frame, and the RS frame allocated to the C / D region is a secondary RS frame. frame). The primary RS frame and the secondary RS frame form one parade. That is, if the mobile service data in one RS frame are all allocated to the A / B / C / D areas in the data group, one parade transmits one RS frame. In contrast, if the mobile service data in one RS frame is allocated to the A / B area in the data group and the mobile service data in the other RS frame is allocated to the C / D area in the data group, Up to RS frames can be transmitted.

That is, the RS frame mode indicates whether one parade transmits one RS frame or two RS frames. This RS frame mode is transmitted as TPC data.

Table 1 below shows an example of an RS frame mode.

RS frame mode Description 00 There is only a primary RS frame for all Group Regions 01 There are two separate RS frames
Primary RS frame for Group Region A and B
-Secondary RS frame for Group Region C and D 10 Reserved 11 Reserved

In Table 1, 2 bits are allocated to indicate an RS frame mode. Referring to Table 1, if the RS frame mode value is 00, one parade transmits one RS frame. If the RS frame mode value is 01, one parade is two RS frames, that is, primary RS. Indicates that the frame and the secondary RS frame are to be transmitted. That is, when the RS frame mode value is 01, data of the primary RS frame for region A / B for the A / B region is allocated to the A / B region of the data group and transmitted, and the C / D The data of the secondary RS frame for region C / D for the region indicates that the data is allocated to the C / D region of the corresponding data group and transmitted.

Like the data group allocation, the parades may be allocated as far apart from each other as possible in the subframe. This makes it possible to respond strongly to burst errors that can occur within one subframe.

In addition, the method of allocating parades may be differently applied to every M / H frame and may be equally applied to all M / H frames. In addition, the same may be applied to all subframes in one M / H frame or may be differently applied to each subframe. The present invention may vary for each M / H frame, and the same applies to all subframes in one M / H frame. That is, the M / H frame structure may vary in units of M / H frames, which makes it possible to flexibly adjust the ensemble data rate.

That is, in the embodiment of the present invention, the ensemble concept is introduced to define a set of services. One M / H ensemble has the same QoS and is coded with the same FEC code. In addition, one ensemble has the same unique identifier (ie, ensemble id) and corresponds to consecutive RS frames.

6 is a diagram illustrating a data transmission structure in a physical layer according to an embodiment of the present invention, and shows an example in which FIC data is included and transmitted in each data group.

As described above, the M / H frame for about 0.968 seconds is divided into five subframes, and data groups corresponding to several ensembles are present in each subframe, and data groups corresponding to each ensemble are present. These are interleaved in M / H frame units to form an RS frame belonging to one ensemble. In FIG. 6, two ensemble (NoG = 4, NoG = 3) exist. In addition, a portion of each data group (e.g. 37 bytes / data group) is used to deliver encoded FIC data separately from the RS frame data channel. The FIC region allocated to each data group constitutes one FIC segment, which is interleaved in units of subframes. For example, RS encoding and serial concatenated convolution code (SCCC) encoding are applied to data of the RS frame, and RS encoding and parallel concatenated convolution code (PCCC) encoding are applied to the FIC data. . TPC data is applied to RS encoding and parallel concatenated convolution code (PCCC) encoding similarly to the FIC data. In this case, (187 + P, 187) -RS encoding is applied to the data of the RS frame, (51,37) -RS encoding is applied to the FIC data, and the (18,10) -RS encoding is applied to the TPC data. In one embodiment it is applied. Where P is the number of parity bytes.

Hierarchical Signaling  rescue

7 illustrates a hierarchical signaling structure according to an embodiment of the present invention. As shown in FIG. 7, the mobile broadcast technology according to the present embodiment employs a signaling method using FIC and SMT. This is called hierarchical signaling structure in the present invention.

That is, FIG. 7 illustrates a hierarchical signaling structure for providing data required for service acquisition through a service map table (SMT) among FIC chunks and IP level mobile service signaling channels.

As can be seen in FIG. 7, the FIC chunk uses its fast characteristic to convey the mapping relationship between the mobile service and the ensemble to the receiving system. That is, the FIC chunk provides signaling system for quickly finding an ensemble delivering a desired service in the receiving system and quickly receiving RS frames of the ensemble.

FIC ( Fast Information Channel )

In addition, in the reception system according to the present invention, a fast information channel (FIC) enables faster access to a currently broadcast mobile service.

That is, the FIC handler 121 of FIG. 1 configures an FIC chunk from FIC segments, parses the FIC chunk, and outputs the result to the service manager 122.

8 shows a syntax structure of an FIC chunk that serves to map a relationship between a mobile service and an ensemble through the FIC.

The FIC chunk consists of a 5-byte FIC chunk header and a variable length FIC chunk payload.

9 illustrates an embodiment of a syntax structure of an FIC chunk header according to the present invention.

The FIC chunk header signals a major protocol version change that is not backward compatible with the corresponding FIC chunk, and a minor protocol version that is backward compatible with the corresponding FIC chunk. Signals a minor protocol version change and signals each length of an extension of an FIC chunk header, an extension of an ensemble loop header, and a mobile service loop extension that may be caused by a minor protocol version change. .

If a receiving system that can accommodate the corresponding minor protocol version change processes the corresponding extension field, a legacy receiving system that cannot accept the corresponding minor protocol version change uses each corresponding length information. In an embodiment, the corresponding extended field is skipped. For example, if the receiving system can accommodate the minor protocol version change, the content field indicated by the corresponding extension field can be known, and the operation according to the content indicated by the extension field can be performed.

According to an embodiment of the present invention, the minor protocol version change of the FIC chunk is performed by inserting an additional field at each end of the FIC chunk header, the ensemble loop header, and the mobile service loop in the FIC chunk of the previous minor protocol version. Otherwise, if the length of the additional field is not represented by each extension length of the FIC chunk header, or if a particular field in the FIC chunk payload is missing, or the number of bits allocated to that field or In one embodiment, when the definition of the field is changed, the major protocol version of the corresponding FIC chunk is updated.

In addition, the FIC chunk header signals whether data of the corresponding FIC chunk payload includes mapping information between an ensemble and a mobile service in a current M / H frame or mapping information between an ensemble and a mobile service in a next M / H frame. It also signals the transport stream ID of the mobile broadcast in which the current FIC chunk is transmitted and the number of ensembles transmitted through the corresponding mobile broadcast.

To this end, the FIC chunk header may include an FIC_major_protocol_version field, an FIC_minor_protocol_version field, an FIC_chunk_header_extension_length field, an ensemble_loop_header_extension_length field, an M / H_service_loop_extension_length field, a current_next_indicator field, a transport_stream_id field, a les field, and a transport_stream_id field.

In an embodiment, the FIC_major_protocol_version field allocates 2 bits and indicates a major protocol version of the corresponding FIC chunk syntax. The major protocol version change indicates a level change that is not backward compatible. If this field value is updated, a legacy receiver system that can handle previous major versions of the FIC chunk protocol will not process the FIC chunk (A two-bit unsigned integer field that represents the major version level of the syntax of the FIC Chunk.A change in the major version level shall indicate a non-backward-compatible level of change.When this field is updated, legacy receivers who can process the prior major version of FIC-Chunk protocol shall avoid attempting to process the FIC Chunk).

In an embodiment, the FIC_minor_protocol_version field allocates 3 bits and indicates a minor protocol version of the corresponding FIC chunk syntax. Changing the minor protocol version indicates a backward compatible level change. If this field is updated, a legacy receiver capable of processing the same major version of the FIC chunk protocol may process a portion of the FIC chunk (A three-bit unsigned integer field that represents the minor version level. of the syntax of the FIC-Chunk.A change in the minor version level, provided the major version level remains the same, shall indicate a backward-compatible level of change.This means that, when this field is updated, legacy receivers who can process the same major version of FIC Chunk protocol may process a part of the FIC Chunk).

The FIC_Chunk_header_extension_length field allocates 3 bits according to an embodiment, and indicates the length of the FIC chunk header extension byte generated by the minor protocol version update of the corresponding FIC chunk. The 3-byte unsigned integer field identifies the length of the FIC-Chunk header extension bytes caused by the minor protocol version update of the FIC-Chunk, where the extension bytes are appended at the end of the FIC-Chunk header).

In an embodiment, the ensemble_header_extension_length field allocates 3 bits and indicates the length of an ensemble header extension byte generated by a minor protocol version update of a corresponding FIC chunk. The 3-byte unsigned integer field identifies the length of the ensemble header extension bytes caused by the minor protocol version update of the FIC-Chunk, where the extension bytes are appended at the end of the ensemble loop header).

The M / H_service_loop_extension_length field allocates 3 bits in one embodiment and indicates the length of the mobile service loop extension byte generated by the minor protocol version update of the corresponding FIC chunk. The 3-byte unsigned integer field identifies the length of the ensemble header extension bytes caused by the minor protocol version update of the M / H service loop, where the extension bytes are appended at the end of the M / H service loop).

In an embodiment, the current_next_indicator field allocates 1 bit, and when the field value is set to 1, it indicates that the corresponding FIC chunk is applied to the current M / H frame. A one-bit indicator, which when set to '1' shall indicate that this FIC-Chunk is currently applicable.when the field is set to 0, the FIC chunk is applied to the next M / H frame. bit is set to '0', it shall indicate that this FIC-Chunk will be applicable for the next M / H Frame.In the latter case, the most recent version of FIC-Chunk transmitted with the current_next_indicator bit set to '1' shall be currently applicable). That is, when the field value is set to 1, it means that the corresponding FIC chunk transmits signaling data of the current M / H frame. In addition, if the field value is set to 0, this means that the corresponding FIC chunk transmits signaling data of the next M / H frame. According to the present invention, when reconfiguration occurs in which mapping information between an ensemble and a mobile service in a current M / H frame and mapping information between an ensemble and a mobile service in a next M / H frame are different, an M / before the reconfiguration occurs. The H frame is called a current M / H frame, and an M / H frame where reconfiguration occurs is called a next M / H frame.

In an embodiment, the transport_stream_id field allocates 16 bits and indicates a transport stream ID of a mobile broadcast in which a current FIC chunk is transmitted. This 16-bit unsigned integer number field serves as a label to identify this M / H Broadcast.The value of this field shall be equal to the value of the transport_stream_id field in the Program Association Table (PAT) in the MPEG-2 transport stream of the main ATSC broadcast).

In an embodiment, the num_ensembles field allocates 8 bits and indicates the number of ensembles transmitted through the corresponding physical transport channel (An 8-bit unsigned integer field that shall equal the number of Ensembles carried through this physical transmission channel). .

10 illustrates an embodiment of protocol version change when using syntax and protocol versioning structure of an FIC chunk according to the present invention.

In FIG. 10, two ensemble (ie, ensemble 0 and ensemble 1) exist, two mobile services are transmitted through ensemble 0, and one mobile service is transmitted through ensemble 1. FIG. At this time, when the minor protocol version of the FIC chunk is changed, the value of the FIC_minor_protocol_version field is increased and displayed, extension bytes of the FIC chunk header added by the corresponding minor protocol version, and an ensemble loop header. Each length information of the extension bytes of and the extension bytes of the mobile service loop is signaled through the FIC_chunk_header_extension_length, ensemble_loop_header_extension_length, and M / H_service_loop_extension_length fields of the FIC chunk header. That is, it is signaled to skip the corresponding extension bytes in the existing receiving system that cannot accommodate the corresponding minor protocol version change.

In FIG. 10, the FIC_minor_protocol_version field value of the FIC chunk is changed from 000 to 001, and the FIC_chunk_header_extension_length field, ensemble_loop_header_extension_length, and M / H_service_loop_extension_length fields are added to the FIC chunk header of the changed minor protocol version. At this time, if the FIC chunk header is extended by one byte, the FIC_chunk_header_extension_length field indicates 001. In this case, one byte extension field (FIC_Chunk_header_extension_bytes field) is added to the end of the FIC chunk header, and the existing receiving system skips the one-byte extension field added to the end of the FIC chunk header without processing.

If the ensemble loop header in the FIC chunk is extended by 2 bytes, the ensemble_loop_header_extension_length field indicates 010. In this case, two bytes of extension fields (Ensemble_loop_header_extension_bytes fields) are added to the end of the ensemble 0 loop header and the ensemble 1 loop header, respectively, and in the conventional receiving system, two bytes of extension added to the end of the ensemble 0 loop header and the ensemble 1 loop header are added. The field is skipped without processing.

In addition, if the mobile service loop of the FIC chunk is extended by one byte, the M / H_service_loop_extension_length field indicates 001. In this case, one byte extension field (M / H_service_loop_extension_bytes field) is added to the end of two mobile service loops transmitted through ensemble 0 and one mobile service loop transmitted through ensemble 1. In the conventional receiving system, two mobile service loops transmitted through the ensemble 0 and one byte extended field added to the end of one mobile service loop transmitted through the ensemble 1 are skipped without processing.

FIG. 11 illustrates an embodiment of the FIC chunk processing process when the minor protocol version of the FIC chunk is changed as shown in FIG. 10. Existing receiving systems, that is, receiving systems that cannot accommodate the corresponding minor protocol version change of FIC chunks, process the remaining fields except the extension field when the value of the FIC_minor_protocol version field is changed, and use the FIC_chunk_header_extension_length, ensemble_loop_header_extension_length, and M / H_service_loop_extension_length fields. The extended fields are skipped without processing. If the receiving system can accommodate the change of the corresponding minor protocol version of the FIC chunk, the corresponding extended field is processed using each length field.

12 illustrates an embodiment of a syntax structure of an FIC chunk payload according to the present invention.

The FIC chunk payload includes configuration information of an ensemble and information on a mobile service transmitted through each ensemble, for each ensemble corresponding to a num_ensembles field value in the FIC chunk header of FIG. 9. have. The FIC chunk payload consists of an ensemble loop and a mobile service loop below the ensemble loop. Through the FIC chunk payload, the receiving system can determine through which ensemble the desired mobile service is transmitted (this is done by mapping between ensemble_id and M / H_service_id) and receive RS frames belonging to the ensemble.

To this end, the ensemble loop of the FIC chunk payload may include an ensemble_id field, an ensemble_structure_major_version field, an ensemble_structure_minor_version field, an SLT_ensemble_indicator field, a GAT_ensemble_indicator field, and an M / H_service_configuration_version field, and a nums_ / field, which are repeated as many as the num_ensembles field value. The mobile service loop may include a multi_ensemble_service field, an M / H_service_status field, and an SP_indicator field which are repeated by the num_M / H_services field value.

In one embodiment, the ensemble_id field allocates 8 bits and indicates a unique identifier of the ensemble. For example, values of 0x00 to 0x7F may be allocated as the field value. This field serves to bind the mobile services and the ensemble. The value of the field may be derived from parade_id of TPC data. For example, when the ensemble is transmitted through the primary RS frame, the most significant bit (MSB) is set to '0' and the remaining 7 bits are used as the parade_id value of the parade. On the other hand, when the ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to '1' and the remaining 7 bits are used as the parade_id value of the parade (This 8-bit unsigned integer field in the range 0x00 to 0x7F shall be the Ensemble ID associated with this M / H Ensemble.The value of this field shall be derived from the parade_id carried through the TPC, by using the parade_id of the associated M / H Parade for the least significant 7 bits , and using '0' for the most significant bit when the M / H Ensemble is carried over the Primary RS Frames and using '1' for the most significant bit when the M / H Ensemble is carried over the Secondary RS Frames. the value of ensemble_id of an M / H Ensemble shall not be changed during the period of time where an M / H Service is present and / or announced in the SG).

In an embodiment, the ensemble_major_protocol_version field allocates 2 bits and indicates a major protocol version of a corresponding ensemble structure (particularly, a corresponding RS frame structure and a mobile service structure). A change in the ensemble major protocol version indicates a change in level that is not backward-compatible (a two-bit unsigned integer field that represents the major level version of the structure of this ensemble, specifically its RS Frame structure and its M / H Service Signaling Channel.A change in the major version level shall indicate a non-backward-compatible level of change).

The ensemble_minor_protocol_version field allocates 3 bits in one embodiment and indicates a version of the minor protocol of the ensemble structure. A three-bit unsigned integer field that represents the minor level version of the structure of this ensemble, specifically its RS Frame structure and its M / H Service Signaling Channel.A change in the minor version level, provided the major version level remains the same, shall indicate a backward-compatible level of change). The ensemble_structure_major_version field and ensemble_structure_minor_version field may be omitted from the FIC chunk payload.

In another embodiment, the 5-bit ensemble_protocol_version field may be allocated instead of the ensemble_structure_major_version field and the ensemble_structure_minor_version field, and the major protocol version and minor protocol version of the ensemble structure (particularly, the RS frame structure and the mobile service structure) may be displayed. That is, the upper two bits of the ensemble_protocol_version field indicate the major protocol version of the ensemble structure, and the lower three bits indicate the minor protocol version of the ensemble structure.

The SLT_ensemble_indicator field allocates 1 bit according to an embodiment, and indicates whether SLT information is transmitted by a corresponding ensemble (S one_bit indicator, which when set to '1' shall indicate that the SLT (Service Labeling Table) is carried in the M / H Service Signaling Channel of this Ensemble).

In an embodiment, the GAT_ensemble_indicator field allocates 1 bit and indicates whether the GAT information is transmitted as a corresponding ensemble (A one-bit indicator, which when set to '1' shall indicate that the GAT (Guide Access Table) is carried in the signaling stream of this ensemble).

In an embodiment, the M / H_service_configuration_version field allocates 5 bits and indicates a version of the mobile service signaling channel of the corresponding ensemble (This 5-bit field is the version number of the M / H Service Signaling Channel of this M). / H Ensemble.The value of this field is modulo 32 and shall be incremented by 1, whenever a change is made in any of the tables carried within the M / H Service Signaling Channel in this ensemble).

In an embodiment, the num_M / H_services field allocates 8 bits and indicates the number of mobile services transmitted by the ensemble (An 8-bit unsigned integer field that represents the number of M / H Services carried through this M /). H Ensemble).

As an example, if the minor protocol version in the FIC chunk header is changed and an extension field is added to the ensemble loop header, this extension field is added after the num_M / H_services field. In another embodiment, if the num_M / H_services field is included in a mobile service loop, an extension field added to the ensemble loop header is added after the M / H_service_configuration_version field.

In an embodiment, the M / H_service_id field of the mobile service loop allocates 16 bits and indicates a unique identifier of the corresponding mobile service. This field value is a 16-bit unsigned integer number that identifies the M / H Service.This number shall be unique within the M / H Broadcast.For a situation when an M / H Service has components in multiple M / H Ensembles, the set of IP streams of the service in each Ensemble shall be treated as a separate service for signaling purposes, except that the entries for these services in the FIC shall all have the same M / H_service_id value. , the same M / H_service_id value may appear in more than one num_ensembles loop, and when this happens the M / H_service_id shall represent the overall combined service, thereby maintaining the uniqueness of the M / H_service_id.).

In an embodiment, the multi_ensemble_service field allocates 2 bits and indicates whether the corresponding mobile service is transmitted through one or more ensemble. Also, this field value indicates whether the mobile service is valid only for the portion of the mobile service transmitted through the ensemble (i two-bit enumerated field that shall identify whether this M / H Service is carried across more than one M /). Also, this field identifies whether the M / H Service can be rendered meaningfully with only the portion of the M / H Service carried through this M / H Ensemble).

The M / H_service_status field allocates 2 bits in one embodiment and indicates a state of a corresponding mobile service. For example, an upper bit of the field indicates whether the corresponding mobile service is active, and a lower bit indicates whether the corresponding mobile service is hidden (A 2-bit enumerated field that shall identify the status of this M / H The most significant bit indicates whether this M / H Service is active (when set to 1) or inactive (when set to 0) and the least significant bit indicates whether this M / H Service is hidden (when set to 1) or not (when set to 0).

In an embodiment, the SP_indicator field allocates 1 bit, and indicates whether the corresponding mobile service has service protection (A 1-bit field that indicates, when set to 1, service protection is applied to at least one of the components needed to provide a meaningful presentation of this M / H Service).

As an example, if the minor protocol version in the FIC chunk header is changed and an extension field is added to the mobile service loop, this extension field is added after the SP_indicator field.

In addition, the FIC chunk payload may include an FIC_chunk_stuffing () field. Stuffing of the FIC_chunk_stuffing () field is necessary for the boundary of the FIC chunk to be aligned with the boundary of the last FIC segment among the FIC segments belonging to the FIC chunk (Stuffing may exist in an FIC-Chunk, to keep the boundary of the FIC-Chunk to be aligned with the boundary of the last FIC-Segment among FIC-segments belong to the FIC chunk.The length of the stuffing is determined by how much space is left after parsing through the entire FIC- Chunk payload preceding the stuffing.).

At this time, the transmission system (not shown) according to the present invention divides the FIC chunk into a plurality of FIC segments as shown in FIG. 13, and transmits the FIC chunk to the receiving system in units of FIC segments. Each FIC segment unit is 37 bytes in size, and each FIC segment consists of a 2-byte FIC segment header and a 35-byte FIC segment payload. That is, one FIC chunk composed of the FIC chunk header and the FIC chunk payload as shown in FIG. 13A is segmented by 35 bytes as shown in FIG. 13B. Then, as shown in FIG. 13 (c), two bytes of the FIC segment header are added in front of each segmented 35 bytes to form the FIC segment.

In an embodiment of the present invention, the length of the FIC chunk payload is variable. The length of the FIC chunk depends on the number of ensembles transmitted through the corresponding physical transport channel and the number of mobile services included in each ensemble.

The FIC chunk payload may include stuffing data. In this case, the stuffing data is used for alignment between the FIC chunk and the boundary of the last FIC segment among the FIC segments belonging to the FIC chunk. By minimizing the length of stuffing data, waste of FIC segments can be reduced.

Applying Equation 1 below, the number of stuffing data bytes to be inserted into the FIC chunk can be obtained.

Number of stuffing data bytes = 35-j

j = (5 + number of bytes of signaling data to be inserted into the payload of the FIC chunk) mod 35

For example, if the sum of the 5-byte header of the FIC chunk and the length of the signaling data to be inserted into the payload is 205 bytes, j in Equation 1 is 30, so the payload of the FIC chunk includes 5 bytes of stuffing data. can do. The length of the FIC chunk including the stuffing data is 210 bytes, and the FIC chunk is divided into six FIC segments and transmitted. At this time, the segment number is sequentially added to the six FIC segments divided in the FIC chunk.

In addition, the present invention may transmit FIC segments divided from one FIC chunk through one subframe or through a plurality of subframes as shown in FIG. 14. If the FIC chunk is transmitted as in the latter case, the amount of data to be transmitted through the FIC chunk is larger than the amount of FIC segments transmitted in one subframe (in this case, the bit rate is very low) If the service is executed, etc.), all the necessary signaling data can be transmitted through the FIC chunk.

FIG. 14 illustrates an embodiment in which data of an FIC chunk is transmitted through four FIC segments when the TNoG of the corresponding mobile broadcast is six.

14 shows an example in which an FIC chunk is repeatedly transmitted two times in succession. At this time, all FIC segments divided from the FIC chunk are transmitted once through two subframes (subframe1 and subframe2), and once all are divided from the FIC chunk through one subframe (subframe1) of the two subframes. An example of FIC segments being transmitted is shown. That is, the present invention means that a plurality of FIC chunks may be transmitted through one subframe. In FIG. 14, the contents of two FIC chunks may be the same or may be different from each other.

At this time, the FIC segment number shown in FIG. 14 indicates the FIC segment number in each FIC chunk, not the number of the FIC segment in each subframe. By doing so, the dependency between the FIC chunk and the subframe can be eliminated, thereby reducing the waste of the FIC segment.

In addition, the present invention may add a null FIC segment. The null FIC segment is used to process the remaining FIC segment when stuffing is required in the corresponding M / H frame despite repeated transmission of the FIC chunk. For example, suppose TNoG is 3 and the FIC chunk is divided into two FIC segments. In this case, if the FIC chunk is repeatedly transmitted through five subframes in one M / H frame, two FIC segments in one subframe (for example, the last subframe in chronological order) of the five subframes. Will only be sent. In this case, one null FIC segment is allocated to the corresponding subframe and transmitted. That is, the null FIC segment is used to align the boundary of the FIC chunk with the boundary of the M / H frame. At this time, since the null FIC segment is not an FIC segment divided from the FIC chunk, the FIC segment number is not assigned to the null FIC segment.

According to the present invention, when one FIC chunk is divided into a plurality of FIC segments and included in each data group of at least one subframe in an M / H frame, the present invention allocates the FIC chunk in reverse order from the last subframe on the M / H frame. do. According to an embodiment, when a null FIC segment is present, the null FIC segment is positioned in a subframe on the M / H frame so that the latest transmission is performed.

FIG. 15 illustrates an embodiment in which data of an FIC chunk is transmitted through eight FIC segments when the TNoG of the corresponding mobile broadcast is six. In this case, the amount of data to be transmitted through the FIC chunk is larger than the amount of FIC segments transmitted through one subframe. In this case, since the FIC segments divided from the FIC chunk are transmitted through two subframes as shown in FIG. 15, all necessary signaling data can be transmitted through one FIC chunk. Again, the number assigned to each FIC segment is the number of the FIC segment in the FIC chunk. That is, even if the data amount of the FIC chunk is larger than the data amount of the FIC segments transmitted through one subframe, some of the data of the FIC chunk cannot be transmitted.

In this case, in order to discard the null FIC segment without processing in the receiving system, identification information for distinguishing the null FIC segment is required.

According to an embodiment of the present invention, the FIC_type field in the header of the null FIC segment is used as identification information for identifying the null FIC segment. According to an embodiment of the present invention, the FIC_type field value in the header of the null FIC segment is set to '11' to distinguish the null FIC segment. That is, when the FIC_type field value of the null FIC segment is set to '11' and transmitted to the receiving system, the receiving system can discard the payload of the FIC segment in which the FIC_type field value is set to '11' without processing. . '11' is an embodiment to help understanding of the present invention, and any value that can distinguish the null FIC segment is possible if an appointment is made in advance between the transmitting / receiving side. It will not be limited. In addition, identification information for identifying the null FIC segment may be displayed using another field in the FIC segment header.

16 illustrates an embodiment of a syntax structure of an FIC segment header according to the present invention.

The FIC segment header may include an FIC_type field, an error_indicator field, an FIC_segment_num field, and an FIC_last_segment_num field. Description of each field is as follows.

The FIC_type field (2 bits) indicates a type of the corresponding FIC. If the field value is '00', this indicates that the corresponding FIC segment is an FIC segment that transmits a part of the FIC chunk. If the field value is '11', this indicates that the corresponding FIC segment is a null FIC segment transmitting stuffing data. The remaining values are reserved for future use. (A two bit field, which indicates when set to '00', the FIC-Segment is carrying a portion of an FIC-Chunk and when set to '11', the FIC-Segment is a NULL FIC-Segment, which carries stuffing data.Other values are reserved for future use.).

The error_indicator field (1 bit) indicates whether an error has occurred in a corresponding FIC segment during transmission. The error_indicator field (1 bit) is set to '1' when an error occurs and '0' when there is no error. That is, when there is an error that cannot be recovered during the construction of the FIC segment, this field is set to '1'. This field allows the receiving system to recognize the presence or absence of an error in the FIC segment.

The FIC_seg_number field (4 bits) indicates the number of the corresponding FIC segment when one FIC chunk is divided into a plurality of FIC segments and transmitted. For example, if the FIC segment is the first FIC segment of the FIC chunk, the FIC_seg_number field value is set to 0x0, and if the second FIC segment, the FIC_seg_number field value is set to 0x1. That is, the FIC_seg_number field is incremented by 1 with each additional FIC segment in the FIC chunk. (A 4-bit unsigned integer number field which gives the number of this FIC-Segment.For the first FIC-Segment of an FIC-Chunk , the value of this field shall be set to 0x0.This field shall be incremented by one with each additional segment in the FIC chunk). If the FIC chunk is divided into four FIC segments, the value of the FIC_seg_number field of the last FIC segment of the FIC chunk is indicated by 0x3.

The FIC_last_seg_number field (4 bits) indicates the number of the last FIC segment (ie, the FIC segment having the highest FIC_segment_num field value) of the complete FIC chunk (A 4-bit unsigned integer number field which gives the number of the last FIC Segment (ie, the FIC Segment with the highest FIC_segment_num) of the complete FIC Chunk).

In this case, since the conventional FIC segment numbers are sequentially assigned to the FIC segments in one subframe, the last FIC segment number and the TNOG always correspond in this case. However, in the FIC segment number allocation scheme according to the present invention, the last FIC segment number and TNOG do not always coincide. That is, they may or may not match. The TNoG is the number of all data groups allocated to one subframe. For example, if TNoG is 6 and the FIC chunk is divided into 8 FIC segments, the TNoG is 6 and the last FIC segment number is 8.

In another embodiment of the present invention, the null FIC segment may be distinguished using a value of the FIC_segment_num field in the FIC segment header. That is, since the FIC segment number is not assigned to the null FIC segment, the transmitting system allocates and transmits null data to the FIC_segment_num field value of the null FIC segment, and the receiving system assigns null data to the FIC_segment_num field value. It can also be recognized as an FIC segment. Instead of null data, data previously promised by the transmission / reception system may be allocated to the FIC_segment_num field value.

As such, the FIC chunk may be divided into a plurality of FIC segments and transmitted through one subframe, or may be transmitted through a plurality of subframes. In addition, only FIC segments divided from one FIC chunk may be transmitted through one subframe, and FIC segments divided from a plurality of FIC chunks may be transmitted through one subframe. In this case, the number assigned to each FIC segment is not a number in the corresponding subframe, but a number in the corresponding FIC chunk (that is, a value of the FIC_seg_number field). In addition, a null FIC segment may be transmitted to align the boundary of the M / H frame and the boundary of the FIC chunk. In this case, a segment number is not assigned to the null FIC segment.

In the present invention, as described above, one FIC chunk may be transmitted through a plurality of subframes, and a plurality of FIC chunks may be transmitted through one subframe, but FIC segments are interleaved and transmitted in units of subframes. In one embodiment.

FIG. 17 illustrates a case in which one FIC chunk is transmitted through a plurality of subframes, or when a plurality of FIC chunks are transmitted through one subframe, as shown in FIGS. It is an example.

That is, the signaling decoder 118 of the receiving system collects the FIC data of the signaling information region in the data group for each subframe, performs deinterleaving on a subframe basis, and then performs RS decoding on the deinterleaved FIC segment to perform FIC. Output to the handler 121. The FIC segment buffer of the FIC handler 121 temporarily stores the RS decoded FIC segment and outputs it to the FIC segment parser. The FIC segment parser extracts and analyzes the FIC segment header, collects FIC segments constituting one FIC chunk according to the analysis result, and restores (or constructs) one FIC chunk by removing the FIC segment header of the collected FIC segments. do. As an example, the FIC segment parser collects FIC segments constituting one FIC chunk using the FIC_segment_num field and the FIC_last_segment_num field in the FIC segment header. The recovered FIC chunk is output to an FIC chunk parser. The FIC chunk parser extracts and analyzes the header of the input FIC chunk, and extracts signaling data included in the payload of the corresponding FIC chunk according to the analysis result and outputs it to the service manager 122.

That is, the FIC segment parser extracts and analyzes the header of the FIC segment input after buffering, and finds an FIC segment having a value of 0 in the FIC_segment_num field, that is, an FIC segment including the first byte of data of the FIC chunk. When the first FIC segment of the FIC chunk is found, the FIC segments are sequentially collected from the first FIC segment to the FIC segment where the FIC_segment_num field value is the same as the FIC_last_segment_num field value. The FIC chunk is formed by removing the FIC segment header of the collected FIC segments and outputs the FIC chunk.

 For example, assume that the TNoG of the corresponding mobile broadcast is 6 and the FIC chunk is divided into five FIC segments and transmitted as shown in FIG. 17. 17, it can be seen that FIC segments of one FIC chunk are transmitted through two subframes, or FIC segments of two FIC chunks are transmitted in one subframe, but deinterleaving is performed in units of subframes. . After collecting five FIC segments from the FIC segment having the FIC_segment_num field value of 0 to the FIC segment having the FIC_segment_num field value of 4, and removing each FIC segment header from the five FIC segments, one FIC chunk is restored. In other words, when the payloads of all five FIC segments are collected, one FIC chunk is restored (or configured). In this case, the null FIC segment is identified through the FIC_type field in the corresponding null FIC segment header and is discarded without being used in the FIC chunk restoration process.

FIG. 18 illustrates an example in which the reception system recovers the FIC chunk when the TNoG of the corresponding mobile broadcast is 6 and the FIC chunk is divided into eight FIC segments and transmitted.

In FIG. 18, although FIC segments of one FIC chunk are transmitted through two subframes, it can be seen that deinterleaving is performed in units of subframes. Since the FIC chunk restoration process in FIG. 18 is also substantially the same as the restoration process in FIG. 17, the description of FIG.

That is, in FIG. 18, after collecting eight FIC segments from the FIC segment having the FIC_segment_num field value of 0 to the FIC segment having the FIC_segment_num field value of 7, and removing each segment header from the eight FIC segments, one FIC chunk is restored. do. In other words, when the payloads of all eight FIC segments are collected, one FIC chunk is restored (or configured). In this case, the null FIC segment is identified through the FIC_type field in the corresponding null FIC segment header and is not used in the FIC chunk restoration process.

Meanwhile, suppose that a plurality of FIC chunks having different protocol versions are transmitted through one M / H frame, and the receiving system can process all of the plurality of FIC chunks having different protocol versions.

At this time, if the FIC segments divided from the plurality of FIC chunks having different protocol versions are normally received without error, the plurality of FIC chunks having different protocol versions are normally restored in the receiving system.

However, if an error due to burst noise occurs in FIC segments divided from a plurality of FIC chunks having different protocol versions, the reception system may not normally restore a plurality of FIC chunks having different protocol versions.

For example, suppose that a FIC chunk having a major protocol version of '00' and a FIC chunk having a major protocol version of '01' are simultaneously transmitted on one FIC, that is, one M / H frame. In addition, as shown in FIG. 19A, FIC segments 4 to 7 delivering FIC chunks of major protocol version '00' and FIC segments 0 to 3 delivering major protocol version '01' are not received due to an error due to burst noise. I assume you did.

In this case, the receiving system collects eight FIC segments from the FIC segment having the FIC_segment_num field value of 0 to the FIC segment having the FIC_segment_num field value of 7 by using the FIC_segment_num and FIC_last_segment_num fields in the FIC segment header. The FIC segment header is removed to form one FIC chunk as shown in FIG. 19B. In this case, since the FIC segment having the FIC_segment_num field value of 0 is the FIC segment divided from the FIC chunk having the major protocol version of '00', in the receiving system, the major protocol version of the FIC chunk configured as shown in FIG. 19 (b) is '00. Recognize.

However, in the case of the FIC chunk of FIG. 19B, the FIC segments 0 to 3 are FIC segments transmitting data of the FIC chunk having a major protocol version of '00', and the FIC segments 4 to 7 have a major protocol version of ' FIC segments that carry data of FIC chunks that are 01 '.

Therefore, when burst noise causes loss in FIC segments, the receiving system recognizes FIC segments carrying two different protocol versions of FIC chunks as FIC segments carrying one protocol version of FIC chunks. And restoring the FIC chunk may occur. In addition, in the receiving system, an error occurs in the FIC chunk restoration as described above, but a problem occurs in that the FIC chunk restoration is not recognized. As a result, serious problems may occur in obtaining and restoring an RS frame corresponding to an ensemble of a desired mobile service.

According to an embodiment of the present invention, in order to solve this problem, the protocol version information of the FIC chunk is transmitted through the FIC segment header of each FIC segment.

According to an embodiment of the present invention, the protocol version information of the FIC chunk transmitted through the FIC segment header is at least one of major protocol version information and minor protocol version information of the corresponding FIC chunk.

20 shows another embodiment of a syntax structure of an FIC segment header according to the present invention. That is, the FIC_Chunk_major_protocol_version field is further added in the syntax structure of the FIC segment header of FIG. 16.

That is, the FIC segment header of FIG. 20 may include an FIC_type field, an FIC_Chunk_major_protocol_version field, an error_indicator field, an FIC_segment_num field, and an FIC_last_segment_num field. Since description of the remaining fields except for the FIC_Chunk_major_protocol_version field is described with reference to FIG. 16, a description thereof will be omitted in FIG. 20.

In an embodiment, the FIC_Chunk_major_protocol_version field allocates 2 bits and indicates a major protocol version of the corresponding FIC chunk. That is, the FIC_Chunk_major_protocol_version field in the FIC segment header is equal to the value of the FIC_major_protocol_version field in the corresponding FIC chunk header.

A detailed description of the major protocol version of the FIC chunk syntax may be omitted by referring to the description of the FIC chunk header of FIG. 9 described above.

FIG. 21 shows an example of recovering FIC chunks by receiving FIC segments having the FIC segment header as shown in FIG. In this case, for example, two FIC chunks are transmitted on one FIC (i.e., one M / H frame), and the major protocol versions of the two FIC chunks are different from each other. Assume that it is a receiving system that can handle both other FIC chunks.

That is, as shown in (a) of FIG. 21, an FIC chunk having a major protocol version of '00' and an FIC chunk having a major protocol version of '01' are simultaneously transmitted on one FIC (ie, one M / H frame). In this case, it is assumed that FIC segments 4 to 7 carrying the FIC chunk of major protocol version '00' and FIC segments 0 to 3 carrying the major protocol version '01' are not received due to an error due to burst noise.

At this time, the receiving system restores the FIC chunk by using the FIC_segment_num field, the FIC_last_segment_num field, and the FIC_Chunk_major_protocol_version field in the FIC segment header.

In other words, the FIC_Chunk_major_protocol_version field value from FIC segments 0 to 3 and the FIC_Chunk_major_protocol_version field values from FIC segments 4 to 7 are different. It does not consist of.

In the FIC handler 121 of the reception system according to the present invention, four FIC segments are collected from an FIC segment having an FIC_segment_num field value of 0 to an FIC segment having a FIC_segment_num field value of 3, as shown in FIG. Each segment header is removed from the segments to form an FIC chunk with a major protocol version of '00'. In addition, four FIC segments are collected from the FIC segment with the FIC_segment_num field value of 4 to the FIC segment with the FIC_segment_num field value of 7, and each segment header is removed from the four FIC segments to obtain an FIC chunk having a major protocol version of '01'. Configure.

By doing so, when burst noise causes losses in the FIC segments, the FIC segments carrying the FIC chunks of two different major protocol versions in the receiving system are the FIC segments carrying the FIC chunks of one major protocol version. This can prevent the problem of recognizing this.

That is, the present invention allocates major protocol version information of the corresponding FIC chunk to the FIC segment header, so that FIC segments of the same major protocol version are mixed even if FIC segments of the FIC chunk having different major protocol versions are mixed on one M / H frame. You can only collect them to restore the FIC chunk.

At this time, if the FIC chunk is restored as shown in FIG. 21, the FIC chunk is not completely restored. For example, an FIC chunk with a major protocol version of '00' has four FIC segments missing from an FIC segment with a FIC_segment_num field value of 4 to an FIC segment with a FIC_segment_num field value of 7, with a major protocol version of '01'. The FIC chunk has no four FIC segments from the FIC segment having the FIC_segment_num field value of 1 to the FIC segment having the FIC_segment_num field value of 3.

In this case, therefore, the embodiment does not restore the FIC chunk. That is, when FIC segments of the same major protocol version are collected, the FIC chunk is not restored if it is smaller than the number of FIC segments divided from the corresponding FIC chunk.

In this case, the process of collecting the FIC segments to restore one FIC chunk may be performed in one subframe unit or may be performed in one M / H frame unit. This is because the same FIC chunk may be repeatedly transmitted on one subframe, and the same FIC chunk may be repeatedly transmitted on one M / H frame. In addition, it may be performed in a predetermined number of subframe units or a predetermined number of M / H frame units.

Also assume that FIC chunks with different major protocol versions coexist on one M / H frame, and the receiving system can handle all FIC chunks with different major protocol versions. In this case, the FIC chunk may be configured by checking the current FIC segment number, the last FIC segment number, and the major protocol version of each FIC segment and collecting the FIC segments of the major protocol version such as the major protocol version of the receiving system.

Suppose that an FIC chunk having a different major protocol version coexists on one M / H frame, and the receiving system can process only one major protocol version thereof. In this case, the major protocol version that can handle recovers the FIC chunks from the signaled FIC segments.

Meanwhile, the present invention transmits mapping (or configuration) information between an ensemble in an M / H frame and a mobile service using an FIC chunk as described above. At this time, if reconfiguration occurs in which mapping information between the ensemble and the mobile service in the current M / H frame and mapping information between the ensemble and the mobile service in the next M / H frame are different, at least in the M / H frame before the reconfiguration occurs. According to an embodiment of the present invention, signaling information between an ensemble in a corresponding M / H frame in which reconfiguration occurs and a mobile service is previously signaled through one FIC chunk. In the present invention, an M / H frame before reconfiguration occurs is called a current M / H frame, and an M / H frame where reconfiguration occurs is called a next M / H frame.

The present invention also provides an FIC chunk signaling mapping information between an ensemble and a mobile service in a current M / H frame and an FIC chunk signaling mapping information between an ensemble and a mobile service in a next M / H frame on one M / H frame. In parallel, the transmission is an embodiment. At this time, on the corresponding M / H frame, the FIC chunk signaling the mapping information between the ensemble of the next M / H frame and the mobile service is placed later in time than the FIC chunk signaling the mapping information between the ensemble of the current M / H frame and the mobile service. In one embodiment it is transmitted. That is, in the receiving system, the FIC chunk signaling the mapping information between the ensemble of the current M / H frame and the mobile service is first received in the corresponding M / H frame, and the mapping information between the ensemble of the next M / H frame and the mobile service is signaled. The FIC chunk will be received later.

In this case, when the FIC chunk is received and restored by the FIC handler 121 of the receiving system, signaling information included in the payload of the corresponding FIC chunk is ensemble of the current M / H frame using the current_next_indicator field in the header of the restored FIC chunk. Whether it is mapping information between the mobile service and the mapping information between the ensemble of the next M / H frame and the mobile service. For convenience of description, the present invention may refer to mapping information between an ensemble of an M / H frame and a mobile service as ensemble configuration information of an M / H frame.

FIG. 22 illustrates an example in which reconfiguration occurs in which ensemble configuration information of a current M / H frame and ensemble configuration information of a next M / H frame are different.

In FIG. 22, the part shown as ..., k-1, k, k + 1, k + 2, k + 3, ... at the top means an M / H frame. In addition, an example of reconfiguration occurs in the k + 2th M / H frame. That is, as illustrated in FIG. 22, two ensembles having a TNoG of 4 are transmitted in an M / H frame before reconfiguration occurs, and three ensembles having a TNoG of 7 are transmitted in an M / H frame having a reconfiguration occurred. It is becoming.

As shown in FIG. 22, when reconfiguration occurs due to a change in the number of ensembles transmitted in M / H frames, the number of mobile services transmitted in each ensemble, the number of TNoGs in each subframe, etc., major and minor FIC chunks are generated. The protocol version information is not changed, and the value of the FIC_version field in the TPC data is changed.

22 shows an example in which the value of the FIC_version field in the TPC data is updated to 6 by increasing 1 in the k + 1th M / H frame, and the value of the current_next_indicator field in the header of the FIC chunk is also changed to 0 in the k + 1th M / H frame. Is showing.

FIG. 23 illustrates that reconfiguration occurs in the k + 2th M / H frame, and the ensemble configuration information of the current M / H frame and the ensemble configuration information of the next M / H frame are transmitted in parallel in the k + 1th M / H frame. An embodiment of an RS frame acquisition process is shown.

Referring to the k + 1 th frame of FIG. 23, the FIC chunk signaling the ensemble configuration information of the current M / H frame is received and restored before the FIC chunk signaling the ensemble configuration information of the next M / H frame.

At this time, if the tuning of the physical channel including the ensemble desired to receive is performed in the middle portion of the k + 1st M / H frame as shown in FIG. It can be obtained in an M / H frame. That is, when reconfiguration occurs in which mapping information between an ensemble in a mobile broadcast and a mobile service is changed, the ensemble configuration information of an M / H frame in which reconfiguration occurs in the FIC chunk transmitted in the M / H frame immediately before the reconfiguration occurs is generated in advance. By signaling, it is possible to quickly obtain the ensemble configuration information of the M / H frame in which the corresponding reconfiguration occurs. The RS frame transmitted to the k + 2th M / H frame can be completely recovered by using the ensemble configuration information of the k + 2th M / H frame obtained from the k + 1th M / H frame. .

FIG. 24 is identical to FIG. 23 except that tuning of the physical channel containing the ensemble desired to be received is done at the end of the k-th M / H frame.

In this case, when the RS system corresponding to about 20% of one M / H frame is not received by the receiving system, RS-CRC decoding and SCCC decoding may restore the entire RS frame.

For example, as shown in FIG. 24, tuning of a physical channel including an ensemble desired to be received is made at the end of the k th M / H frame, and k + from the first FIC chunk of the k + 1 th M / H frame. Assume that the signaling information of the first M / H frame is obtained completely. At this time, while receiving the first FIC chunk of the k + 1 st M / H frame, the RS frame transmitted to the k + 1 st M / H frame is not received. However, if the unreceived portion corresponds to about 20% of the k + 1th M / H frame, RS-CRC decoding and SCCC decoding may be used to restore the entire RS frame transmitted to the k + 1th M / H frame. It becomes possible. In addition, even if reconfiguration occurs in the k + 2th M / H frame, the signaling information of the k + 2th M / H frame acquired in the k + 1th M / H frame is transmitted to the k + 2th M / H frame. The RS frame can be completely recovered.

As described above, according to the tuning time of the physical channel and the FIC chunk data structure in the M / H frame immediately before reconfiguration occurs, the present invention can acquire and restore the RS frame more quickly to serve the user.

However, when the FIC chunk signaling the ensemble configuration information of the current M / H frame and the FIC chunk signaling the ensemble configuration information of the next M / H frame coexist in one M / H frame, one M / H Problems that occur when different protocol versions of the FIC chunks are received in H frames may also occur at this time.

That is, one FIC chunk is recovered from the FIC segment carrying the FIC chunk signaling the ensemble configuration information of the current M / H frame and the FIC segments carrying the FIC chunk signaling the ensemble configuration information of the next M / H frame. Error may occur. If an error occurs during FIC chunk restoration as described above, the ensemble configuration information of the next M / H frame cannot be properly obtained from the restored FIC chunk. Therefore, the RS frame transmitted to the next M / H frame cannot be properly obtained and restored. do.

For example, the order of the FIC segments of the FIC chunk signaling the ensemble configuration information of the current M / H frame in one M / H frame and the FIC segments of the FIC chunk signaling the ensemble configuration information of the next M / H frame When mixed and received, the receiving system determines whether the received FIC segment is an FIC segment belonging to the FIC chunk signaling the ensemble configuration information of the current M / H frame, or an FIC segment belonging to the FIC chunk signaling the ensemble configuration information of the next M / H frame. The problem described above may arise because the recognition is unknown. Also, even if the FIC segments are lost due to an error due to burst noise, the receiving system determines whether the received FIC segment is an FIC segment belonging to the FIC chunk signaling the ensemble configuration information of the current M / H frame, or the ensemble configuration information of the next M / H frame. The above-described problem may also occur because it is not known whether the FIC segment belongs to the FIC chunk signaling.

Alternatively, the above-described problem may occur when the TPC data and the FIC segment are received as shown in FIG. 25.

That is, as shown in ① of FIG. 25, the value of the FIC_version field in the TPC data increases by one in the first FIC segment of the FIC chunk signaling the ensemble configuration information of the next M / H frame. Then, the receiving system exits the time slicing mode as shown in 2) of FIG. 25 and collects the FIC segments. As shown in (3) of FIG. 25, by using only the FIC_segment_num field and the FIC_last_segment_num field in each FIC segment header of the collected FIC segments, only FIC segments constituting one FIC chunk are collected and then each FIC segment in the order of FIC segment number. And remove the header of each arranged FIC segment. Then, one FIC chunk is configured as in ④ of FIG. 25. Then, the ensemble configuration information of the M / H frame is obtained from the configured FIC chunk, and according to the obtained ensemble configuration information, it enters the time slicing mode as shown in ⑤ of FIG.

However, looking at the collected FIC segments as shown in ③ of FIG. 25, the FIC segment of the FIC chunk signaling the ensemble configuration information of the current M / H frame and the FIC chunk of the FIC chunk signaling the ensemble configuration information of the next M / H frame are shown. You can see that the segments are mixed. That is, (3) of FIG. 25 is an example of incorrectly collecting the FIC segments. This is because it is not known whether each FIC segment is an FIC segment belonging to the FIC chunk signaling the ensemble configuration information of the current M / H frame or an FIC segment belonging to the FIC chunk signaling the ensemble configuration information of the next M / H frame. .

When one FIC chunk is configured as shown in ④ of FIG. 25, the reception system determines that the FIC chunk is signaling ensemble configuration information of the next M / H frame. However, the FIC chunk includes some data of the FIC chunk signaling the ensemble configuration information of the current M / H frame. That is, ④ in FIG. 25 shows an example in which the FIC chunk is restored with wrong information. Therefore, since the ensemble configuration information obtained from the incorrectly restored FIC chunk is also wrong information, the RS frame transmitted in the next M / H frame cannot be properly obtained and restored.

In order to solve this problem, the present invention transmits M / H frame identification information through the FIC segment header of each FIC segment, wherein the M / H frame identification information includes the ensemble configuration information of the current M / H frame. According to an embodiment of the present invention, whether the FIC segment of the FIC chunk signaling the FIC chunk or the FIC chunk signaling the ensemble configuration information of the next M / H frame is signaled.

According to an embodiment of the present invention, the M / H frame identification information transmitted through the FIC segment header is a current_next_indicator field.

26 shows another embodiment of a syntax structure of an FIC segment header according to the present invention. That is, the current_next_indicator field is further added in the syntax structure of the FIC segment header of FIG. 20. According to an embodiment of the present invention, one bit is allocated to the current_next_indicator field.

That is, the FIC segment header of FIG. 26 may include an FIC_type field, an FIC_Chunk_major_protocol_version field, a current_next_indicator field, an error_indicator field, an FIC_segment_num field, and an FIC_last_segment_num field.

Detailed descriptions of the FIC_type field, the error_indicator field, the FIC_segment_num field, and the FIC_last_segment_num field will be omitted in FIG. 26.

In an embodiment, the FIC_Chunk_major_protocol_version field allocates 2 bits and indicates a major protocol version of the corresponding FIC chunk. In this case, the value of this field should be the same as the value of the FIC_major_protocol_version field in the corresponding FIC chunk header. A detailed description of the major protocol version of the FIC chunk syntax may be omitted by referring to the description of the FIC chunk header of FIG. 9 described above.

The current_next_indicator field allocates 1 bit in one embodiment. If the field value is set to 1, it indicates that the corresponding FIC segment transmits a part of the FIC chunk that can be applied to the current M / H frame. On the contrary, if the field value is set to 0, it indicates that the corresponding FIC segment transmits a part of the FIC chunk that can be applied to the next M / H frame. In the former case, the current version of the FIC chunk transmitted with the current_next_indicator field set to 1 is currently applied (which when set to '1' shall indicate that this FIC-Segment is carrying a portion of the FIC-Chunk which is applicable to the current M / H Frame.When this bit is set to '0', it shall indicate that this FIC-Segment is carrying a portion of the FIC-Chunk which will be applicable for the next M / H Frame.In the former case, the most recent version of the FIC-Chunk transmitted with the current_next_indicator bit set to '1' shall be currently applicable.).

In addition, the TPC data allocated and transmitted together with the FIC data in the signaling information area of the data group mainly include parameters used in a physical layer module and are transmitted without being interleaved. Is possible.

According to an embodiment of the present invention, when the FIC chunk is updated by using a characteristic that TPC data including the FIC_version field can be received for each slot, the receiving system uses the FIC_version field of the TPC data to identify an update of the corresponding FIC chunk. It is set as an Example. When an update of the corresponding FIC chunk is detected, it is possible to exit the time slicing mode and collect FIC segments.

27 shows an embodiment of a syntax structure of TPC data according to the present invention.

The TPC data includes a Sub-Frame_number field, a Slot_number field, a Parade_id field, a starting_Group_number (SGN) field, a number_of_Groups (NoG) field, a Parade_repetition_cycle (PRC) field, an RS_Frame_mode field, an RS_code_mode_primary field, an RS_code_mode_secondary field, an SC_CC_Block_mode_code_mode_code_mode_code_mode_code_out_code_mode_code_out_code_mode_code_mode_code_out_code_mode_code_out_code_mode_code_mode_code_out_code_mode_code_mode_code_out_code_mode_code_mode_code_out_code_mode_code_mode_code_outer_code_out_code_mode_code_mode_code_outer_code It may include a SCCC_outer_code_mode_C field, an SCCC_outer_code_mode_D field, a FIC_version field, a Parade_continuity_counter field, a total number of groups (TNoG) field, and a TPC_protocol_version field.

The Sub-frame_number field indicates the number of the current subframe in the corresponding M / H frame and is transmitted for M / H frame synchronization. The Sub-Frame_number field shall be the current Sub-Frame number within the M / H Frame, which is transmitted for M / H Frame synchronization.Its value shall range from 0 to 4).

The Slot_number field indicates the number of the current slot in the corresponding subframe and is transmitted for M / H frame synchronization. The Slot_number field value may have a value between 0 and 15 (The Slot_number field is the current Slot number within the Sub-Frame, which is transmitted for M / H Frame synchronization. Its value shall range from 0 to 15).

The Parade_id field indicates an identifier for identifying a parade to which the corresponding data group belongs. The Parade_id field value may be represented by 7 bits. The Parade_id field identifies the Parade to which this Group belongs.The value of this field may be any 7-bit value.Each Parade in a M / H transmission shall have a unique Parade_id). Communication of the Parade_id between the physical layer and the upper layer is made by Ensemble_id formed by adding 1 bit to the left of the Parade_id (Communication of the Parade_id between the physical layer and the management layer shall be by means of an Ensemble_id formed by adding one bit to the left of the Parade_id). Ensemble_id for distinguishing the primary ensemble transmitted through the parade is formed by displaying 0 in the added MSB, and Ensemble_id for distinguishing the secondary ensemble may be formed by displaying 1 in the added MSB (If the Ensemble_id is for the primary Ensemble delivered through this Parade, the added MSB shall be '0'.Otherwise, if it is for the secondary Ensemble, the added MSB shall be' 1 ').

The starting_Group_number (SGN) field shall be the first Slot_number for a Parade to which this Group belongs, as determined by Equation 1 (after the Slot numbers for all preceding Parades have been calculated).) The SGN and NoG fields are used to obtain a slot number assigned to one parade in the corresponding subframe.

The number_of_Groups (NoG) field shall be the number of Groups in a Sub-Frame assigned to the Parade to which this Group belongs, minus 1, eg, NoG = 0 implies that one Group is allocated to this Parade in a Sub-Frame). The NoG field value may have a value between 0 and 7. Slot numbers assigned to the corresponding parade may be calculated from SGN and NoG.

The PRC field indicates a repetition period of a parade transmitted in M / H frames. (The Parade_repetition_cycle (PRC) field shall be the cycle time over which the Parade is transmitted, minus 1, specified in units of M / H Frames) .

The RS_Frame_mode field indicates whether one RS frame or two RS frames are transmitted in one parade.

The RS_code_mode_primary field indicates an RS code mode for a primary RS frame.

The RS_code_mode_secondary field indicates an RS code mode for the secondary RS frame.

The SCCC_Block_mode indicates how M / H blocks in the data group are allocated to the SCCC block.

The SCCC_outer_code_mode_A field indicates the SCCC outer code mode for the area A in the data group.

The SCCC_outer_code_mode_B field indicates the SCCC outer code mode for the area B in the data group.

The SCCC_outer_code_mode_C field indicates the SCCC outer code mode for the area C in the data group.

The SCCC_outer_code_mode_D field indicates the SCCC outer code mode for the area D in the data group.

The FIC_version field indicates a version of FIC data. That is, the FIC_version field indicates the version of the corresponding FIC chunk data structure. The value of this field is set equally in all TPC data structures transmitted through one M / H frame. The value of the field is increased by 1 whenever there is an FIC segment in which the current_next_indicator field value is set to 0 in a subframe in which the TPC data is transmitted (This field represents the version of the FIC-Chunk data structure. this field shall be set equally to all the TPC data structure delivered through one M / H frame and shall be incremented by one whenever there is a FIC-Segment with current_next_indicator field set to '0' in the M / H Subframe, where the TPC data structure is delivered.). For example, when the number of mobile services included in ensemble 0 is changed from 2 to 3, the value of the FIC_version field is changed.

The Parade_continuity_counter field increases from 0 to 15, and increases by 1 for every (PRC + 1) M / H frame. For example, if PRC = 011, the Parade_continuity_counter field is incremented every fourth M / H frame.

The TNoG field indicates the number of all data groups allocated in one subframe. In other words, it is the sum of the data groups of all parades in one subframe. The value of this field is increased from 0-16. The value of this field shall be the total number of groups to be transmitted during a Sub-Frame.In other words, it is the sum of NoGs of all Parades within a Sub-Frame.Its value shall be in the range of 0 through 16 inclusive.TNoG is used both for current M / H Frame information and for signaling in advance.).

The tpc_protocol_version field allocates 5 bits in one embodiment, and indicates a version of the TPC syntax structure (A 5-bit unsigned integer field that represents the version of the structure of the TPC syntax.The 2 most-significant bits are the major version level; the least-significant three bits are the minor version level, to be interpreted as follows: A change in the major version level shall indicate a non-backward-compatible level of change.A change in the minor version level, provided the major version level remains the same, shall indicate a backward-compatible level of change.The initial value for this field shall be '11111'.At least one of the bits shall be changed so as to form a previously unused value of this field each time the TPC structure is changed by a future version of this standard.Other values of the version may be used in future to signal use of the reserved bits or a change in the defined syntax.The first such change shall be to '00 'or '000', so that this field increments in the same manner as other fields for later changes.).

 The information included in the TPC data is only an embodiment for better understanding of the present invention, and the present invention is not limited to the above embodiments because addition and deletion of the information included in the TPC data can be easily changed by those skilled in the art. Will not.

At this time, the TPC data for each parade (except for the Sub-Frame_number field and the Slot_number field) does not change their values during one M / H frame. The same information is repeatedly transmitted through all data groups in the parade for one M / H frame. By doing so, reception of TPC data is extremely robust, and reception performance can be improved. Since the Sub-Frame_number field and the Slot_number field are incremented counter values, the fields are robust due to transmission of expected values regularly (Since the TPC parameters (except Sub-Frame_number and Slot_number) for each Parade do not change their values during an M / H Frame, the same information is transmitted repeatedly through all M / H Groups belonging to that Parade during an M / H Frame.This allows very robust and reliable reception of the TPC data.Because the Sub- Frame_number and the Slot_number are increasing counter values, they also are robust due to the transmission of regularly expected values).

FIG. 28 shows an example of recovering FIC chunks by receiving FIC segments having the FIC segment header as shown in FIG. 26 and TPC data having the structure as shown in FIG.

That is, when the value of the FIC_versiopn field of the TPC data structure increases by 1 as shown in ① of FIG. 28, the reception system determines that the data structure of the corresponding FIC chunk has been updated. Collect segments.

As shown in ③ of FIG. 28, only FIC segments constituting one FIC chunk are collected using the FIC_segment_num field, FIC_last_segment_num field, and current_next_indicator field in each FIC segment header of the collected FIC segments, and then in order of FIC segment number. Arrange the FIC segments and remove the header of each arranged FIC segment. Then, one FIC chunk is configured as in ④ of FIG. 28. Then, the ensemble configuration information of the M / H frame is obtained from the configured FIC chunk, and according to the obtained ensemble configuration information, it enters the time slicing mode as shown in ⑤ of FIG. In case of ③ of FIG. 28, when only FIC segments constituting one FIC chunk are collected, the FIC_Chunk_major_protocol_version field in the FIC segment header may be additionally used. That is, by using only the segment_num field, the FIC_last_segment_num field, the current_next_indicator field, and the FIC_Chunk_major_protocol_version field, only the FIC segments of the FIC chunk signaling the ensemble configuration information of the next (or current) M / H frame of the same protocol version are collected. The FIC chunks are formed by arranging each FIC segment and removing the header of each arranged FIC segment.

When the FIC chunk is configured as described above, it can be seen that the FIC chunk is composed of FIC chunks of the FIC chunk signaling the ensemble configuration information of the next M / H frame as shown in ④ of FIG. 28.

Accordingly, in the receiving system, the FIC segment of the FIC chunk signaling the ensemble configuration information of the current M / H frame and the FIC segments of the FIC chunk signaling the next M / H ensemble configuration information are prevented to form a single FIC chunk. can do. That is, the present invention identifies an M / H frame that can identify whether signaling information transmitted as a payload of a corresponding FIC segment is signaling information of a current M / H frame or signaling information of a next M / H frame in an FIC segment header. By allocating the information, the receiving system can obtain the ensemble configuration information of the next M / H frame from the FIC chunk without error, thereby properly obtaining and restoring the RS frame transmitted to the next M / H frame. do.

29 and 30 are flowcharts illustrating one embodiment of a process of recovering FIC chunks from FIC segments according to the present invention.

29 and 30 assume that FIC chunks of different FIC chunk major protocol versions are received on one M / H frame.

That is, when the physical transport channel including the mobile service selected by the user is tuned (S501), the mobile broadcast signal (that is, M / H signal) for transmitting the mobile service selected by the user is identified from the tuned physical transport channel ( S502). In operation S503, a subframe number through which the identified mobile broadcast signal is transmitted and a slot number allocated to the subframe are found.

The data groups received through the slots of the subframe found in S503 are collected (S504). PCCC decoding is performed on the FIC data received in each signaling information region of the collected data groups, deinterleaving is performed in units of subframes, and RS decoding is performed in reverse of the transmitting side (S505). Then, the FIC segments are restored for each subframe.

In this case, the deinterleaving is not performed on the TPC data received in the signaling information region, and the PCCC decoding and the RS decoding are performed in the reverse direction of the transmitting side.

When the step S505 is performed, the segment header of the first received FIC segment is examined and the first received FIC segment is stored in the FIC segment buffer in the FIC handler 121 (S506). That is, through the inspection, the number of the FIC segment, the number of the last FIC segment, the FIC chunk major protocol version, and the like are obtained from the FIC_segment_num field, the FIC_last_segment_num field, and the FIC_Chunk_major_protocol_version field included in the segment header of the FIC segment.

Then, it is checked whether the major protocol version set in the reception system (or receiver) is the same as the FIC chunk major protocol version acquired in step S506 (S507).

If the two major protocol versions are not the same in S507, the FIC segment stored in the FIC segment buffer is removed (S508). Next, after checking the segment header of the received FIC segment, the FIC segment is stored in the FIC segment buffer (S509). In this case, the number of the FIC segment, the number of the last FIC segment, the FIC chunk major protocol version, and the like are obtained from the FIC_segment_num field, the FIC_last_segment_num field, and the FIC_Chunk_major_protocol_version field of the segment header of the FIC segment.

On the other hand, if it is confirmed in S507 that the two major protocol versions are the same, the number of the FIC segment, the number of the last FIC segment, the FIC chunk major protocol from the FIC_segment_num field, the FIC_last_segment_num field, and the FIC_Chunk_major_protocol_version field of the next received FIC segment Obtain a version and more.

Then, it is checked whether the obtained FIC chunk major protocol version information is the same as the FIC chunk major protocol version information of the FIC segment stored in the FIC segment buffer (S511).

If it is confirmed in S511 that the two major protocol version information is the same, it is checked whether the FIC segment of the S510 is already stored in the FIC segment buffer (S512). This can be known from the FIC segment number (ie, FIC_segment_num field) and FIC chunk major protocol version (FIC_Chunk_major_protocol_version field) obtained in S510.

If it is confirmed in S512 that it is already stored in the FIC segment buffer, the FIC segment is discarded without being stored (S513). However, if it is determined in S512 that the FIC segment buffer is not stored, the FIC segment is stored in the FIC segment buffer (S514).

After S513 or S514 is performed, it is checked whether all FIC segments of the FIC chunk corresponding to the FIC chunk major protocol version are received and stored in the FIC segment buffer (S515). This can be confirmed using the number of the current FIC segment, the number of the last FIC segment, and the FIC Chunk Major Protocol version. In this case, S515 may be performed whenever one FIC segment is stored in the FIC segment buffer or may be performed after receiving all FIC segments on one M / H frame. Alternatively, the operation may be performed for each predetermined subframe unit or for each predetermined number of M / H frame units. Alternatively, the operation may be performed until all FIC segments divided from the FIC chunk are collected.

If it is confirmed in S515 that the FIC segments of the FIC chunk are not all stored in the FIC segment buffer, the process proceeds to S510 and repeats the above process for the next FIC segment.

If it is confirmed in S515 that all the FIC segments of the FIC chunk are received and stored in the FIC segment buffer, the FIC segments stored in the FIC segment buffer are sorted in the order of FIC segment number and then each FIC segment header is removed (S516). . Then, one FIC chunk is recovered from the payloads of the FIC segments (S517).

As such, the major protocol version of the FIC chunk received through the segment header of each FIC segment constituting the FIC chunk has the same value as the major protocol version received by the header of the corresponding FIC chunk. In addition, when FIC segments of a plurality of FIC chunks having different FIC chunk major protocol versions signaled to the receiver, the receiver collects FIC segments in which the same FIC chunk major protocol version as the major protocol version set in the receiver is signaled and collects FIC chunks. In one embodiment to configure the.

The present invention described so far is not limited to the above-described embodiments, and can be modified by those skilled in the art as can be seen from the appended claims, and such modifications are the scope of the present invention. Belongs to.

1 is a block diagram showing an embodiment of a receiving system according to the present invention;

2 illustrates an embodiment of a structure of a data group according to the present invention.

3 illustrates an RS frame according to an embodiment of the present invention.

4 illustrates an example of an M / H frame structure for transmitting and receiving mobile service data according to the present invention.

5 illustrates an example of a general VSB frame structure.

6 is a diagram showing an embodiment of a data transmission structure for a mobile service according to the present invention;

7 illustrates a hierarchical signaling structure according to an embodiment of the present invention.

8 illustrates an embodiment of a syntax structure of an FIC chunk according to the present invention.

9 illustrates an embodiment of a syntax structure of an FIC chunk header according to the present invention.

10 is a diagram illustrating an embodiment in which a minor protocol version of an FIC chunk is changed according to the present invention.

11 illustrates an embodiment of the operation of an existing receiver when a minor protocol version of an FIC chunk is changed according to the present invention.

12 illustrates an embodiment of a syntax structure of an FIC chunk payload according to the present invention.

13 illustrates an embodiment of a segmentation process of an FIC chunk according to the present invention.

14 illustrates an embodiment of transmitting FIC segments according to the present invention.

15 illustrates another embodiment of transmitting FIC segments according to the present invention.

16 illustrates an embodiment of a syntax structure of an FIC segment header according to the present invention.

17 illustrates an embodiment of receiving FIC segments and restoring an FIC chunk according to the present invention.

18 illustrates another embodiment of receiving FIC segments and restoring FIC chunks in accordance with the present invention.

19 illustrates an example of an error that may occur when restoring an FIC chunk by receiving FIC segments according to the present invention.

20 illustrates another embodiment of a syntax structure of an FIC segment header according to the present invention.

21 illustrates another embodiment of receiving FIC segments and restoring an FIC chunk according to the present invention.

22 shows an example in which the data structure of an FIC chunk is changed according to the present invention.

FIG. 23 illustrates an embodiment of a process of recovering an RS frame when an FIC chunk is previously signaled according to the present invention; FIG.

FIG. 24 illustrates another embodiment of a process of recovering an RS frame when an FIC chunk is signaled in advance according to the present invention; FIG.

25 illustrates another example of an error that may occur when receiving FIC segments and restoring an FIC chunk according to the present invention.

FIG. 26 illustrates another embodiment of a syntax structure of an FIC segment header according to the present invention. FIG.

27 illustrates another embodiment of a syntax structure of TPC data according to the present invention.

28 illustrates another embodiment of receiving FIC segments and restoring an FIC chunk according to the present invention.

29 and 30 are flowcharts illustrating a process of restoring an FIC chunk by receiving FIC segments according to the present invention.

Claims (15)

The transmission frame consists of a plurality of subframes for receiving at least one ensemble and at least one mobile service, one subframe consists of a plurality of slots, and the mobile service data and the FIC segment are stored from the at least one slot. Receiving an included broadcast signal; Extract FIC segments signaled by different FIC chunk major protocol versions from the broadcast signal, and obtain the number of the corresponding FIC segment, the number of the last FIC segment, and the FIC chunk major protocol version information from each segment header of the extracted FIC segments. Doing; And Restoring an FIC chunk including signaling information between an ensemble in the transport frame and a mobile service from the payload of the FIC segments based on the obtained number of the corresponding FIC segment, the number of the last FIC segment, and the FIC chunk major protocol version information. A data processing method of a receiving system comprising the step of. The method of claim 1, wherein the FIC chunk recovery step is And restoring the FIC chunk from the payload of FIC segments in which the same FIC chunk major protocol version as the FIC chunk major protocol version set in the receiving system is signaled. The method of claim 1, The FIC chunk major protocol version information obtained from the segment header of the FIC segment used to restore the FIC chunk has the same value as the FIC major protocol version information allocated to the chunk header of the FIC chunk. Treatment method. The method of claim 1, The FIC chunk is composed of a 5 byte chunk header and a variable length chunk payload, and the chunk payload includes signaling information between an ensemble in the transmission frame and a mobile service. The method of claim 4, wherein The FIC chunk is segmented into 35 bytes and allocated to the segment payload of each FIC segment and received. The method of claim 5, And the lowest FIC segment number is assigned to the FIC segment number of the segment header of the FIC segment including the first byte of the FIC chunk. The method of claim 5, The last FIC segment of the FIC chunk is N (N

And 0) stuffing data bytes, wherein the number of stuffing data bytes is determined by the following equation. Number of stuffing data bytes (N) = 35-j, j = (5 + number of bytes of signaling data to be inserted into the payload of the FIC chunk) mod 35. The method of claim 1, Extracting transmission parameter channel (TPC) data from the broadcast signal, the transmission parameter channel (TPC) data comprising identification information for identifying an update of the FIC chunk data structure. The transmission frame consists of a plurality of subframes for receiving at least one ensemble and at least one mobile service, one subframe consists of a plurality of slots, and the mobile service data and the FIC segment are stored from the at least one slot. Receiving unit for receiving the included broadcast signal; Extract FIC segments signaled by different FIC chunk major protocol versions from the broadcast signal, and obtain the number of the corresponding FIC segment, the number of the last FIC segment, and the FIC chunk major protocol version information from each segment header of the extracted FIC segments. A first processing unit; And Restoring an FIC chunk including signaling information between an ensemble in the transport frame and a mobile service from the payload of the FIC segments based on the obtained number of the corresponding FIC segment, the number of the last FIC segment, and the FIC chunk major protocol version information. Receiving system comprising a second processing unit. The method of claim 9, wherein the second processing unit And a system for restoring the FIC chunk from the payload of the FIC segments signaled by the same FIC chunk major protocol version as configured in the receiving system. The method of claim 9, The FIC chunk major protocol version information obtained from the segment header of the FIC segment used to recover the FIC chunk has the same value as the FIC major protocol version information allocated to the chunk header of the FIC chunk. The method of claim 9, The FIC chunk is composed of a 5 byte chunk header and a variable length chunk payload, and the chunk payload includes signaling information between an ensemble in the transmission frame and a mobile service. 13. The method of claim 12, The FIC chunk is segmented into 35 bytes and allocated to the segment payload of each FIC segment and received. The method of claim 13, And the lowest FIC segment number is assigned to the FIC segment number of the segment header of the FIC segment including the first byte of the FIC chunk. The method of claim 13, The last FIC segment of the FIC chunk is N (N

And 0) stuffing data bytes, wherein the number of stuffing data bytes is determined by the following equation. Number of stuffing data bytes (N) = 35-j, j = (5 + number of bytes of signaling data to be inserted into the payload of the FIC chunk) mod 35.

Images