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

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

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

<p>Among digital broadcasts, the Vestigial Sideband (VSB) transmission method adopted as a digital broadcast standard in North America and Korea is a single carrier method, so the reception performance of the reception system may deteriorate in a poor channel environment. In particular, in the case of a portable or mobile broadcast receiver, robustness against channel change and noise is more required, and therefore, when mobile service data is transmitted using the VSB transmission method, reception performance is further deteriorated.</p>

<solutionproblem><p>Accordingly, it is an object of the present invention to provide a digital broadcasting transmission/reception system and data processing method that are resistant to channel change and noise. </p><p>Another object of the present invention is to provide a digital broadcast transmission/reception system and data processing method for signaling service guide information using a Fast Information Channel (FIC).</p><p>Another object of the present invention is to provide a digital broadcast transmission/reception system and data processing method for signaling service guide information using a service signaling channel. </p><p>Another object of the present invention is to provide a digital broadcast transmission/reception system and data processing method for receiving service guide information using signaling information of FIC and signaling information of a service signaling channel. </p></solutionproblem><meansproblemsolution><p>In order to achieve the above object, a data processing method of a receiving system according to an embodiment of the present invention provides a fast information channel (FIC) including a field indicating that a table signaling service guide bootstrap information is included in a service signaling channel. ) receiving data, mobile service data packetized into RS frames belonging to an ensemble desired to receive, and a broadcast signal including the service signaling channel, demodulating the broadcast signal, and a table included in the service signaling channel It may include obtaining service guide bootstrap information from, and accessing the service guide announcement channel using the service guide bootstrap information. </p><p>The broadcast signal may further include transmission parameter channel (TPC) data including FIC version information for identifying the update of the FIC data.</p><p>The data processing method of the receiving system according to the present invention includes accessing the service guide announcement channel to obtain service guide management information, and according to the access information of the service guide information included in the service guide management information, service guide information It may further include the step of receiving. </p><p>The service signaling management information includes a service guide delivery descriptor (SGDD).</p><p>The FIC data includes a 5-byte FIC chunk header and a variable-length FIC chunk payload, and the indication field is included in at least one of the FIC chunk header and the FIC chunk payload. </p><p>The service guide bootstrap information may be signaled in a descriptor of a service map table (SMT) included in the service signaling channel. </p><p>The service guide bootstrap information may be signaled in a field of a guide access table (GAT) included in the service signaling channel. </p><p>A receiving system according to an embodiment of the present invention may include a receiver, a demodulator, a first handler, and a second handler. The receiver includes fast information channel (FIC) data including a field indicating that a table for signaling service guide bootstrap information is included in the service signaling channel, and mobile service data packetized into RS frames belonging to an ensemble desired to be received; A broadcast signal including the service signaling channel is received. The demodulator demodulates the broadcast signal. The first handler obtains service guide bootstrap information from a table included in the service signaling channel. The second handler accesses the service guide announcement channel using the service guide bootstrap information.</p><p>Other objects, features and advantages of the present invention will become apparent from a detailed description of the embodiments with reference to the accompanying drawings. </p></meansproblemsolution><effectiveness><p>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 segment units and transmitted through FIC, so that a receiving system can perform fast service acquisition.</p><p>In addition, the present invention efficiently identifies an ensemble transmitting service guide information by using the signaling information of the FIC chunk and the signaling information received through the service signaling channel, and receives and processes the service guide information from the RS frame belonging to the ensemble. make it available </p><p>The present invention has the advantage of being resistant to errors when transmitting mobile service data through a channel and compatibility with an existing receiver. The present invention has an advantage in that mobile service data can be received without errors even in a channel with high ghost and noise. According to the present invention, the reception performance of the reception system can be improved in an environment with severe channel change by inserting known data at a specific position in the data area and transmitting it. In particular, the present invention is more effective when applied to portable and mobile receivers that have severe channel changes and require robustness against noise.</p></effectiveness>

<p>DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention that can specifically realize the above objects will be described with reference to the accompanying drawings. At this time, the configuration and operation of the present invention shown in the drawings and described by it is described as at least one embodiment, and the technical idea of the present invention and its core configuration and operation are not limited thereby.</p><p><u>Definitions of terms used in the present invention </u></p><p>The terms used in the present invention have been selected as widely used general terms as possible while considering the functions in the present invention, but these may vary depending on the intentions or customs of those skilled in the art or the emergence of new technologies. In addition, in specific cases, there are also terms arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the description of the corresponding invention. Therefore, it is intended to clarify that the terms used in the present invention should be defined based on the meaning of the term and the overall contents of the present invention, rather than the simple name of the term.</p><p>Among terms used in the present invention, main service data is data that can be received by a fixed reception system, and may include audio/video (A/V) data. That is, the main service data may include HD (High Definition) or SD (Standard Definition) level A/V data, and may include various data for data broadcasting. And known data is data known in advance by the promise of the transmitter/receiver.</p><p>Among the terms used in the present invention, M/H (or MH) is the first letter of each of Mobile and Handheld, and is a concept opposite to the fixed type. In addition, the M/H service data includes at least one of mobile service data and handheld service data. For convenience of description, in the present invention, the M/H service data is also referred to as mobile service data. In this case, the mobile service data may include not only M/H service data but also service data indicating movement or portability, and therefore, the mobile service data will not be limited to the M/H service data. Also, data required for mobile service will be referred to as mobile service data.</p><p>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 is service data for a portable or mobile terminal (or broadcast receiver), and may be A/V data having a smaller resolution and a smaller data rate than the main service data. For example, if the A/V codec (Codec) used for the existing main service is an MPEG-2 codec (Codec), the A/V codec (Codec) for the mobile service is MPEG-4 with better video compression efficiency. A method such as Advanced Video Coding (AVC) or Scalable Video Coding (SVC) may be used. Also, any kind of data may be transmitted as the mobile service data. For example, Transport Protocol Expert Group (TPEG) data for broadcasting traffic information in real time may be transmitted as mobile service data. </p><p>In addition, data services using the mobile service data include weather services, transportation services, stock services, audience participation quiz programs, real-time opinion polls, interactive educational broadcasting, game services, drama plots, characters, background music, filming locations, etc. Information provision service for sports, information provision service for sports past matches, profile and performance information of players, service to enable product information and orders, etc., service to provide information on programs by media, time, or topic and the like, but the present invention is not limited thereto. </p><p>The transmitting system of the present invention enables transmission by multiplexing main service data and mobile service data on the same physical channel without affecting reception of main service data in an existing receiving system at all (backward compatible). </p><p>The transmission system of the present invention performs additional encoding on mobile service data, and inserts data known in advance by both the transmitter and receiver, ie, known data, so that the data can be transmitted. </p><p>When the transmission system according to the present invention is used, mobile service data can be received in the receiving system, and mobile service data can be reliably received despite various distortions and noises generated in the channel. </p><p>In addition, according to an embodiment, the transmission/reception system of the present invention operates two data channels. One data channel is an RS frame data channel for content transmission, and the other data channel is a FIC (Fast Information Channel) for service acquisition. 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 segment units and transmitted through FIC, so that a receiving system can perform fast service acquisition.</p><p>1 shows an embodiment of a protocol stack for providing a mobile service based on IP.</p><p>That is, in the transmission system, mobile service data (eg, A/V streaming) is packetized according to a Real Time protocol (RTP) method, and the RTP packet is further packetized according to a User Datagram protocol (UDP) method, RTP The /UDP packet is again packetized according to the IP method to become RTP/UDP/IP packet data. In the present invention, the packetized RTP/UDP/IP packet data is referred to as an IP datagram for convenience of description.</p><p>In addition, service information for receiving a mobile service may be provided in the form of a table, and a service signaling channel for transmitting such a table (eg, a service map table, SMT) is packetized according to the UDP method, and the packetized UDP data is again packetized according to the IP method to become UDP/IP data. The UDP/IP data is also referred to as an IP datagram in the present invention for convenience of description. In this case, according to an embodiment, the service signaling channel is encapsulated into an IP datagram having a well-known IP destination address and a well-known destination UDP port number.</p><p>In the present invention, the adaptation layer collects the IP datagrams to form an RS frame, distributes the data of the RS frame to a plurality of data groups, and then modulates the data using a predetermined transmission method, for example, the VSB transmission method, in the mobile physical layer. In one embodiment, it is transmitted through According to an embodiment, each data group includes an FIC segment. The relationship between the RS frame and the FIC segment will be described in detail later.</p><p>Meanwhile, a service guide delivery descriptor (SGDD) including access information of announcement information for mobile services may be included in the RS frame and transmitted. In this case, according to an embodiment, the SGDD is transmitted through a service guide announcement channel.</p><p>In the present invention, the service guide announcement channel is packetized according to a file transfer protocol method, and is again packetized according to an Asynchronous Layered Coding/Layered Coding Transport (ALC/LCT) method. The packetized ALC/LCT data is again packetized according to the UDP method, and the packetized ALC/LCT/UDP data is again packetized according to the IP method to form ALC/LCT/UDP/IP data and then an RS frame Included in is an embodiment.</p><p>That is, the RS frame may include at least one of an IP datagram of mobile service data, an IP datagram of a service signaling channel, and an IP datagram of a service guide announcement channel. </p><p>In the present invention, a collection of consecutive RS frames having the same Forward Error Correction codes (FEC) is referred to as an ensemble.</p><p>According to an embodiment of the present invention, signaling information for identifying an ensemble including an entry point of a service guide, ie, SGDD, to the FIC is an embodiment.</p><p>In the present invention, as an embodiment, signaling the access information of the service guide announcement channel to the service signaling channel included in the ensemble identified by the FIC. </p><p>In the present invention, it is assumed that the access information of the service guide announcement channel includes service guide bootstrap information. That is, the service guide bootstrap information is information necessary to bootstrap the service guide of the mobile service. The service guide bootstrap information includes access information (eg, TSI) of a FLUTE session transmitting the service guide announcement channel.</p><p>According to an embodiment, the access information of the service guide announcement channel is signaled through a table included in the service signaling channel. The table may be a service map table (SMT) or a guide access table (GAT).</p><p>In the present invention, for convenience of description, data included in the RS frame will also be referred to as mobile service data.</p><p><u>data format structure</u></p><p>Meanwhile, 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. </p><p>2 is a diagram showing an embodiment of the structure of a data group according to the present invention. </p><p>An example of dividing a data group into ten M/H blocks (M/H blocks B1 to B10) is shown in the data configuration according to FIG. 2 . In addition, it is assumed that each M/H block has a length of 16 segments. In FIG. 2 , only RS parity data is allocated to a part of the 5 segments before the M/H block B1 and the 5 segments after the M/H block B10, and is excluded from areas A to D of the data group according to an embodiment.</p><p>That is, assuming that one data group is divided into areas A, B, C, and D, each M/H block is placed in any one of areas A to D according to the characteristics of each M/H block in the data group. can be included In this case, according to the degree of interference of the main service data, each M/H block is included in any one of areas A to D according to an embodiment.</p><p>Here, the reason why the data group is divided into a plurality of areas and used is to have different uses. That is, an area where there is no or little interference of main service data may exhibit stronger reception performance than an area where there is no interference of the main service data. In addition, when applying a system that inserts known data into a data group and transmits known data according to the promise of the transmitter/receiver, when long known data is continuously inserted into the mobile service data periodically, the main service It is possible to periodically insert known data of a certain length into an area where there is no data interference (ie, an area where main service data is not mixed). However, it is difficult to periodically insert known data due to the interference of the main service data in an area with interference of the main service data, and it is also difficult to continuously insert long known data.</p><p>In the data group, mobile service data means RS frame data. The data of the RS frame will be described in detail later.</p><p>M/H blocks B4 to M/H blocks B7 in the data group of FIG. 2 are regions where there is no interference of main service data, and show examples in which long known data streams are inserted before and after each M/H block. In the present invention, it will be referred to as region A (=B4+B5+B6+B7) including the M/H blocks B4 to M/H blocks B7. As described above, in the case of region A having a known data sequence in front and back of each M/H block, since the receiving system can perform equalization using channel information obtained from known data, the strongest equalization among regions A to D performance can be obtained.</p><p>M/H blocks B3 and M/H blocks B8 in the data group of FIG. 2 are regions with little interference of main service data, and both M/H blocks show examples in which a long known data stream is inserted in only one side. That is, due to the interference of main service data, in M/H block B3, a long known data string is inserted only after the corresponding M/H block, and in M/H block B8, a long known data string is inserted only before the corresponding M/H block. can be In the present invention, the region B including the M/H block B3 and the M/H block B8 will be referred to as a region B (=B3+B8). As described above, in the case of region B having a known data stream in only one of the M/H blocks as described above, the receiving system can perform equalization using channel information obtained from the known data, so it is more robust than the C/D region. equalization performance can be obtained.</p><p>M/H blocks B2 and M/H blocks B9 in the data group of FIG. 2 have more interference of main service data than area B, and both M/H blocks cannot insert a long known data sequence back and forth. In the present invention, the region C including the M/H block B2 and the M/H block B9 will be referred to as a region C (=B2+B9).</p><p>In the M/H block B1 and the M/H block B10 in the data group of FIG. 2, the interference of main service data is greater than that of the C area, and similarly, both M/H blocks cannot insert a long known data sequence back and forth. In the present invention, the region D including the M/H block B1 and the M/H block B10 will be referred to as (=B1+B10). Since the C/D region is far away from the known data stream, reception performance may be poor when the channel changes rapidly.</p><p>In addition, the data group includes a signaling information area to which signaling data (or signaling information) is allocated. </p><p>According to the present invention, a part of the first segment to the second segment of the M/H block B4 in the data group may be used as the signaling information area. </p><p>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 a signaling information area. That is, the signaling information area is composed of 207 bytes, 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.</p><p>The signaling data transmitted to the signaling information area can be divided into two types of channel data. One is TPC (Transmission Parameter Channel) data, and the other is FIC (Fast Information Channel) data.</p><p>The TPC data mainly includes parameters used in a physical layer module, and is transmitted without interleaving, so that the receiving system can access each slot. </p><p>The FIC data is provided to enable fast service acquisition in a receiving system, and includes cross-layer information between a physical layer and an upper layer. The FIC data is interleaved and transmitted in units of subframes.</p><p>For example, when the data group includes six known data streams as in FIG. 2 , the signaling information area is located between the first known data stream and the second known data stream. 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. In addition, the third to sixth known data streams 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 separated by 16 segments.</p><p>3 is a diagram illustrating the structure of an RS frame according to an embodiment of the present invention. </p><p>The RS frame is received for each M/H frame in a state in which the time slicing mode is switched.</p><p>An RS frame according to an embodiment of the present invention is composed of a plurality of M/H Transport Packets (TPs). Each M/H TP consists of an M/H header of 2 bytes and an M/H payload of N-2 bytes. The M/H payload may include at least one of an IP datagram of mobile service data, an IP datagram of SMT, and an IP datagram of SGDD.</p><p>That is, one RS frame includes an IP datagram of each mobile service data, and all RS frames include an IP datagram of a service map table (SMT ) section. In one embodiment, the SMT or an IP datagram of a service signaling channel for transmitting the SMT is received by being included in a corresponding RS frame with a well-known IP destination address and a well-known destination UDP port number. do.</p><p>Also, the RS frame may include an IP datagram of SGDD. According to an embodiment, the SGDD or access information of a service guide announcement channel for transmitting the SGDD is signaled to the SMT. The access information of the service guide announcement channel includes service guide bootstrap information.</p><p>In the RS frame of FIG. 3, there are three types of IP datagrams (IP Datagrams 1, 2, and 3), one of which is an IP datagram for SMT. The remaining IP datagram may be an IP datagram of mobile service data or an IP datagram for SGDD.</p><p>The transmission system performs RS encoding on the RS frame in a column direction, performs CRC encoding in a row direction, and allocates and transmits the RS frame to corresponding regions of a plurality of data groups. In the present invention, all data included in the RS frame is also referred to as mobile service data for convenience of description.</p><p><u>data transfer structure </u></p><p>4 is a diagram illustrating an example of an M/H frame structure for transmission/reception of mobile service data according to the present invention. </p><p>4 shows an example in which one M/H frame consists of 5 subframes and one subframe consists of 16 slots. In this case, it means that one M/H frame includes 5 subframes and 80 slots.</p><p>And, one slot is composed of 156 data packets (ie, transport stream packets) at the packet level and 156 data segments at the symbol level. Alternatively, it has a size corresponding to half of the VSB field. That is, since one data packet of 207 bytes has the same amount of data as one data segment, a data packet before data interleaving can be used as a data segment concept. At this time, two VSB fields are gathered to constitute one VSB frame.</p><p>One VSB frame consists of two VSB fields (ie, an odd field and an even field). And each VSB field is composed of one field sync segment and 312 data segments.</p><p>The slot is a basic time unit for multiplexing mobile service data and main service data. One slot may include mobile service data or may consist only of main service data.</p><p>If the first 118 data packets in the slot correspond to one data group, the remaining 38 packets become the main service data packets. As another example, if there is no data group in one slot, the corresponding slot consists of 156 main service data packets.</p><p>Meanwhile, data in one RS frame may be allotted to the A/B/C/D regions within the data group, or may be allocated to at least one of the A/B/C/D regions. According to an embodiment of the present invention, all of the data in one RS frame is allocated to the A/B/C/D area or only to any one of the A/B area and the C/D area. 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 referred to as a Primary RS frame, and the RS frame allocated to the C/D region is referred to as a Secondary RS frame. frame). In addition, the primary RS frame and the secondary RS frame constitute one parade. That is, if all the data in one RS frame is allocated to the A/B/C/D regions in the data group, one parade transmits one RS frame. On the other hand, if the data in one RS frame is allocated to the A/B area in the data group and the data in the other RS frame is allocated to the C/D area in the corresponding data group, one parade is up to two RS frames. can be transmitted</p><p>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.</p><p>Table 1 below shows an example of RS frame mode. </p><p><tables id="1"><table><tgroup xmlns="http://www.oasis-open.org/tables/exchange/1.0" cols="2"><colspec colnum="1" align="justify" colname="col1" colwidth="2824" /><colspec colnum="2" align="justify" colname="col2" colwidth="7919" /><tbody><row><entry align="justify" colname="col1">RS frame mode</entry><entry align="justify" colname="col2">Description</entry></row><row><entry align="justify" colname="col1">00</entry><entry align="justify" colname="col2">There is only a primary RS frame for all Group Regions</entry></row><row><entry align="justify" colname="col1">01</entry><entry align="justify" colname="col2">There are two separate RS frames - Primary RS frame for Group Region A and B - Secondary RS frame for Group Region C and D</entry></row><row><entry align="justify" colname="col1">10</entry><entry align="justify" colname="col2">Reserved</entry></row><row><entry align="justify" colname="col1">11</entry><entry align="justify" colname="col2">Reserved</entry></row></tbody></tgroup></table></tables></p><p>Table 1 shows that 2 bits are allocated to indicate the RS frame mode. Referring to Table 1, if the RS frame mode value is 00, it indicates that one parade transmits one RS frame, and if the RS frame mode value is 01, one parade indicates two RS frames, that is, the primary RS. It indicates to transmit a frame and a secondary RS frame. That is, if the RS frame mode value is 01, the data of the Primary RS frame for region A/B is allocated to the A/B region of the data group and transmitted, and C/D It indicates that the data of the secondary RS frame for region C/D is allocated to the C/D region of the corresponding data group and transmitted.</p><p>Similar to the data group allocation, it is an embodiment that the parades are allocated as far apart as possible from each other within the subframe. In this way, it is possible to strongly respond to a burst error that may occur within one subframe.</p><p>In addition, the method of allocating parades may be applied differently to each 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 applied differently to each subframe. The present invention may vary for each M/H frame, and the same application is applied to all sub-frames in one M/H frame as an embodiment. That is, the M/H frame structure can be changed in units of M/H frames, which allows the ensemble data rate to be flexibly adjusted.</p><p>That is, in the embodiment of the present invention, an 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. Also, one ensemble has the same unique identifier (ie, ensemble id) and corresponds to consecutive RS frames.</p><p>5 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. </p><p>As described above, the M/H frame for about 0.968 seconds is divided into 5 subframes, and data groups corresponding to several ensembles are mixed in each subframe, and data groups corresponding to each ensemble are present. are interleaved in units of M/H frames to form an RS frame belonging to one ensemble. In FIG. 5, there are two ensembles (NoG=4, NoG=3). In addition, a certain part (eg 37 bytes/data group) of each data group is used for transmitting FIC data to which encoding is applied separately from the RS frame data channel. An FIC region allocated to each data group constitutes one FIC segment, and the FIC segments are interleaved in units of subframes. For example, RS encoding and serial concatenated convolution code (SCCC) encoding are applied to the data of the RS frame, and RS encoding and parallel concatenated convolution code (PCCC) encoding are applied to the FIC data. . Meanwhile, RS encoding and parallel concatenated convolution code (PCCC) encoding are applied to TPC data like the FIC data. At this time, (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 (18,10)-RS encoding is applied to the TPC data. It is applied as an example. Here, P is the number of parity bytes.</p><p><u>hierarchical </u><u>signaling</u><u> structure </u></p><p>6 is a diagram illustrating a hierarchical signaling structure according to an embodiment of the present invention. As shown in FIG. 6 , the mobile broadcasting technology according to the present embodiment employs a signaling method using FIC and SMT. This is called a hierarchical signaling structure in the present invention.</p><p>That is, FIG. 6 shows a hierarchical signaling structure that provides data necessary for service acquisition through a service map table (SMT) among FIC chunks and IP-level mobile service signaling channels. </p><p>As can be seen from FIG. 6 , the FIC chunk transmits the mapping relationship between the mobile service and the ensemble to the receiving system by using its fast characteristic. That is, the FIC chunk provides the receiving system with signaling data for quickly finding an ensemble delivering a desired service in the receiving system and quickly receiving RS frames of the corresponding ensemble.</p><p><u>FIC</u><u>(</u><u>Fast</u><u></u><u>Information</u><u></u><u>Channel</u><u>) </u></p><p>In addition, the receiving system according to the present invention allows faster access to a currently broadcast mobile service using a Fast Information Channel (FIC). </p><p>7 shows a syntax structure of an FIC chunk serving to map a relationship between a mobile service and an ensemble through FIC. </p><p>The FIC chunk includes a 5-byte FIC chunk header and a variable-length FIC chunk payload. </p><p>8 shows an embodiment of a syntax structure of an FIC chunk header according to the present invention. </p><p>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 minor protocol version change, and signals each length of FIC chunk header extension, ensemble loop header extension, and mobile service loop extension that may occur due to minor protocol version change. . </p><p>If the receiving system that can accommodate the minor protocol version change processes the extension field, while the legacy receiving system that cannot accommodate the minor protocol version change uses each corresponding length information, As an embodiment, skipping the corresponding extension field. For example, if the receiving system can accommodate the change of the corresponding minor protocol version, the contents indicated by the corresponding extension field can be known, and the operation according to the contents indicated by the extension field can be performed.</p><p>In the present invention, the minor protocol version change of the FIC chunk is made by inserting an additional field into 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. In other cases, if the length of the additional field cannot be expressed by each extension length of the FIC chunk header, or a specific field in the FIC chunk payload is missing, or the number of bits allocated to the field or , when the definition of the field is changed, updating the major protocol version of the corresponding FIC chunk is an embodiment.</p><p>In addition, the FIC chunk header signals whether the data of the corresponding FIC chunk payload contains mapping information between the ensemble and the mobile service in the current M/H frame or the mapping information between the ensemble and the mobile service in the next M/H frame. In addition, the transport stream ID of the mobile broadcast in which the FIC chunk is currently transmitted and the number of ensembles transmitted through the mobile broadcast are signaled.</p><p>In addition, the FIC chunk header according to the present invention may signal an ESG (Electronic Service Guide) entry point, that is, an identifier of an ensemble through which a SGDD (Service Guide Delivery Descriptor) is transmitted. In this case, the receiving system can know in which ensemble the corresponding SGDD is received.</p><p>For this, the FIC chunk header may include an FIC_major_protocol_version field, a 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 num_entry_location field, a num_entry_location field, and a num_entry_location field. </p><p>The FIC_major_protocol_version field allocates 2 bits according to an embodiment, and indicates a major protocol version of the corresponding FIC chunk syntax. A change of the major protocol version indicates a change of a level that is not backward compatible. If this field value is updated, the legacy receiving system that can handle the previous major protocol version of the FIC chunk protocol does not process the FIC chunk (A two-bit unsigned integer field that represents the major version level of 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).</p><p>The FIC_minor_protocol_version field allocates 3 bits according to an embodiment and indicates the minor protocol version of the corresponding FIC chunk syntax. A change in the minor protocol version indicates a backward compatible level change. If this field is updated, a legacy receiving system capable of handling the same major protocol version of the FIC chunk protocol may process a part of the FIC chunk (A three-bit unsigned integer field that represents the minor) 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).</p><p>The FIC_Chunk_header_extension_length field allocates 3 bits as an embodiment and indicates the length of the FIC chunk header extension byte generated by updating the minor protocol version of the corresponding FIC chunk. This 3-bit 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).</p><p>The ensemble_header_extension_length field allocates 3 bits as an embodiment and indicates the length of the ensemble header extension byte generated by the minor protocol version update of the corresponding FIC chunk. The extension bytes are appended to the end of the corresponding ensemble loop header (This 3-bit 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).</p><p>The M/H_service_loop_extension_length field allocates 3 bits as an 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 extension bytes are appended to the end of the corresponding mobile service loop (This 3-bit 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).</p><p>For example, it is assumed that two ensembles (ie, ensemble 0 and ensemble 1) exist in the FIC chunk, and two mobile services are transmitted through ensemble 0 and one mobile service is transmitted through ensemble 1 . At this time, if the FIC chunk header is extended by 1 byte while the minor protocol version is changed, the FIC_chunk_header_extension_length field indicates 001. In this case, a 1-byte extension field (FIC_Chunk_header_extension_bytes field) is added to the end of the FIC chunk header, and the existing reception system skips the 1-byte extension field added to the end of the FIC chunk header without processing.</p><p>And 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, a 2-byte extension field (Ensemble_loop_header_extension_bytes field) is added to the end of the ensemble 0 loop header and the ensemble 1 loop header, respectively. In the existing receiving system, the 2-byte extension added to the end of the ensemble 0 loop header and the ensemble 1 loop header is added. Fields are skipped without processing.</p><p>Also, if the mobile service loop of the FIC chunk is extended by 1 byte, the M/H_service_loop_extension_length field indicates 001. In this case, an extension field of 1 byte (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, respectively. In addition, in the existing reception system, the 1-byte extension field added to the end of two mobile service loops transmitted through ensemble 0 and one mobile service loop transmitted through ensemble 1 is skipped without processing.</p><p>In this way, when the value of the FIC_minor_protocol version field is changed, the existing receiving system, that is, the receiving system that cannot accommodate the change of the corresponding minor protocol version of the FIC chunk, processes the remaining fields except for the extension field, and sets the FIC_chunk_header_extension_length, ensemble_loop_header_extension_length, and M/H_service_loop_extension_length fields. The corresponding 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 extension field is processed using each length field.</p><p>The current_next_indicator field allocates 1 bit as an embodiment, and when the field value is set to 1, it indicates that the corresponding FIC chunk is applied to the current M/H frame. If the field value is set to 0, it indicates that the corresponding FIC chunk is applied to the next M/H frame (A one-bit indicator, which when set to '1' shall indicate that this FIC-Chunk is currently applicable. When the 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 the signaling data of the current M/H frame. Also, when the field value is set to 0, it means that the corresponding FIC chunk transmits the signaling data of the next M/H frame. In the present invention, when reconfiguration occurs in which mapping information between the ensemble and the mobile service in the current M/H frame and the mapping information between the ensemble and the mobile service in the next M/H frame are different, the M/ before the reconfiguration occurs The H frame will be referred to as a current M/H frame, and the M/H frame in which reconfiguration will occur will be referred to as a next M/H frame. </p><p>The transport_stream_id field allocates 16 bits according to an embodiment, and indicates a transport stream ID of a mobile broadcast in which the 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).</p><p>The SG_version field allocates 5 bits according to an embodiment, and indicates version information of a service guide transmitted through a physical channel. That is, the physical channel is a physical channel through which the corresponding FIC chunk is transmitted.</p><p>In an embodiment, the num_ensembles field allocates 8 bits and indicates the number of ensembles transmitted through a corresponding physical transmission channel (An 8-bit unsigned integer field that shall equal the number of Ensembles carried through this physical transmission channel) . </p><p>The ESG_EntryPoint_Location field, according to an embodiment, allocates 8 bits and indicates an entry point of the ESG, that is, an ensemble id through which the SGDD is transmitted. Accordingly, the receiving system can know in which ensemble the corresponding SGDD, that is, the ESG entry point is received.</p><p>9 shows an embodiment of a syntax structure of an FIC chunk payload according to the present invention. </p><p>The FIC chunk payload includes, for each of the ensembles corresponding to the num_ensembles field value in the FIC chunk header of FIG. 8, configuration information of the ensemble, and information on a mobile service transmitted through each ensemble, have. In addition, the FIC chunk payload includes information indicating whether an entry point of the service guide, ie, SGDD, exists in the corresponding ensemble for each ensemble. In this case, by using the indication information, the receiving system can know whether a table including service guide bootstrap information is included in the service signaling channel. The table may be SMT or GAT.</p><p>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 a 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 corresponding ensemble.</p><p>To this end, the ensemble loop of the FIC chunk payload may include an ensemble_id field, an SG_entry_point_indicator field, an SMT_version field, and a num_MH_services field that are repeated by the value of the num_ensembles field. The mobile service loop may include an MH_service_id field, an MH_service_type field, a multi_ensemble_service field, an MH_service_status field, and an SP_indicator field that are repeated as many as num_MH_services field values.</p><p>The ensemble_id field, according to an embodiment, allocates 8 bits and indicates a unique identifier of the corresponding ensemble. For example, values of 0x00 to 0x7F may be allocated as the field value. This field serves to bind mobile services and ensembles. The value of the field may be derived from parade_id of TPC data. For example, when the corresponding 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 corresponding parade. On the other hand, when the corresponding 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 corresponding 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. Note that 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).</p><p>The SG_entry_point_indicator field allocates 1 bit as an embodiment, and indicates whether an entry point of the service guide, ie, SGDD, exists in the corresponding ensemble. For example, if the value of the SG_entry_point_indicator field is 1, it may indicate that SGDD is included in the corresponding ensemble, and if 0, it may indicate that it is not included. In this case, when the value of the SG_entry_point_indicator field is 1, access information of the service guide announcement channel, ie, service guide bootstrap information, is signaled to the service signaling channel included in the corresponding ensemble.</p><p>Accordingly, the receiving system can identify whether SGDD is included in the corresponding ensemble according to the value of the SG_entry_point_indicator field. In addition, the receiving system may identify whether access information of the service guide announcement channel, that is, service guide bootstrap information, is signaled to the service signaling channel included in the corresponding ensemble according to the SG_entry_point_indicator field value. That is, the receiving system can know whether a table including service guide bootstrap information is included in the service signaling channel according to the value of the SG_entry_point_indicator field. The table may be SMT or GAT.</p><p>In this case, the present invention shows an example in which the ESG_EntryPoint_Location field is included in the FIC chunk header and the SG_entry_point_indicator field is included in the FIC chunk payload. In this case, the receiving system may determine which ensemble includes SGDD by referring to both field values, or may determine which ensemble includes SGDD by referring to only one of the two fields. As another embodiment of the present invention, only one of the two fields may be included. For example, the ESG_EntryPoint_Location field is included in the FIC chunk header and the SG_entry_point_indicator field is not included in the FIC chunk payload, or vice versa.</p><p>The SMT_version field, according to an embodiment, allocates 5 bits and indicates version information of service map table (SMT) data of the corresponding ensemble. </p><p>The num_M/H_services field allocates 8 bits as an embodiment and indicates the number of mobile services transmitted in the corresponding ensemble (An 8-bit unsigned integer field that represents the number of M/H Services carried through this M/ H Ensemble).</p><p>For 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 the mobile service loop, an extension field added to the ensemble loop header is added after the M/H_service_configuration_version field.</p><p>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. The field value has a unique value in mobile broadcasting (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. Thus, 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.). </p><p>The MH_service_type field, according to an embodiment, allocates 5 bits and indicates the type of the corresponding mobile service. </p><p>The multi_ensemble_service field allocates 2 bits according to an embodiment, and indicates whether a corresponding mobile service is transmitted through one or more ensembles. In addition, this field value indicates whether the mobile service is valid only for the mobile service part transmitted through the ensemble (A 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).</p><p>The M/H_service_status field, according to an embodiment, allocates 2 bits and indicates the status of the corresponding mobile service. For example, the high-order bit of the field indicates whether the corresponding mobile service is active, and the low-order 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).</p><p>The SP_indicator field allocates 1 bit as an embodiment and indicates whether service protection of the corresponding mobile service is performed (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).</p><p>For 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. </p><p>Also, the FIC chunk payload may include an FIC_chunk_stuffing() field. Stuffing of the FIC_chunk_stuffing() field is necessary so that the boundary of the FIC chunk is aligned with the boundary of the last FIC segment among 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. Chunk payload preceding the stuffing.).</p><p>At this time, the transmitting system (not shown) according to the present invention divides the FIC chunk into a plurality of FIC segments, and transmits the FIC chunk to the receiving system in units of FIC segments. The size of each FIC segment unit is 37 bytes, and each FIC segment consists of a 2-byte FIC segment header and a 35-byte FIC segment payload. That is, one FIC chunk including the FIC chunk header and the FIC chunk payload is segmented by 35 bytes. Then, a 2-byte FIC segment header is added in front of each 35-byte segmented segment to configure the FIC segment.</p><p>According to an embodiment of the present invention, the length of the FIC chunk payload is variable. The length of the FIC chunk varies depending on the number of ensembles transmitted through the corresponding physical transmission channel and the number of mobile services included in each ensemble.</p><p>And the FIC chunk payload may include stuffing data. In this case, it is assumed that the stuffing data is used for alignment between an FIC chunk and a boundary of a last FIC segment among FIC segments belonging to the FIC chunk. When the length of the stuffing data is minimized in this way, the waste of the FIC segment can be reduced.</p><p>By applying Equation 1 below, the number of stuffing data bytes to be inserted into the FIC chunk can be obtained. </p><p><maths num="1"><df>Number of stuffing data bytes = 35 - j </df></maths></p><p>j = (5 + the number of signaling data bytes to be inserted into the payload of the FIC chunk) mod 35</p><p>For example, if the sum of the length of the 5-byte header of the FIC chunk and the length of signaling data to be inserted into the payload is 205 bytes, in Equation 1, j becomes 30, so the payload of the FIC chunk includes 5-byte stuffing data. can do. The length of the FIC chunk including stuffing data is 210 bytes, and the FIC chunk is divided into 6 FIC segments and transmitted. At this time, segment numbers are sequentially added to the six FIC segments divided in the FIC chunk.</p><p>And, according to the present invention, FIC segments divided from one FIC chunk may be transmitted through one subframe or through a plurality of subframes. If the FIC chunk is transmitted as in the latter case, when the amount of data to be transmitted through the FIC chunk is greater than the amount of FIC segments transmitted through one subframe (in this case, a plurality of services with very low bit rates) is executed, etc.), all necessary signaling data may be transmitted through the FIC chunk.</p><p>In this case, the FIC segment number indicates the FIC segment number within each FIC chunk, not the number of the FIC segment within each subframe. In this way, since the dependency relationship between the FIC chunk and the subframe can be removed, the waste of the FIC segment can be reduced.</p><p>In addition, the present invention may add a null FIC segment (NULL FIC Segment). The null FIC segment is used for processing the remaining FIC segment when stuffing is required in the corresponding M/H frame despite repeated transmission of the FIC chunk. For example, assume that TNoG is 3, and the FIC chunk is divided into two FIC segments. In this case, when the FIC chunk is repeatedly transmitted through 5 subframes in one M/H frame, two FIC segments are only will be transmitted. 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 and the boundary of the M/H frame. In this case, since the null FIC segment is not an FIC segment divided from an FIC chunk, an FIC segment number is not assigned to the null FIC segment. </p><p>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 the M/H frame, the M/H frame is allocated in the reverse order from the last subframe and transmitted. do. If there is a null FIC segment, it is assumed that the null FIC segment is located in a subframe on the M/H frame so that it is transmitted the latest.</p><p>In this case, in order to discard the null FIC segment without being processed by the receiving system, identification information for distinguishing the null FIC segment is required.</p><p>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 distinguishing the null FIC segment. According to an embodiment of the present invention, the null FIC segment is distinguished by setting the FIC_type field value in the header of the null FIC segment to '11'. That is, if the FIC_type field value of the null FIC segment is set to '11' and transmitted to the receiving system, the receiving system may discard the payload of the FIC segment in which the FIC_type field value is set to '11' without processing. . The '11' is an embodiment for helping understanding of the present invention, and if a promise is made between the transmitting and receiving sides in advance, any value capable of distinguishing the null FIC segment is possible. will not be limited. In addition, identification information for identifying the null FIC segment may be indicated using another field in the FIC segment header. </p><p>10 shows an embodiment of a syntax structure of an FIC segment header according to the present invention.</p><p>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. A description of each field is as follows.</p><p>The FIC_type field (2 bits) indicates the type of the corresponding FIC. If the field value is '00', it indicates that the corresponding FIC segment is an FIC segment that transmits a part of the FIC chunk. If the field value is '11', it indicates that the corresponding FIC segment is a null FIC segment for 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.).</p><p>The error_indicator field (1 bit) indicates whether an error has occurred in the corresponding FIC segment during transmission, and is set to '1' when an error occurs and '0' when there is no error. That is, when there is an unrecoverable error in the process of configuring the FIC segment, this field is set to '1'. Through this field, the receiving system can recognize whether there is an error in the FIC segment.</p><p>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 corresponding FIC segment is the first FIC segment of the FIC chunk, the FIC_seg_number field value is set to 0x0, and if the corresponding FIC segment is the second FIC segment, the FIC_seg_number field value is set to 0x1. That is, the FIC_seg_number field increases 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 4 FIC segments, 0x3 is indicated in the FIC_seg_number field value of the last FIC segment of the FIC chunk.</p><p>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). </p><p>At this time, since the conventional method of sequentially allocating FIC segment numbers to FIC segments in one subframe, in this case, the last FIC segment number and TNOG always coincide. However, in the FIC segment number allocation method according to the present invention, the last FIC segment number and TNOG do not always match. That is, they may or may not match. The TNoG is the total number of 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 becomes 8.</p><p>According to another embodiment of the present invention, the null FIC segment may be identified using a value of the FIC_segment_num field in the FIC segment header. That is, since an FIC segment number is not assigned to the null FIC segment, the transmitting system allocates null data to the FIC_segment_num field value of the null FIC segment and transmits it, and the receiving system transmits the FIC segment to which null data is assigned to the FIC_segment_num field value is null It can also be recognized as an FIC segment. Data promised in advance by the transmission/reception system may be allocated to the FIC_segment_num field value instead of null data.</p><p>As described above, 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. Also, only FIC segments divided from one FIC chunk may be transmitted through one subframe, or 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 within the corresponding subframe, but a number within the corresponding FIC chunk (ie, the FIC_seg_number field value). 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 which case a segment number is not assigned to the null FIC segment.</p><p>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 the FIC segments are interleaved and transmitted in units of subframes. let it be an embodiment. </p><p>Meanwhile, FIG. 11 shows an embodiment of a bit stream syntax structure of an SMT section that provides access information of SGDD transmitted by being included in an RS frame. Here, the SMT section is written in the form of an MPEG-2 private section to help understanding, but the format of the data of the SMT section may be any form.</p><p>The SMT may provide access information of mobile services in an ensemble including the SMT. In addition, the SMT may provide information essential for rendering of a mobile service. In addition, the SMT may include one or more descriptors, and other additional information may be described through the descriptors.</p><p>According to an embodiment of the present invention, when the SGDD is included in the ensemble including the SMT and received, the access information of the SGDD is provided by using the descriptor of the SMT. According to an embodiment, the descriptor of the SMT is an ensemble level descriptor.</p><p>In this case, the service signaling channel for transmitting the SMT may further include a signaling table (eg, GAT) other than the SMT. In this case, it is assumed that IP datagrams of the service signaling channel have the same well-known IP address and well-known UDP port number. Therefore, the classification of the SMT included in the service signaling data is made by the table identifier. That is, the table identifier may be table_id existing in the header of the corresponding table or the corresponding table section, and can be identified by further referring to table_id_extension, if necessary.</p><p>Examples of fields that can be transmitted through the SMT section are as follows. </p><p>The table_id field (8 bits) is a field for distinguishing the type of a table, and through this, it can be recognized that this table is SMT. </p><p>A section_syntax_indicator field (1 bit) is an indicator defining a section format of SMT, and the section format may be, for example, MPEG short-form syntax ('0') or the like (section_syntax_indicator: This 1-bit field shall be set to '0' to always indicate that this table is derived from the "short" form of the MPEG-2 private section table).</p><p>The private_indicator field (1 bit) indicates whether the SMT follows the private section.</p><p>The section_length field (12 bits) indicates the section length of the remaining SMT after the corresponding field (section_length: A 12-bit field. It specifies the number of remaining bytes this table section immediately following this field.).</p><p>The table_id_extension field (16 bits) is table-dependent and becomes a logical part of the table_id field providing the range of the remaining fields (table_id_extension: This is a 16-bit field and is table-dependent. It shall be considered to be logically part of the table_id field providing the scope for the remaining fields). The table_id_extension field includes an SMT_protocol_version field and an ensemble_id field.</p><p>The SMT_protocol_version field (8 bits) indicates the protocol version for allowing SMT transmitted by parameters having a structure different from those defined in the current protocol (SMT_protocol_version: An 8-bit unsigned integer field whose function is to allow, in the future, this SMT to carry parameters that may be structured differently than those defined in the current protocol. Non-zero values of SMT_protocol_version may be used by a future version of this standard to indicate structurally different tables).</p><p>The ensemble_id field (8 bits) is an ID value related to the corresponding ensemble, and values of 0x00 to 0x3F may be assigned. The value of this field is preferably derived from parade_id of TPC data. If the corresponding 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 corresponding parade. On the other hand, if the corresponding 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 corresponding parade.</p><p>A version_number field (5 bits) indicates a version number of SMT.</p><p>A current_next_indicator field (1 bit) indicates whether the SMT section is currently applicable.</p><p>The section_number field (8 bits) indicates the number of the current SMT section.</p><p>The last_section_number field (8 bits) indicates the last section number constituting the SMT.</p><p>The num_MH_services field (8 bits) indicates the number of mobile services in the SMT section. (num_MH_services: This 8 bit field specifies the number of services in this SMT section.).</p><p>Thereafter, a 'for' loop (or called a mobile service loop) is performed as many as the number of mobile services corresponding to the value of the num_MH_services field to provide signaling information for a plurality of mobile services. That is, signaling information of a corresponding mobile service is displayed for each mobile service included in the SMT section. In this case, the following field information may be provided for each mobile service.</p><p>The MH_service_id field (16 bits) indicates a value that can uniquely identify a corresponding mobile service (A 16-bit unsigned integer number that shall uniquely identify this mobile service within the scope of this SMT section.). </p><p>The Multi_ensemble_service field (2 bits) identifies whether a corresponding mobile service is transmitted through one or more ensembles.</p><p>The MH_service_status field (2 bits) identifies the status of the corresponding mobile service. Here, the MSB indicates whether the corresponding mobile service is active ('1') or inactive ('0'), and the LSB indicates whether the corresponding mobile service is hidden ('1') or not ('0').</p><p>The SP_indicator field (1 bit) indicates whether the corresponding mobile service is service protected. If the value of the SP_indicator field is 1, service protection is applied to at least one of the components required to provide a meaningful presentation of the corresponding mobile service (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 Service).</p><p>The short_MH_service_name_length field (3 bits) indicates the length of the short service name described in the short_service_name field in units of bytes. </p><p>The short_MH_service_name field indicates a short name of a corresponding mobile service.</p><p>The MH_service_category field (6 bits) identifies the type category of the corresponding mobile service. </p><p>The num_components field (5-bit) indicates the number of IP stream components in the corresponding mobile service (num_components: This 5-bit field specifies the number of IP stream components in this mobile service).</p><p>The IP_version_flag field (1 bit) indicates that the source_IP_address field, the MH_service_destination_IP_address field, and the component_destination_IP_address field are IPv6 addresses when set to '1', and indicates that the source_IP_address field and the MH_service_destination_IP_address field and component_destination field are IPv6 addresses when set to '0'. (IP_version_flag: A 1-bit indicator, which when set to '0' shall indicate that source_IP_address, MH_service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses. The value of '1' for this field is reserved for possible future indication that source_IP_address, MH_service_destination_IP_address, and component_destination_IP_address fields are for IPv6. Use of IPv6 addressing is not currently defined).</p><p>When the source_IP_address_flag field (1 bit) is set, it is a flag indicating that a source IP address value for a corresponding service exists to indicate a source-specific multicast (source_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set, that a source IP address value for this Service is present to indicate a source specific multicast).</p><p>When the MH_service_destination_IP_address_flag field (1 bit) is set, it indicates that the corresponding IP stream component is transmitted through an IP datagram having a destination IP address different from the MH_service_destination_IP_address. Therefore, when this flag is set, the receiving system uses component_destination_IP_address as destination_IP_address to access the corresponding IP stream component, and ignores the MH_service_destination_IP_address field in the num_MH_services loop.</p><p>The source_IP_address field (32 or 128 bits) needs to be interpreted when source_IP_address_flag is set to '1', but does not need to be interpreted when source_IP_address_flag is not set to '0'. When the source_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit IPv4 address indicating the source of the corresponding mobile service. If the IP_version_flag field is set to '1', this field indicates a 32-bit IPv6 address indicating the source of the corresponding mobile service.</p><p>The MH_service_destination_IP_address field (32 or 128 bits) needs to be interpreted when MH_service_destination_IP_address_flag is set to '1', but does not need to be interpreted when MH_service_destination_IP_address_flag is set to '0'. When MH_service_destination_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit destination IPv4 address for the corresponding mobile service. When MH_service_destination_IP_address_flag is set to '1' and the IP_version_flag field is set to '1', this field indicates a 64-bit destination IPv6 address for a corresponding mobile service. If the corresponding MH_service_destination_IP_address cannot be resolved, the component_destination_IP_address field in the num_components loop must be interpreted, and the receiving system must use component_destination_IP_address to access the IP stream component.</p><p>Meanwhile, the SMT according to the present embodiment provides information on a plurality of components using a for loop. </p><p>Thereafter, a 'for' loop (or referred to as a component loop) is performed as many as the number of components corresponding to the num_components field value to provide access information for a plurality of components. That is, access information of each component included in the corresponding mobile service is provided. In this case, the following field information may be provided for each component.</p><p>If the essential_component_indicator field (1 bit) is set to '1', it indicates that the corresponding component is an essential component for mobile service. Otherwise, the corresponding component indicates that it is an optional component (essential_component_indicator: A one-bit indicator which, when set to '1', shall indicate that this component is an essential component for the service. Otherwise, this field indicates that this component is an optional component).</p><p>When the component_destination_IP_address_flag field (1 bit) is set to '1', it is a flag indicating that the component_destination_IP_address field exists for the corresponding component (component_destination_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set to '1', that the component_destination_IP_address is present for this component). </p><p>A port_num_count field (6 bits) indicates the number of a UDP port related to a corresponding UDP/IP stream component. The destination UDP port number value increases by 1 starting from the destination_UDP_port_num field value.</p><p>A destination_UDP_port_num field (16 bits) indicates a destination UDP port number for a corresponding IP stream component.</p><p>In the component_destination_IP_address field (32 or 128 bits), when the IP_version_flag field is set to '0', this field indicates a 32-bit destination IPv4 address for the corresponding IP stream component. And when the IP_version_flag field is set to '1', this field indicates a 128-bit destination IPv6 address for the corresponding IP stream component (component_destination_IP_address: This field shall be present if the component_destination_IP_address_flag is set to '1' and shall not be present if the component_destination_IP_address_flag is set to '0'. When this field is present, the destination address of the IP datagrams carrying this component of the M/H Service shall match the address in this field. When this field is not present, the destination address of the IP datagrams carrying this component shall match the address in the M/H_service_destination_IP_address field. The conditional use of the 128 bit-long address version of this field is to facilitate possible use of IPv6 in the future, although use of IPv6 is not currently defined).</p><p>A num_component_level_descriptors field (4 bits) indicates the number of descriptors providing additional information of a component level. </p><p>The component_level_descriptor( ) is included in the component loop as many as the number corresponding to the value of the num_component_level_descriptors field to provide additional information about the component.</p><p>A num_MH_service_level_descriptors field (4 bits) indicates the number of descriptors providing additional information of a corresponding mobile service level.</p><p>Service_level_descriptor() is included in the mobile service loop as many as the number corresponding to the value of the num_MH_service_level_descriptors field to provide additional information on the mobile service.</p><p>The num_ensemble_level_descriptors field (4 bits) is the number of descriptors providing additional information of the ensemble level. </p><p>Ensemble_level_descriptor( ) is included in the ensemble loop as many as the number corresponding to the value of the num_ensemble_level_descriptors field to provide additional information about the ensemble.</p><p>Meanwhile, when the FIC indicates that the ESG entry point, ie, SGDD, is included in the ensemble corresponding to the ensemble identifier of the SMT, the SG access descriptor SG_Access_Descriptor is included in the ensemble level descriptor of the SMT. For example, suppose that the FIC indicates that SGDD is included in the ensemble having the ensemble identifier A using at least one of the ESG_EntryPoint_Location field and the SG_entry_point_indicator field. At this time, if the value of the ensemble_id field of the SMT is A, the SG access descriptor SG_Access_Descriptor is included in the SMT and received.</p><p>According to an embodiment, the SG access descriptor SG_Access_Descriptor provides access information of a service guide announcement channel for transmitting the SGDD. The access information of the service guide announcement channel includes service guide bootstrap information. The service guide bootstrap information includes a transport session identifier of a FLUTE session for transmitting the service guide announcement channel.</p><p>12 shows an embodiment of the bit stream syntax structure of the SG access descriptor SG_Access_Descriptor() according to the present invention.</p><p>A description of each field of the SG access descriptor SG_Access_Descriptor() is as follows.</p><p>In FIG. 12, a descriptor_tag field (8 bits) is a descriptor identifier, and an identifier for identifying the SG access descriptor SG_Access_Descriptor() is displayed. </p><p>A descriptor_length field (8 bits) indicates the remaining length of the descriptor in bytes from the descriptor_length field to the end of the descriptor. </p><p>The IP_version_flag field (1 bit) indicates that the destination_IP_address field is an IPv6 address when it is set to '1', and indicates that the destination_IP_address field is an IPv4 address when it is set to '0'. </p><p>The address_count field (7 bits) is a counter indicating how many high-order IP addresses from the destination_IP_address field described below are transmitted for transmission of the corresponding mobile service data. </p><p>The destination_IP_address field (32 or 128 bits) indicates the destination IP address of the FLUTE session transmitting the service guide announcement channel. If the IP_version_flag field is set to '0', the destination_IP_address field indicates a 32-bit destination IPv4 address for the corresponding service guide announcement channel. When the IP_version_flag field is set to '1', the destination_IP_address field indicates a 64-bit destination IPv6 address for a corresponding service guide announcement channel.</p><p>A destination_UDP_port_num field (16 bits) indicates a destination UDP port number of a FLUTE session transmitting a service guide announcement channel (Represents the destination UDP port number where the FLUTE session carrying SGDD is transported.).</p><p>The announcement_channel_TSI field (16 bits) indicates a transport session identifier for a FLUTE session in which the service guide announcement channel is transmitted. </p><p>That is, an IP datagram of a service guide announcement channel transmitting SGDD is obtained from the corresponding ensemble using the destination_IP_address field and the destination_UDP_port_num field, and after removing the ALC/LCT header from the obtained IP datagram, the announcement_channel_TSI field is added. SGDD is received by accessing the corresponding FLUTE session using FLUTE session information of SGDUs may be obtained from the received SGDD, and SGDUs may be received by accessing all FLUTE sessions according to the FLUTE session information. The SGDU includes one or more fragments.</p><p>In this case, if the service guide announcement channel has a well-known IP destination address and a well-known destination UDP port number, the destination_IP_address field and the destination_port_num field may be omitted.</p><p>Meanwhile, the SGDD access information as shown in FIG. 12 may be provided in a table format. In this case, according to an embodiment, the table including the SGDD access information is transmitted through a service signaling channel. In an embodiment, the classification of a table including the SGDD access information is performed by a table identifier. The table identifier may be table_id existing in the header of a corresponding table or a corresponding table section, and may be identified by further referring to table_id_extension, if necessary.</p><p>13 shows a relationship between a service guide structure to be used in an M/H system according to the present invention, an FIC chunk, and an SMT. Each SG fragment is bundled in an SGDU unit and transmitted through a FLUTE session, and the SGDD includes access information for a FLUTE session transmitting each SGDU. The FIC chunk informs which ensemble the SGDD is transmitted through, and the SMT included in the ensemble for transmitting the SGDD informs the IP access information of the SGDD or the access information of the FLUTE session using the SG access descriptor. By doing so, the receiving system can efficiently access the ESG.</p><p>In FIG. 13, the service guide includes an Administrative Group that provides upper-level configuration information of the entire service guide, a Provisioning Group that provides service subscription and purchase information, and a service guide such as services, contents, and service schedules. It includes a core group that provides core information, and an access group that provides access information for accessing services or content. </p><p>In FIG. 13 , the administrative group is a group that provides basic information for receiving a service guide from a receiving system, and includes a service guide delivery descriptor (SGDD). The SGDD informs access information of a FLUTE session in which a service guide delivery unit (SGDU) including one or more fragments, which is a minimum unit constituting a service guide, is located, and grouping ( Grouping) informs an entry point for receiving information and a notification message.</p><p>The supply group is a group that provides rate information for service reception, and includes a Purchase Item fragment, a Purchase data fragment, and a Purchase channel fragment. The core group is a group that provides information on the service itself, and includes a service fragment, a schedule fragment, and a content fragment. The access group includes an access fragment and a session description fragment. The service guide may include a preview data fragment and an interactive data fragment in addition to the group. In Fig. 13, arrows indicate reference relationships. According to this example, the feature item fragment, the content fragment, the schedule fragment, and the access fragment may refer to the service fragment. The schedule fragment may refer to a service fragment and a content fragment. The number illustrated above each arrow in FIG. 13 indicates the possible number of each sub-unit information. And the number indicates the possible number of each fragment.</p><p>The main fragments among the exemplified fragments will be described as follows.</p><p>The service fragment includes information about a service provided to a user, for example, a service such as a conventional television channel. </p><p>The content fragment includes metadata about the content. For example, types of content such as A/V, text, and images may be included in the content fragment.</p><p>The schedule fragment includes schedule information for one content of the service. For example, the broadcast time of the content may correspond to this.</p><p>The pertures item fragment includes item information related to purchase. </p><p>The pertures data fragment includes information related to the purchase of a service that a user can purchase. The pertures channel fragment refers to an interface through which a terminal or a user communicates with a purchase system. The perture channel fragment includes information about a parameter related to a purchasing system or management of a purchase channel.</p><p>The access fragment includes information related to access of a service or content. </p><p>For the convenience of the present invention, detailed element values and attribute values for each fragment of the service guide are not included in the description of the present invention. However, the detailed element values and attribute values do not limit the present invention. The present invention may be applied to all element values and attribute values defined by necessity in providing a service guide.</p><p>14 is a flowchart illustrating an embodiment of a method for receiving a service guide using an FIC chunk and SMT according to the present invention. </p><p>In FIG. 14 , when the physical transmission channel including the mobile service selected by the user is tuned, a mobile broadcasting signal for transmitting the mobile service selected by the user is checked from the tuned physical transmission channel ( S101 ). Then, the confirmed mobile broadcasting signal is demodulated (S102). Then, FIC segments are obtained from the demodulated mobile broadcast signal to reconstruct an FIC chunk (S103 and S104).</p><p>That is, a subframe in which the demodulated mobile broadcast signal is transmitted and a slot allocated to the subframe are found out. Then, data groups received through the slots of the sub-frame are collected. Then, PCCC decoding is performed on the FIC data received in each signaling information area of the collected data groups, deinterleaving is performed in units of subframes, and then RS decoding is performed in the reverse direction of the transmitting side. Then, the FIC segments are reconstructed for each subframe. This process is performed for one or more subframes, and the FIC chunk is restored from the payload of the FIC segments according to the FIC_type field, the FIC_segment_num field, and the FIC_last_segment_num field in each header of the FIC segments reconstructed from the one or more subframes.</p><p>According to an embodiment, the restored FIC chunk includes an FIC chunk header as shown in FIG. 8 and an FIC chunk payload as shown in FIG. 9 .</p><p>A transport stream ID of a mobile broadcast through which the FIC chunk is transmitted is identified from the transport_stream_id field of the restored FIC chunk header (S105). Then, mapping information between the ensemble and the mobile service is constructed using the information included in the restored FIC chunk (S106). The mapping information between the ensemble and the mobile service may include an ensemble identifier, a service identifier included in the ensemble identified by the ensemble identifier, service type information, and the like.</p><p>Then, it is checked in which ensemble the SGDD is received from the restored FIC chunk (S107). </p><p>In the present invention, it is possible to check which ensemble contains SGDD by referring to both the ESG_EntryPoint_Location field value of the FIC chunk header and the SG_entry_point_indicator field value of the FIC chunk payload, or which ensemble contains the SGDD by referring to only one of the two fields. have.</p><p>When the ensemble including the SGDD is identified in S107, the receiving system switches to the time slicing mode for receiving the corresponding ensemble and receives RS frames belonging to the ensemble for each M/H frame (S108). According to an embodiment of the present invention, RS frames belonging to an ensemble in which the SG_entry_point_indicator field value in the FIC chunk payload is set to 1 is received as an embodiment.</p><p>SMT is obtained from the received RS frame (S109). According to an embodiment, the SMT is received by being included in a service signaling channel having a well-known IP address and a well-known UDP port number. That is, SMT is obtained using a table identifier from an IP datagram of a service signaling channel having a well-known IP address and a well-known UDP port number.</p><p>The SG connection descriptor is processed among the descriptors included in the obtained SMT to obtain an entry point of the ESG, that is, IP connection information of the SGDD (S110). According to an embodiment, the SG connection descriptor includes a destination IP address, a destination UDP port number, and a TSI of a service guide announcement channel.</p><p>Accordingly, the IP datagram of the service guide signaling channel for transmitting the SGDD is obtained from the corresponding RS frame using the destination IP address and the destination UDP port number (S111).</p><p>After removing the ALC/LCT header from the obtained IP datagram, the SGDD is received by accessing the corresponding FLUTE session using the announcement_channel_TSI field (S112). Access information of SGDUs is obtained from the received SGDD, and SGDUs are collected by accessing each FLUSE session according to the obtained access information (S113). The SGDU includes one or more fragments. Then, SG data is extracted and stored from fragments included in the collected SGDUs. After that, when there is a user's request, the receiving system displays the SG information according to the stored SG data.</p><p>According to an embodiment of the present invention, S103 is performed by a signaling decoder, S104 to S107 are FIC handlers or physical adaptation control signal handlers, and S108 is performed by an RS frame decoder and an RS frame handler. In one embodiment, S109 and S110 are the SI handler or the physical adaptive control signal handler, S111 is the IP network stack, and S112 and S113 are the file handler and the ESG handler or the physical adaptive control signal handler. do it with</p><p><u>receiving system </u></p><p>15 is a diagram illustrating a configuration block diagram of a receiving system according to an embodiment of the present invention. In FIG. 15 , a solid arrow indicates a data path, and a dotted arrow indicates a control signal path.</p><p>The reception system according to the present embodiment includes a baseband processor 100 , a management processor 200 , and a presentation processor 300 . </p><p>The baseband processor 100 includes an operation controller 110 , a tuner 120 , a demodulator 130 , an equalizer 140 , and a known sequence detector. ) 150 , a mobile handheld block decoder 160 , a primary RS frame decoder 170 , a secondary RS frame decoder 180 , and a signaling decoder 190 . may include. </p><p>The operation controller 110 controls the operation of each block of the baseband processor 100 . </p><p>The tuner 120 tunes the reception system to a frequency of a specific physical channel, so as to receive main service data, which is a broadcast signal for a stationary broadcast reception device, and mobile service data, which is a broadcast signal for a mobile broadcast reception device. . At this time, the frequency of the tuned specific channel is down-converted into an intermediate frequency (IF) signal and output to the demodulator 130 and the known data detector 140 . The passband digital IF signal output from the tuner 120 may include only main service data, may include only mobile service data, or may include both main service data and mobile service data. The mobile service data may be RS frame data or data for a mobile service within a data group.</p><p>The demodulator 130 performs automatic gain control, carrier recovery, and timing recovery on the passband digital IF signal input from the tuner 120 to make a baseband signal, and then includes an equalizer 140 and a known data detector ( 150) is output. The demodulator 130 may improve demodulation performance by using the known data symbol stream received from the known data detector 150 during timing restoration or carrier restoration.</p><p>The equalizer 140 compensates for distortion on a channel included in the signal demodulated by the demodulator 130 and outputs the compensation to the block decoder 160 . The equalizer 140 may improve equalization performance by using the known data symbol stream input from the known data detector 150 . In addition, the equalizer 140 may receive feedback of the decoding result of the block decoder 150 to improve equalization performance.</p><p>The known data detector 150 detects the position of the known data inserted by the transmitting side from the input/output data of the demodulator 130, that is, the data before demodulation or the partially demodulated data, and the position along with the position information. The symbol sequence of the known data generated in ? is output to the demodulator 130 and the equalizer 140 . In addition, the known data detector 150 outputs information to the block decoder 160 so that the block decoder 160 can distinguish the mobile service data that has undergone additional encoding at the transmitting side and the main service data that has not been additionally encoded. .</p><p>In the block decoder 160, after channel equalization by the equalizer 140, input data is data on which both block encoding and trellis encoding of the serial concatenated convolution code (SCCC) method are performed at the transmitting side (ie, RS frame). My data), trellis decoding and block decoding are performed in the reverse direction of the transmitting side, and only trellis decoding is performed for data on which only trellis encoding is performed without block encoding (ie, main service data). </p><p>The signaling decoder 190 decodes the input signaling data after channel equalization by the equalizer 140 . It is assumed that the signaling data (or signaling information) input to the signaling decoder 190 is data on which both block encoding and trellis encoding have been performed in the transmission system. Examples of such signaling data include transmission parameter channel (TPC) data and fast information channel (FIC) data. For example, the signaling decoder 190 performs recursive turbo decoding of a parallel concatenated convolution code (PCCC) method on data of a signaling information region among input data, and then extracts FIC data and TPC data from the turbo-decoded signaling data. Separate the data. In addition, the signaling decoder 190 performs RS decoding on the separated TPC data in the reverse direction of the transmitting side, and outputs the RS decoding to the TPC handler 214 . In addition, the signaling decoder 190 performs deinterleaving on the separated FIC data in units of subframes, performs RS decoding in the reverse direction of the transmitting side, and outputs it to the FIC handler 215 . A transmission unit of FIC data that is deinterleaved and RS-decoded by the signaling decoder 190 and output to the FIC handler 215 is an FIC segment.</p><p>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. However, in an embodiment, the division of the primary RS frame and the secondary RS frame depends on the importance of data.</p><p>The primary RS frame decoder 170 receives the output of the block decoder 160 as an input. In this case, it is assumed that the primary RS frame decoder 170 receives, from the block decoder 160, data of a primary RS frame encoded by Reed Solomon (RS) and/or cyclic redundancy check (CRC) encoding. . The primary RS frame decoder 170 corrects errors in the primary RS frame by performing the reverse process of the RS frame encoder (not shown) of the transmission system. That is, the primary RS frame decoder 170 collects a plurality of data groups to form a primary RS frame, and then performs error correction in units of primary RS frames.</p><p>The secondary RS frame decoder 180 receives the output of the block decoder 160 as an input. In this case, according to an embodiment, the secondary RS frame decoder 180 receives data of the RS-encoded and/or CRC-encoded secondary RS frame. The secondary RS frame decoder 180 corrects errors in the secondary RS frame by performing the reverse process of the RS frame encoder (not shown) of the transmission system. That is, the secondary RS frame decoder 180 collects a plurality of data groups to form a secondary RS frame, and then performs error correction in units of secondary RS frames.</p><p>Meanwhile, the management processor 200 according to an embodiment of the present invention includes an M/H Physical Adaptation Processor 210 , an IP network stack 220 , and a streaming handler. handler) 230, SI handler 240, file handler 250, MIME type handler (Multipurpose Internet Mail Extensions) type handler 260, ESG handler 270 , an ESG decoder 280 , and a storage 290 may be included. </p><p>The M/H physical adaptation processor 210 includes a primary RS frame handler 211, a secondary RS frame handler 212, and an M/H-TP handler (M/H). -TP handler 213 , TPC handler 214 , FIC handler 215 , and Physical Adaptation Control Signal Handler 216 . </p><p>The TPC handler 214 receives a sub-frame number, a slot number, a parade id, and a stating group number from the TPC data output from the signaling decoder 190 . ; SGN), group number (number of groups; NOG), parade repetition cycle (PRC), RS frame mode (RS frame mode), RS code mode (RS code mode), SCCC block mode (SCCC block mode) ), SCCC outer code mode, FIC version, total number of groups in subframe (Total Number of Groups; TNoG), parade continuity counter; PCC) and TPC protocol versions are extracted and output to the physical adaptive control signal handler 216 .</p><p>The sub-frame number indicates the number of the current sub-frame in the corresponding M/H frame, and is transmitted for M/H frame synchronization. The slot number indicates the number of the current slot in the corresponding subframe, and is transmitted for M/H frame synchronization. The Parade id indicates an identifier for identifying a parade to which a corresponding data group belongs. At this time, the communication of Parade id between the physical layer and the upper layer is made by an ensemble identifier (Ensemble id) formed by adding 1 bit to the left of the Parade id. The ensemble identifier for distinguishing the primary ensemble transmitted through the parade is formed by indicating 0 in the added MSB, and the ensemble identifier for distinguishing the secondary ensemble may be formed by indicating 1 in the added MSB. .</p><p>The SGN indicates the first slot number for the parade to which the data group belongs. The NOG indicates the number of groups assigned to the parade to which the data group belongs. The PRC indicates a repetition period of a parade transmitted in units of M/H frames. The RS frame mode indicates whether one RS frame or two RS frames are transmitted in one parade. The RS code mode indicates the RS code mode of the 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 indicates the SCCC outer code mode of the data group. The FIC version indicates a version of the FIC data. 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 increases every 4th M/H frame. </p><p>The TNoG field indicates the total number of data groups allocated in one subframe. The TPC protocol version indicates a version of the corresponding TPC syntax structure. The information included in the TPC data is only an embodiment for helping understanding of the present invention, and since addition and deletion of information included in the TPC data can be easily changed by those skilled in the art, the present invention is not limited to the embodiment. won't</p><p>The FIC handler 215 receives FIC data from the signaling decoder 190 and extracts signaling information for service acquisition, that is, mapping information between the ensemble and the mobile service. </p><p>The primary RS frame handler 211 divides the primary RS frame received from the primary RS frame decoder 170 of the baseband processor 100 into each row to configure M/H-TP, and Output to the /H-TP handler 213 . </p><p>The secondary RS frame handler 212 divides the secondary RS frame received from the secondary RS frame decoder 180 of the baseband processor 100 into each row unit to configure M/H-TP, which output to the TP handler 213 . </p><p>The M/H-TP handler 213 extracts each header of the M/H-TP received from the primary and secondary RS frame handlers 211 and 212 and determines data included in the M/H-TP. . If the determined corresponding data is SI data, it is output to the physical adaptation control signal handler 216 (that is, SI data that is not encapsulated into an IP datagram), and in the case of an IP datagram, the IP network stack 220 ) is output.</p><p>The IP network stack 220 processes broadcast data transmitted in the form of an IP datagram. That is, the IP network stack 220 includes User Datagram Protocol (UDP), Real-time Transport Protocol (RTP), Real-time Transport Control Protocol (RTCP), Asynchronous Layered Coding/Layered Coding Transport (ALC/LCT), FLUTE (File Delivery over Unidirectional Transport) processes input data. At this time, if the processed data is streaming data, it is output to the streaming handler 230, in the case of file-type data, it is output to the file handler 250, and in the case of SI data, it is output to the SI handler 240 . For example, the SMT obtained from the IP datagram of the service signaling channel is output to the SI handler 240 .</p><p>The SI handler 240 receives and processes SI data in the form of an IP datagram input to the IP network stack 220 . </p><p>The SI handler 240 outputs to the MIME type handler 260 when the inputted SI data is a MIME type. </p><p>The MIME type handler 260 receives and processes MINE type SI data output from the SI handler 240 . </p><p>The file handler 250 receives data from the IP network stack 220 in the form of an object according to the ALC/LCT and FLUTE structures. The file handler 250 collects the received data and configures it in the form of a file, and when the file includes an Electronic Service Guide (ESG), it outputs it to the ESG handler 270, and other data for file-based services. In this case, it is output to the presentation controller 330 of the presentation processor 300 .</p><p>The ESG handler 270 processes the ESG data received from the File handler 250 and stores it in the storage 290 or outputs it to the ESG decoder 280 to use the ESG data in the ESG decoder 280 . do. </p><p>The storage unit 290 stores SI (System Information) received from the physical adaptation control signal handler 216 and the ESG handler 270, and transmits the stored data to each block. </p><p>The ESG decoder 280 restores the ESG data and SI data stored in the storage unit 290 or the ESG data received from the ESG handler 270 and outputs the format to the presentation controller 330 to the user. print out </p><p>The streaming handler 230 receives data from the IP network stack 220 in a format according to the RTP and RTCP structures. The streaming handler 230 extracts an audio/video stream from the received data and outputs it to the audio/video decoder 310 of the presentation processor 300 . The audio/video decoder 311 decodes the audio stream and the video stream received from the streaming handler 230, respectively.</p><p>The display module 320 of the presentation processor 300 receives the audio and video signals decoded by the A/V decoder 310 and provides them to the user through a speaker and/or a screen. </p><p>The presentation controller 330 is a controller in charge of modules for outputting data received by a receiving system to a user. </p><p>The channel service manager (Channel Service Manager) 340 is in charge of an interface with the user in order to enable the user to use a broadcast service transmitted based on a channel, such as channel map management and channel service access. </p><p>The application manager 350 is in charge of an interface with a user to use an application service other than an ESG display or other channel service. </p><p>That is, the FIC handler 215 restores an FIC chunk from the FIC segments that are deinterleaved and RS-decoded by the signaling decoder 190, analyzes the restored FIC chunk, and extracts signaling information for service acquisition. output to the physical adaptation control signal handler 216 .</p><p>At this time, the FIC handler 215 performs the FIC chunk from the payload of the FIC segments according to the FIC_type field, the FIC_segment_num field, and the FIC_last_segment_num field in each header of the FIC segments reconstructed from one or more subframes decoded by the signaling decoder 190 . to restore Then, using the information included in the restored FIC chunk, it is checked in which ensemble the SGDD is included and received, and the result is output to the physical adaptive control signal handler 216 . In the present invention, it is possible to check which ensemble contains the SGDD by referring to both the ESG_EntryPoint_Location field value of the FIC chunk header and the SG_entry_point_indicator field value of the FIC chunk payload, or which ensemble contains the SGDD by referring to only one of the two fields. have.</p><p>The physical adaptive control signal handler 216 uses the TPC data output from the TPC handler 214, the FIC data output from the FIC handler 215, and the SMT data output from the SI handler 240 to generate SGDD. The baseband processor 100 is controlled to identify the ensemble including, switch to the time slicing mode for receiving the identified ensemble, and receive RS frames belonging to the ensemble for each M/H frame. Then, access information of the service guide announcement channel for transmitting the SGDD or SGDD is obtained from the SMT included in the received RS frame, and the SGDD is received according to the obtained access information. In addition, after obtaining access information of SGDUs from the received SGDD, accessing each FLUSE session according to the obtained access information to collect SGDUs, and extracting SG data from fragments included in the collected SGDUs, the storage unit 290 control to be stored in After that, when there is a user's request, the presentation processor 300 displays the SG information on the screen according to the SG data stored in the storage unit 290 . </p><p>Until now, the access information of the service guide announcement channel including the service guide bootstrap information is signaled through the descriptor (eg, SG access descriptor) of the ensemble level of the SMT included in the service signaling channel. was explained as</p><p>As another embodiment of the present invention, access information of a service guide announcement channel including the service guide bootstrap information may be signaled through a guide access table (GAT). The GAT is received while being included in the service signaling channel. In this case, since IP datagrams of the service signaling channel have the same well-known IP address and well-known UDP port number, the GAT included in the service signaling data is distinguished by a table identifier. That is, the table identifier may be table_id existing in the header of the corresponding table or the corresponding table section, and can be identified by further referring to table_id_extension, if necessary. According to an embodiment, the GAT includes the announcement_channel_TSI field included in the SG connection descriptor of FIG. 12 .</p><p>If access information of a service guide announcement channel including service guide bootstrap information is signaled using the GAT, the SG_entry_point_indicator field of FIG. 9 indicates whether GAT is transmitted through a service signaling channel included in the corresponding ensemble. to instruct For example, when the value of the SG_entry_point_indicator field is 1, it indicates that the GAT is transmitted through a service signaling channel included in the corresponding ensemble.</p><p>In addition, even when GAT is included in the service signaling channel, the flowchart of FIG. 14 and the reception system of FIG. 15 may be used. In this case, the only difference is that the access information of the service guide announcement channel is obtained from the GAT rather than the SMT.</p><p>16 shows an embodiment of a syntax structure for a GAT section according to the present invention. </p><p>In FIG. 16 , the table_id field is an identifier of a table, and an identifier for identifying a GAT may be set. The GAT of FIG. 16 allocates an 8-bit ensemble_id field and an 8-bit GAT_protocol version field to the table_id_extension field position, and may be used as one of table identifiers for identifying the GAT when the GAT is received through a service signaling channel.</p><p>In FIG. 16 , the section_syntax_indicator field is an indicator defining the section format of the GAT. </p><p>The private_indicator field indicates whether the GAT follows a private section. </p><p>The section_length field indicates the section length of the GAT. </p><p>The GAT_protocl_version field indicates the protocol version of the corresponding GAT. </p><p>The ensemble_id field is an ID value related to the corresponding ensemble, and values of 0x00 to 0x3F may be assigned. The value of this field is preferably derived from parade_id of TPC data. If the corresponding 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 corresponding parade. On the other hand, if the corresponding 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 corresponding parade.</p><p>The version_number field indicates the version number of the GAT. </p><p>The section_number field indicates the section number of the current GAT section. </p><p>The last_section_number field indicates the last section number of the GAT. </p><p>The num_SG_provides field indicates the number of SG providers described in the current GAT section. </p><p>The SG_provider_id field indicates an identifier that can uniquely identify each SG provider. </p><p>The SG_provider_name_length field indicates the total length of the SG_provider_name_text() field to be followed. </p><p>The SG_provider_name_text() field indicates the name of the corresponding provider. </p><p>The source_IP_address field indicates a source IP address of a FLUTE session transmitting a service guide announcement channel. </p><p>The IP_version_flag field (1 bit) indicates that the destination_IP_address field is an IPv6 address when it is set to '1', and indicates that the destination_IP_address field is an IPv4 address when it is set to '0'. </p><p>The destination_IP_address field (32 or 128 bits) indicates the destination IP address of the FLUTE session transmitting the service guide announcement channel. If the IP_version_flag field is set to '0', the destination_IP_address field indicates a 32-bit destination IPv4 address for the corresponding service guide announcement channel. When the IP_version_flag field is set to '1', the destination_IP_address field indicates a 64-bit destination IPv6 address for a corresponding service guide announcement channel.</p><p>A destination_UDP_port_num field (16 bits) indicates a destination UDP port number of a FLUTE session transmitting a service guide announcement channel.</p><p>The announcement_channel_TSI field (16 bits) indicates a transport session identifier for a FLUTE session in which the service guide announcement channel is transmitted. </p><p>The present invention described so far is not limited to the above-described embodiments, and as can be seen from the appended claims, modifications can be made by those skilled in the art to which the present invention pertains, and such modifications are within the scope of the present invention. belongs to</p>