KR20090131663A - Transmission / reception system and data processing method - Google Patents

Abstract

A receiving system and a data processing method for receiving a mobile broadcast signal are disclosed. The receiving system includes a receiver, a demodulator, a first handler, and a second handler. The receiver may include fast information channel (FIC) data including a field indicating that a table signaling service guide bootstrap information is included in a service signaling channel, and mobile service data packetized into an RS frame belonging to an ensemble desired to be received. Receive a broadcast signal including the service signaling channel. 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 a service guide announcement channel using the service guide bootstrap information.

Description

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

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

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

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

Another object of the present invention is to provide a digital broadcast transmission / reception system and a data processing method for signaling service guide information using a fast information channel (FIC).

Another object of the present invention is to provide a digital broadcast transmission / reception system and a data processing method for signaling service guide information using a service signaling channel.

Another object of the present invention is to provide a digital broadcast transmission / reception system and a data processing method for receiving service guide information using signaling information of a FIC and signaling information of a service signaling channel.

In order to achieve the above object, a data processing method of a receiving system according to an embodiment of the present invention, a fast information channel (FIC) including a field indicating that the service signaling channel includes a table signaling the service guide bootstrap information Receiving data and a broadcast signal including the service signaling channel and the mobile service data packetized into an RS frame belonging to an ensemble to be received, demodulating the broadcast signal, and a table included in the service signaling channel. Obtaining service guide bootstrap information from the terminal, and accessing a service guide announcement channel using the service guide bootstrap information.

The broadcast signal may further include transmission parameter channel (TPC) data including FIC version information for identifying an update of the FIC data.

In the data processing method of the reception system according to the present invention, the service guide announcement channel is connected to obtain service guide management information, and the service guide information according to the access information of the service guide information included in the service guide management information. The method may further include receiving.

The service signaling management information includes a service guide delivery descriptor (SGDD).

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.

The service guide bootstrap information may be signaled in a descriptor of a service map table (SMT) included in the service signaling channel.

The service guide bootstrap information may be signaled in a field of a guide access table (GAT) included in the service signaling channel.

The reception system according to an embodiment of the present invention may include a receiver, a demodulator, a first handler, and a second handler. The receiver may include fast information channel (FIC) data including a field indicating that a table signaling service guide bootstrap information is included in a service signaling channel, and mobile service data packetized into an RS frame belonging to an ensemble desired to be received. Receive a broadcast signal including the service signaling channel. 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 a service guide announcement channel using the service guide bootstrap information.

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

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

In addition, the present invention efficiently identifies an ensemble for transmitting service guide information by using signaling information of the FIC chunk and signaling information received through a service signaling channel, and receives and processes service guide information from an RS frame belonging to the ensemble. Make it available.

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

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

Definition of terms used in the present invention

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

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

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

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

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

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

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

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

In addition, according to an embodiment of the present invention, the transmission / reception system operates two data channels. One data channel is an RS frame data channel for content transmission, and the other data channel is a fast information channel (FIC) for service acquisition. According to the present invention, mapping information between an ensemble and a mobile service is signaled using an FIC chunk, and the FIC chunk is divided into FIC segments and transmitted through the FIC, thereby enabling fast service acquisition in a receiving system.

1 illustrates an embodiment of a protocol stack for providing a mobile service based on IP.

That is, in the transmission system, mobile service data (eg, A / V streaming) is packetized according to the Real Time protocol (RTP) scheme, and the RTP packet is packetized according to the User Datagram protocol (UDP) scheme again. The / UDP packet is again packetized according to the IP scheme to become RTP / UDP / IP packet data. The packetized RTP / UDP / IP packet data is referred to as an IP datagram for convenience of description in the present invention.

In addition, service information for receiving a mobile service may be provided in a table form, and a service signaling channel for transmitting such a table (eg, a service map table or SMT) is packetized according to a UDP scheme. UDP data is again packetized according to the IP method to become UDP / IP data. In the present invention, the UDP / IP data is also called an IP datagram for convenience of explanation. In this 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.

In the present invention, the IP datagrams are collected in an adaptation layer to form an RS frame, the data of the RS frame is distributed in a plurality of data groups, and then modulated by a predetermined transmission scheme, for example, a VSB transmission scheme, in the mobile physical layer. In this embodiment, the transmission is performed. According to an embodiment of the present invention, each data group includes an FIC segment. The relationship between the RS frame and the FIC segment will be described in detail later.

Meanwhile, a service guide delivery descriptor (SGDD) including access information of announcement information on mobile services may be included in the RS frame and transmitted. At this time, the SGDD is transmitted through a Service Guide Announcement Channel.

In the present invention, the service guide announcement channel is packetized according to a file transfer protocol method and then 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 scheme, and the packetized ALC / LCT / UDP data is again packetized according to the IP scheme to form ALC / LCT / UDP / IP data and then RS frame. In one embodiment it is included in.

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.

In the present invention, a collection of consecutive RS frames having the same FEC code (The same Forward Error Correction codes) is called an ensemble.

According to an embodiment of the present invention, the FIC signals an entry point of the service guide, that is, information for identifying an ensemble including an SGDD.

According to the embodiment of the present invention, the access information of the service guide announcement channel is signaled to the service signaling channel included in the ensemble identified by the FIC.

According to an embodiment of the present invention, the access information of the service guide announcement channel includes service guide bootstrap information. That is, the service guide bootstrap information is information required for bootstrapping the service guide of the mobile service. The service guide bootstrap information includes access information (eg, TSI) of a FLUTE session for transmitting the service guide announcement channel.

In 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).

In the present invention, data included in the RS frame is also referred to as mobile service data for convenience of description.

Data format structure

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

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

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

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

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

In the data group, mobile service data means data of an RS frame. The data of the RS frame will be described later in detail.

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

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

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

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

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

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

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

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

The TPC data mainly includes parameters used in a physical layer module, and is transmitted without being interleaved, so that the reception system can access slot by slot.

The FIC data is provided to enable fast service acquisition in a receiving system and includes cross layer information between a physical layer and a higher layer. The FIC data is interleaved in subframe units and transmitted.

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

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

The RS frame is received for each M / H frame while being switched to the time slicing mode.

RS frame according to an embodiment of the present invention is composed of a plurality of M / H TP (Transport Packet). Each M / H TP consists of a 2-byte M / H header and an N-2 byte M / H payload. 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.

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 an embodiment, the SMT or the IP datagram of the service signaling channel for transmitting the SMT is received in a corresponding RS frame with a well-known IP destination address and a well-known destination UDP port number. do.

In addition, the RS frame may include an IP datagram of SGDD. According to an embodiment of the present invention, the access information of the service guide announcement channel transmitting the SGDD or the SGDD is signaled to the SMT. The access information of the service guide announcement channel includes service guide bootstrap information.

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.

In the transmission system, RS coding is performed on the RS frame in the column direction, CRC coding is performed in the row direction, and then allocated to a corresponding region of a plurality of data groups for transmission. In the present invention, all data included in the RS frame is referred to as mobile service data for convenience of description.

Data transfer structure

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

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

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

One VSB frame consists of two VSB fields (ie, odd field and even field). Each VSB field consists of one field sync segment and 312 data segments.

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

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

Meanwhile, data in one RS frame may be allocated to all of the A / B / C / D areas in the data group or may be allocated to at least one of the A / B / C / D areas. According to an embodiment of the present invention, data in one RS frame is allocated to all of the A / B / C / D areas or only to one of the A / B areas and the C / D areas. That is, in the latter case, the RS frame allocated to the A / B area in the data group and the RS frame allocated to the C / D area are different. According to an embodiment of the present invention, the RS frame allocated to the A / B region in the data group is called a primary RS frame, and the RS frame allocated to the C / D region is a secondary RS frame. frame). The primary RS frame and the secondary RS frame form one parade. That is, if data in one RS frame are all allocated to the A / B / C / D areas in the data group, one parade transmits one RS frame. In contrast, if the 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 data group, one parade may be applied to two RS frames. Can transmit

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

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

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

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

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

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

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

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

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

Hierarchical Signaling  rescue

6 illustrates 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 hierarchical signaling structure in the present invention.

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

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

FIC ( Fast Information Channel )

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

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

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

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

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

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

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

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

In addition, the FIC chunk header according to the present invention may signal an identifier of an ensemble in which an Electronic Service Guide (ESG) entry point, that is, a Service Guide Delivery Descriptor (SGD), is transmitted. In this case, the receiving system can know which ensemble the SGDD is included in and received.

To this end, the FIC chunk header may include an FIC_major_protocol_version field, an FIC_minor_protocol_version field, an FIC_chunk_header_extension_length field, an ensemble_loop_header_extension_length field, an M / H_service_loop_extension_length field, a current_next_indicator field, a transport_stream_idles field, a sng_version_id_field field

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

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

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

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

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

For example, assume that two ensemble (ie, ensemble 0, ensemble 1) exist in the FIC chunk, two mobile services are transmitted through ensemble 0, and one mobile service is transmitted through ensemble 1. If the minor protocol version is changed and the FIC chunk header is extended by one byte, the FIC_chunk_header_extension_length field indicates 001. In this case, one byte extension field (FIC_Chunk_header_extension_bytes field) is added to the end of the FIC chunk header, and the existing receiving system skips the one-byte extension field added to the end of the FIC chunk header without processing.

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

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

As such, when the FIC_minor_protocol version field value is changed, the existing receiving system, that is, the receiving system that cannot accommodate the corresponding minor protocol version change of the FIC chunk, processes the remaining fields except the extension field, and processes the FIC_chunk_header_extension_length, ensemble_loop_header_extension_length, and M / H_service_loop_extension_length fields. The extended fields are skipped without processing. If the receiving system can accommodate the change of the corresponding minor protocol version of the FIC chunk, the corresponding extended field is processed using each length field.

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

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

In an embodiment, the SG_version field allocates 5 bits 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.

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

In an embodiment, the ESG_EntryPoint_Location field allocates 8 bits and indicates an identifier of an ensemble in which an ESG entry point, that is, an SGDD is transmitted. Therefore, the receiving system can know what ensemble the SGDD, that is, the ESG entry point is received.

9 shows an embodiment of the syntax structure of the FIC chunk payload according to the present invention.

The FIC chunk payload includes configuration information of an ensemble and information on a mobile service transmitted through each ensemble, for each ensemble corresponding to a num_ensembles field value in the FIC chunk header of FIG. 8. have. In addition, the FIC chunk payload includes information indicating whether the entry point of the service guide, that is, the SGDD, exists in the ensemble. In this case, the reception system may determine whether the table including the service guide bootstrap information is included in the service signaling channel by using the indication information. The table may be an SMT or a GAT.

The FIC chunk payload consists of an ensemble loop and a mobile service loop below the ensemble loop. Through the FIC chunk payload, the receiving system can determine through which ensemble the desired mobile service is transmitted (this is done by mapping between ensemble_id and M / H_service_id) and receive RS frames belonging to the ensemble.

To this end, the ensemble loop of the FIC chunk payload may include an ensemble_id field, an SG_entry_point_indicator field, an SMT_version field, and a num_MH_services field repeated as much as the num_ensembles field value. 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 which are repeated by a value of a num_MH_services field.

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

In an embodiment, the SG_entry_point_indicator field allocates 1 bit and indicates whether an entry point of the service guide, that is, SGDD, exists in the corresponding ensemble. For example, if the SG_entry_point_indicator field value is 1, it may indicate that SGDD is included in the ensemble, and if it is 0, it may be indicated that it is not included. At this time, when the SG_entry_point_indicator field value is 1, access information of the service guide announcement channel, that is, service guide bootstrap information, is signaled to the service signaling channel included in the ensemble.

Accordingly, the receiving system may identify whether the SGDD is included in the ensemble according to the SG_entry_point_indicator field value. In addition, the receiving system may identify whether the service guide announcement channel connection information, that is, service guide bootstrap information, has been signaled to the service signaling channel included in the ensemble according to the SG_entry_point_indicator field value. That is, the reception system may know whether a table including service guide bootstrap information is included in the service signaling channel according to the SG_entry_point_indicator field value. The table may be an SMT or a GAT.

At this time, 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. In another embodiment, the present invention may include only one of two fields. 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.

In an embodiment, the SMT_version field allocates 5 bits and indicates version information of service map table (SMT) data of a corresponding ensemble.

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

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

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

In an embodiment, the MH_service_type field allocates 5 bits and indicates a type of a corresponding mobile service.

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

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

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

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

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

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

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

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

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

Number of stuffing data bytes = 35-j

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

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

In addition, the present invention may transmit FIC segments divided from one FIC chunk through one subframe or through a plurality of subframes. If the FIC chunk is transmitted as in the latter case, the amount of data to be transmitted through the FIC chunk is larger than the amount of FIC segments transmitted in one subframe (in this case, a plurality of services having a very low bit rate). May be applied.) All necessary signaling data may be transmitted through the FIC chunk.

In this case, the FIC segment number indicates the FIC segment number in each FIC chunk, not the number of the FIC segment in each subframe. By doing so, the dependency between the FIC chunk and the subframe can be eliminated, thereby reducing the waste of the FIC segment.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Meanwhile, FIG. 11 illustrates an embodiment of a bit stream syntax structure of an SMT section providing access information of an SGDD included in an RS frame and transmitted. In this case, the SMT section has been prepared in the form of MPEG-2 private section to facilitate understanding, but the format of the data of the SMT section may be in any form.

The SMT may provide access information of mobile services in an ensemble in which the SMT is included. In addition, the SMT may provide information essential for rendering a mobile service. The SMT may include one or more descriptors and may describe other additional information through the descriptor.

According to an embodiment of the present invention, when an SGDD is included in an ensemble including the SMT, the access information of the SGDD is provided using a descriptor of the SMT. According to an embodiment of the present invention, the descriptor of the SMT is an ensemble level descriptor.

In this case, the service signaling channel for transmitting the SMT may further include another signaling table (eg, GAT) in addition to the SMT. At this time, the 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 a table identifier. That is, the table identifier may be table_id existing in the header of the table or the table section, and may be distinguished by further referring to table_id_extension if necessary.

Examples of fields that may be transmitted through the SMT section are as follows.

A table_id field (8 bits) is a field for distinguishing a type of table. Through this, it can be seen that the table is an SMT.

The section_syntax_indicator field (1 bit) is an indicator defining a section format of the SMT, and the section format may be, for example, a short-form syntax ('0') of MPEG (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).

The private_indicator field (1 bit) indicates whether the SMT follows the private section.

A section_length field (12 bits) indicates a section length of the remaining SMT after this field (section_length: A 12-bit field.It specifies the number of remaining bytes this table section immediately following this field.).

A 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.

SMT_protocol_version: An 8-bit unsigned integer field whose function is to allow, in the the SMT_protocol_version field (8 bits) indicates the protocol version to allow SMT to transmit parameters whose parameters differ from those defined in the current protocol. future, this SMT to carry parameters that may be structured differently than those defined in the current protocol.At present, the value for the SMT_protocol_version shall be zero.Non-zero values of SMT_protocol_version may be used by a future version of this standard to indicate structurally different tables).

An ensemble_id field (8 bits) is an ID value associated with a corresponding ensemble, and values of 0x00 to 0x3F may be allocated. The value of this field is preferably derived from parade_id of TPC data. If the ensemble is transmitted through the primary RS frame, the most significant bit (MSB) is set to '0' and the remaining 7 bits are used as the parade_id value of the parade. Meanwhile, if the ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to '1' and the remaining 7 bits are used as the parade_id value of the parade.

A version_number field (5 bits) represents the version number of the SMT.

A current_next_indicator field (1 bit) indicates whether the SMT section is currently applicable.

A section_number field (8 bits) indicates the number of the current SMT section.

The last_section_number field (8 bits) indicates the last section number constituting the SMT.

A 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.).

Thereafter, a 'for' loop (or a mobile service loop) is performed as many as the number of mobile services corresponding to the num_MH_services field value to provide signaling information for a plurality of mobile services. That is, signaling information of the mobile service is displayed for each mobile service included in the SMT section. At this time, the following field information may be provided for each mobile service.

The MH_service_id field (16 bits) indicates a value that can uniquely identify the mobile service (A 16-bit unsigned integer number that shall uniquely identify this mobile service within the scope of this SMT section.).

The Multi_ensemble_service field (2 bits) identifies whether the corresponding mobile service is transmitted through one or more ensemble.

An MH_service_status field (2 bits) identifies the status of the 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').

An SP_indicator field (1 bit) indicates whether service protection of a corresponding mobile service is performed. 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 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).

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 bytes.

The short_MH_service_name field represents a short name of the corresponding mobile service.

An MH_service_category field (6 bits) identifies the type category of the corresponding mobile service.

A num_components field (5 bits) indicates the number of IP stream components in the mobile service (num_components: This 5-bit field specifies the number of IP stream components in this mobile service).

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 the source_IP_address field, MH_service_destination_IP_address field and component_destination_IP_address field when the source_IP_address field, the MH_service_destination_IP_address field, and the component_destination_IP_address field are 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).

When the source_IP_address_flag field (1 bit) is set, it is a flag indicating that a source IP address value for the corresponding service exists to indicate 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).

When the MH_service_destination_IP_address_flag field (1 bit) is set, this indicates that the corresponding IP stream component is transmitted through an IP datagram having a destination IP address different from MH_service_destination_IP_address. Therefore, when this flag is set, the receiving system uses component_destination_IP_address as the destination_IP_address and ignores the MH_service_destination_IP_address field in the num_MH_services loop to access the corresponding IP stream component.

The source_IP_address field (32 or 128 bits) needs to be interpreted when the source_IP_address_flag is set to '1', but does not need to be interpreted when the source_IP_address_flag is not set to '0'. When 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 a source of the mobile service. If the IP_version_flag field is set to '1', this field indicates a 32-bit IPv6 address indicating a source of the mobile service.

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'. If 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. If 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 the 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 resolved, and the receiving system must use component_destination_IP_address to access the IP stream component.

Meanwhile, the SMT according to the present embodiment provides information about a plurality of components by using a for loop.

Thereafter, a 'for' loop (or a component loop) is performed as many as the number of components corresponding to the num_components field value, thereby providing access information for a plurality of components. That is, the connection information of each component included in the mobile service is provided. In this case, the following field information may be provided for each component.

The essential_component_indicator field (1 bit), if set to '1', indicates that the corresponding component is an essential component for a mobile service. Otherwise_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).

component_destination_IP_address_flag field (1 bit) is a flag indicating that a component_destination_IP_address field exists for a corresponding component when it is set to '1' (that 1-bit Boolean flag that shall indicate, when set to '1', that the component_destination_IP_address is present for this component).

A port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component. The destination UDP port number is incremented by 1 starting from the value of the destination_UDP_port_num field.

A destination_UDP_port_num field (16 bits) indicates a destination UDP port number for the corresponding IP stream component.

If the component_destination_IP_address field (32 or 128 bits) is set to '0' in the IP_version_flag field, this field indicates a 32-bit destination IPv4 address for the corresponding IP stream component. If 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).

A num_component_level_descriptors field (4 bits) indicates the number of descriptors that provide additional information of the component level.

The component_level_descriptor () is included in the component loop as many as the number corresponding to the num_component_level_descriptors field value, thereby providing additional information about the component.

A num_MH_service_level_descriptors field (4 bits) indicates the number of descriptors that provide additional information of the corresponding mobile service level.

Service_level_descriptor () is included in the mobile service loop as many as the number corresponding to the num_MH_service_level_descriptors field value, thereby providing additional information about the mobile service.

A num_ensemble_level_descriptors field (4 bits) is the number of descriptors that provide additional information of the ensemble level.

Ensemble_level_descriptor () is included in the ensemble loop as many as the number corresponding to the num_ensemble_level_descriptors field value, thereby providing additional information about the ensemble.

On the other hand, if the FIC indicates that the ESG entry point, that is, 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 an ensemble having an ensemble identifier of A using at least one of an ESG_EntryPoint_Location field and an SG_entry_point_indicator field. At this time, if the ensemble_id field value of the SMT is A, an SG access descriptor SG_Access_Descriptor is included in the SMT and received.

According to an embodiment of the present invention, 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.

12 illustrates an embodiment of a bit stream syntax structure of the SG access descriptor SG_Access_Descriptor () according to the present invention.

Description of each field of the SG access descriptor SG_Access_Descriptor () is as follows.

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.

A descriptor_length field (8 bits) indicates the remaining length of the descriptor in byte units from the descriptor_length field to the end of this descriptor.

The IP_version_flag field (1 bit) indicates that the destination_IP_address field is an IPv6 address when set to '1', and indicates that the destination_IP_address field is an IPv4 address when set to '0'.

An address_count field (7 bits) is a counter indicating how many IP addresses from the destination_IP_address field described below are transmitted for transport of corresponding mobile service data.

A destination_IP_address field (32 or 128 bits) indicates the destination IP address of the FLUTE session carrying 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. If the IP_version_flag field is set to '1', the destination_IP_address field indicates a 64-bit destination IPv6 address for the corresponding service guide announcement channel.

A destination_UDP_port_num field (16 bits) indicates a destination UDP port number of a FLUTE session that carries a service guide announcement channel (Represents the destination UDP port number where the FLUTE session carrying SGDD is transported.).

The announcement_channel_TSI field (16 bits) indicates a transport session identifier for a FLUTE session through which a service guide announcement channel is transmitted.

That is, by using the destination_IP_address field and the destination_UDP_port_num field, an IP datagram of a service guide announcement channel transmitting SGDD is obtained from a corresponding ensemble, an ALC / LCT header is removed from the obtained IP datagram, and an announcement_channel_TSI field is obtained. It connects to the corresponding FLUTE session and receives SGDD. FLUTE session information of SGDUs can be obtained from the received SGDD, and all FLUTE sessions can be accessed according to the FLUTE session information to receive SGDUs. The SGDU includes one or more fragments.

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.

Meanwhile, the access information of the SGDD as shown in FIG. 12 may be provided in a table format. In this case, according to an embodiment of the present invention, a table including access information of the SGDD is transmitted through a service signaling channel. According to an embodiment of the present invention, the table including the access information of the SGDD is determined by a table identifier. The table identifier may be table_id existing in the header of the table or the table section, and may be distinguished by further referring to table_id_extension if necessary.

13 shows a relationship between a service guide structure to be used in an M / H system according to the present invention, FIC chunk, and SMT. Each SG fragment is grouped into SGDU units and transmitted through a FLUTE session. SGDD includes access information on a FLUTE session transmitting each SGDU. The FIC chunk informs through which ensemble the SGDD is transmitted, and the SMT included in the ensemble transmitting the SGDD informs the IP access information of the SGDD or the access information of the FLUTE session by using an SG connection descriptor. By doing so, the receiving system can efficiently access the ESG.

In FIG. 13, the service guide includes an administrative group providing upper configuration information of the entire service guide, a provisioning group providing service subscription and purchase information, service, content, and service schedule. Core Groups that provide key information, and Access Groups that provide access information to access services or content.

In FIG. 13, the administrative group is a group that provides basic information for receiving a service guide in 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 the grouping of the SGDU ( Grouping) informs an entry point for receiving information and notification messages.

The supply group is a group providing fee information for receiving a service, and includes a Purchasing Item fragment, a Purchasing data fragment, and a Purchasing 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. Arrows in FIG. 13 indicate reference relationships. According to this example, the aperture 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 represents the possible number of each sub unit information. And the number represents the possible number of each fragment.

The main fragments of the illustrated fragments are described as follows.

The service fragment contains information about a service provided to the user, for example a service such as one conventional television channel.

The content fragment includes metadata about content. For example, types of A / V, text, and image for the content may be included in the content fragment.

The schedule fragment includes schedule information for one piece of content of a service. For example, the broadcast time of the content may correspond to this.

The aperture item fragment includes item information related to a purchase.

The aperture data fragment includes information related to the purchase of a service that a user can purchase. The aperture channel fragment refers to an interface through which a terminal or a user communicates with a purchase system. The aperture channel fragment includes parameters related to a purchase system or information on management of a purchase channel.

The access fragment includes information related to access of a service or content.

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, but the above detailed element values and attribute values do not limit the present invention. The present invention can be applied to all element values and attribute values defined as needed in providing a service guide.

14 is a flowchart illustrating an embodiment of a method for receiving a service guide using an FIC chunk and an SMT according to the present invention.

In FIG. 14, when the physical transport channel including the mobile service selected by the user is tuned, the mobile broadcast signal transmitting the mobile service selected by the user is checked from the tuned physical transport channel (S101). The demodulated mobile broadcast signal is demodulated (S102). Then, FIC segments are obtained from the demodulated mobile broadcast signal to recover FIC chunks (S103 and S104).

That is, a subframe in which the demodulated mobile broadcast signal is transmitted and a slot allocated to the subframe are found. Then, the data groups received through the slots of the found subframe are collected. PCCC decoding is performed on the FIC data received in each signaling information region of the collected data groups, deinterleaving is performed on a subframe basis, and RS decoding is performed in the reverse side of the transmitter. Then, the FIC segments are restored for each subframe. This process is performed for one or more subframes and recovers FIC chunks from the payload of the FIC segments according to the FIC_type field, FIC_segment_num field, and FIC_last_segment_num field in each header of the FIC segments reconstructed from the one or more subframes.

According to an embodiment of the present invention, the recovered FIC chunk includes a FIC chunk header as shown in FIG. 8 and an FIC chunk payload as shown in FIG. 9.

The transport stream ID of the mobile broadcast in 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 configured 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.

In addition, it is checked in which ensemble the SGDD is received from the restored FIC chunk (S107).

In the present invention, 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, it is possible to check which ensemble includes the SGDD or to determine which ensemble contains the SGDD by referring to only one of the two fields. have.

When the ensemble including the SGDD is identified in S107, the receiving system switches to the time slicing mode for receiving the 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 are received.

An SMT is obtained from the received RS frame (S109). According to an embodiment of the present invention, the SMT is included in a service signaling channel having a well-known IP address and a well-known UDP port number. That is, an 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.

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 access information of the SGDD (S110). According to an embodiment of the present invention, the SG connection descriptor includes a destination IP address, a destination UDP port number, and a TSI of a service guide announcement channel.

Accordingly, the IP datagram of the service guide signaling channel transmitting the SGDD from the corresponding RS frame is obtained using the destination IP address and the destination UDP port number (S111).

After removing the ALC / LCT header from the obtained IP datagram, SGDD is received by accessing the corresponding FLUTE session using the announcement_channel_TSI field (S112). Acquiring access information of SGDUs from the received SGDD, and accessing each FLUSE session according to the obtained access information to collect SGDUs (S113). The SGDU includes one or more fragments. The SG data is extracted and stored from fragments included in the collected SGDUs. Thereafter, upon request of the user, the receiving system displays the SG information according to the stored SG data.

According to an embodiment of the present invention, S103 is performed by a signaling decoder, S104 through S107 are performed by an FIC handler or a physical adaptive control signal handler, and S108 is performed by an RS frame decoder and an RS frame handler. The S109 and S110 may be performed by the SI handler or the physical adaptive control signal handler, the S111 may be performed by the IP network stack, and the S112 and S113 may be performed by the file handler and the ESG handler or the physical adaptive control signal handler. Shall be.

Receiving system

15 is a block diagram illustrating a configuration 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.

The receiving system according to the present embodiment includes a baseband processor 100, a management processor 200, and a presentation processor 300.

The baseband processor 100 includes an operation controller 110, a tuner 120, a demodulator 130, an equalizer 140, and a known data detector. 150, Mobile Handheld Block Decoder 160, Primary Reed Solomon Frame Decoder 170, Secondary RS Frame Decoder 180, and Signaling Decoder 190 It may include.

The operation controller 110 controls the operation of each block of the baseband processor 100.

The tuner 120 serves to receive main service data, which is a broadcast signal for a fixed broadcast reception device, and mobile service data, which is a broadcast signal for a mobile broadcast reception device, by tuning the reception system to a frequency of a specific physical channel. . In this case, the tuned frequency of the specific channel is down-converted to an intermediate frequency (IF) signal and outputted 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, only mobile service data, or may include both main service data and mobile service data. The mobile service data may be data of an RS frame or data for mobile service in a data group.

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

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

The known data detector 150 detects a known data position inserted by the transmitting side from the input / output data of the demodulator 130, that is, data before demodulation or data which has been partially demodulated, and the position along with the position information. The symbol sequence of the known data generated by the output is output to the demodulator 130 and the equalizer 140. In addition, the known data detector 150 outputs the information to the block decoder 160 so that the block decoder 160 can distinguish the mobile service data that has been additionally encoded and the main service data that have not been further encoded at the transmitting side. .

The block decoder 160 performs data equalization after channel equalization in the equalizer 140, and the data in which both the block encoding and the trellis encoding of the serial concatenated convolution code (SCCC) scheme are performed at the transmitting side (that is, RS frame). In this case, the trellis decoding and the block decoding are performed inversely to the transmitting side. If the trellis encoding is performed without the block encoding, that is, only the trellis decoding is performed.

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

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, according to an embodiment, the division of the primary RS frame and the secondary RS frame depends on the importance of data.

The primary RS frame decoder 170 receives an output of the block decoder 160 as an input. In this embodiment, the primary RS frame decoder 170 receives data of a primary RS frame encoded with Reed Solomon (RS) encoding and / or a cyclic redundancy check (CRC) encoding from the block decoder 160 according to an embodiment. . The primary RS frame decoder 170 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the primary RS frame. 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 on a primary RS frame basis.

The secondary RS frame decoder 180 receives an output of the block decoder 160 as an input. In this embodiment, the secondary RS frame decoder 180 receives data of a secondary RS frame encoded and / or CRC encoded. The secondary RS frame decoder 180 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the secondary RS frame. That is, the secondary RS frame decoder 180 collects a plurality of data groups to form a secondary RS frame and then performs error correction in units of the secondary RS frame.

Meanwhile, the management processor 200 according to an embodiment of the present invention may include 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 (MIME (Multipurpose Internet Mail Extensions) type handler) 260, ESG handler 270, an ESG decoder 280, and a storage 290.

The M / H physical adaptation processor 210 may include a primary RS frame handler 211, a secondary RS frame handler 212, and an M / H-TP handler. -TP handler 213, TPC handler 214, FIC handler 215, and Physical Adaptation Control Signal Handler 216.

The TPC handler 214 is a sub-frame number, a slot number, a parade id, a group start number from a TPC day output from the signaling decoder 190. ; SGN), number of groups (NOG), parade repetition cycle (PRC), RS frame mode, RS code mode, SCCC block mode ), SCCC outer code mode, FIC version, Total Number of Groups (TNoG), parade continuity counter (PCC), TPC protocol version ( TPC protocol versions) are extracted and output to the physical adaptive control signal handler 216.

The sub-frame number indicates the number of the current subframe 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 the data group belongs. At this time, communication of the Parade id between the physical layer and the upper layer is performed by an ensemble id formed by adding 1 bit to the left side of the Parade id. An ensemble identifier for identifying a primary ensemble transmitted through the parade may be formed by displaying 0 in the added MSB, and an ensemble identifier for identifying a secondary ensemble may be formed by displaying 1 in the added MSB. .

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 M / H frame units. 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 a data group are allocated to an 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 is incremented every fourth M / H frame.

The TNoG field indicates the number of all 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 better understanding of the present invention, and the present invention is not limited to the above embodiments because addition and deletion of the information included in the TPC data can be easily changed by those skilled in the art. Will not.

The FIC handler 215 receives FIC data from the signaling decoder 190 and extracts signaling information for service acquisition, that is, mapping information between an ensemble and a mobile service.

The primary RS frame handler 211 configures M / H-TP by dividing the primary RS frame received from the primary RS frame decoder 170 of the baseband processor 100 in units of rows, and M Output to / H-TP handler 213.

The secondary RS frame handler 212 configures the M / H-TP by dividing the secondary RS frame received from the secondary RS frame decoder 180 of the baseband processor 100 in units of rows, and M / H- Output to TP handler 213.

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 to determine data included in the corresponding M / H-TP. . If the determined data is SI data, it is output to the physical adaptive control signal handler 216 (i.e., SI data is not encapsulated into an IP datagram). )

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 (RTC), Asynchronous Layered Coding / Layered Coding Transport (FLC), and FLUTE. Processes input data such as (File Delivery over Unidirectional Transport). At this time, if the processed data is streaming data, it is output to the streaming handler 230, if the data of the file (File) type is output to the file handler 250, and if the data for SI 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.

The SI handler 240 receives and processes SI data in the form of an IP datagram input to the IP network stack 220.

The SI handler 240 outputs to the MIME type handler 260 when the data on the input SI is a MIME type.

The MIME type handler 260 receives and processes SI data of a MINE type output from the SI handler 240.

The file handler 250 receives data from the IP network stack 220 in the form of an object according to ALC / LCT, FLUTE structure. The file handler 250 collects the received data and configures the file in a file form. When the file includes the ESG (Electronic Service Guide), the file handler 250 outputs the data to the ESG handler 270. In one case, it outputs to the presentation controller 330 of the presentation processor 300.

The ESG handler 270 processes the ESG data received from the file handler 250 and stores the ESG data in the storage unit 290 or outputs the ESG decoder 280 to use the ESG data in the ESG decoder 280. Do it.

The storage unit 290 stores the system information (SI) received from the physical adaptive control signal handler 216 and the ESG handler 270, and transmits the stored data to each block.

The ESG decoder 280 restores the ESG data and the SI data stored in the storage unit 290 or the ESG data received from the ESG handler 270 to the presentation controller 330 as a format for outputting to the user. Output

The streaming handler 230 receives data from the IP network stack 220 in the form of 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.

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.

The presentation controller 330 is a controller in charge of modules for outputting data received by a receiving system to a user.

The channel service manager 340 is responsible for the interface with the user in order to enable the user to use a broadcast service transmitted on a channel basis, such as channel map management and channel service access.

The application manager 350 manages an interface with a user for using an application service, not an ESG display or other channel service.

That is, the FIC handler 215 restores FIC chunks from the FIC segments deinterleaved and RS decoded and output by the signaling decoder 190, and extracts signaling information for service acquisition by analyzing the recovered FIC chunks. Output to physical adaptive control signal handler 216.

At this time, the FIC handler 215 is a FIC chunk from the payload of the FIC segments according to the FIC_type field, FIC_segment_num field, and FIC_last_segment_num field in each header of the FIC segments recovered from the at least one subframe decoded by the signaling decoder 190 Restore it. Then, using the information included in the restored FIC chunk, the SGDD is included in the ensemble and received, and the result is output to the physical adaptive control signal handler 216. In the present invention, 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, it is possible to check which ensemble includes the SGDD, or to determine which ensemble contains the SGDD by referring to only one of the two fields. have.

The physical adaptive control signal handler 216 performs SGDD using TPC data output from the TPC handler 214, FIC data output from the FIC handler 215, and SMT data output from the SI handler 240. The baseband processor 100 controls the baseband processor 100 to identify the ensemble and to switch to a time slicing mode for receiving the identified ensemble, to receive RS frames belonging to the ensemble for each M / H frame. In addition, access information of a service guide announcement channel for transmitting the SGDD or SGDD is obtained from the SMT included in the received RS frame, and control is performed to receive the SGDD according to the obtained access information. The storage unit 290 obtains access information of SGDUs from the received SGDD, collects SGDUs by accessing each FLUSE session according to the obtained access information, and extracts SG data from fragments included in the collected SGDUs. Control to save to. Thereafter, when a user's request is made, the presentation processor 300 displays SG information on the screen according to the SG data stored in the storage unit 290.

Until now, the access information of the service guide announcement channel including the service guide bootstrap information is signaled through a descriptor of an ensemble level of the SMT included in the service signaling channel (eg, an SG connection descriptor). As described.

In another embodiment of the present invention, the 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 included in the service signaling channel and received. In this case, since the IP datagrams of the service signaling channel have the same well-known IP address and the 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 table or the table section, and may be distinguished by further referring to table_id_extension if necessary. According to an embodiment of the present invention, the GAT includes an announcement_channel_TSI field included in the SG access descriptor of FIG. 12.

If the GAT is used to signal access information of a service guide announcement channel including service guide bootstrap information, the SG_entry_point_indicator field of FIG. 9 indicates whether the GAT is transmitted to a service signaling channel included in the ensemble. To indicate. For example, when the SG_entry_point_indicator field value is 1, it indicates that GAT is transmitted through a service signaling channel included in the ensemble.

Further, even when the GAT is included in the service signaling channel, the flowchart of FIG. 14 and the receiving 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.

16 shows an embodiment of a syntax structure for a GAT section according to the present invention.

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 a table_id_extension field position, and may be used as one of a table identifier for distinguishing the GAT when the GAT is received through a service signaling channel.

In FIG. 16, the section_syntax_indicator field is an indicator defining a section format of a GAT.

The private_indicator field indicates whether the GAT follows a private section.

The section_length field represents the section length of the GAT.

The GAT_protocl_version field indicates the protocol version of the GAT.

The ensemble_id field is an ID value associated with a corresponding ensemble and may be assigned values of 0x00 to 0x3F. The value of this field is preferably derived from parade_id of TPC data. If the ensemble is transmitted through the primary RS frame, the most significant bit (MSB) is set to '0' and the remaining 7 bits are used as the parade_id value of the parade. Meanwhile, if the ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to '1' and the remaining 7 bits are used as the parade_id value of the parade.

The version_number field represents a version number of the GAT.

The section_number field represents a section number of the current GAT section.

The last_section_number field represents the last section number of the GAT.

The num_SG_provides field indicates the number of SG providers described in the current GAT section.

The SG_provider_id field indicates an identifier that can uniquely identify each SG provider.

The SG_provider_name_length field indicates the total length of the SG_provider_name_text () field to be followed.

The SG_provider_name_text () field indicates the name of the provider.

The source_IP_address field indicates the source IP address of the FLUTE session for transmitting the service guide announcement channel.

The IP_version_flag field (1 bit) indicates that the destination_IP_address field is an IPv6 address when set to '1', and indicates that the destination_IP_address field is an IPv4 address when set to '0'.

A destination_IP_address field (32 or 128 bits) indicates the destination IP address of the FLUTE session carrying 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. If the IP_version_flag field is set to '1', the destination_IP_address field indicates a 64-bit destination IPv6 address for the corresponding service guide announcement channel.

A destination_UDP_port_num field (16 bits) indicates the destination UDP port number of the FLUTE session for transmitting the service guide announcement channel.

The announcement_channel_TSI field (16 bits) indicates a transport session identifier for a FLUTE session through which a service guide announcement channel is transmitted.

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

1 illustrates an embodiment of a protocol stack for a mobile service according to the present invention.

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

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

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

5 illustrates an embodiment of a data transmission structure for a mobile service according to the present invention.

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

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

8 is a diagram illustrating an embodiment of a syntax structure of an FIC chunk header according to the present invention.

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

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

11 is a diagram illustrating an embodiment of a syntax structure of a service map table (SMT) according to the present invention.

FIG. 12 is a diagram illustrating an embodiment of a syntax structure of an SG access descriptor included in the SMT. FIG.

13 shows the relationship between the SG structure and the FIC chunk and the SMT.

14 is a flowchart illustrating an embodiment of a method for receiving a service guide using an FIC chunk and an SMT according to the present invention.

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

16 illustrates an embodiment of a syntax structure of a guide access table (GAT) section according to the present invention.

Claims (15)

High-speed information channel (FIC) data including a field indicating that a table signaling service guide bootstrap information is included in a service signaling channel, and mobile service data packetized into an RS frame belonging to an ensemble to be received and the service signaling. Receiving a broadcast signal comprising a channel; Demodulating the broadcast signal; Obtaining service guide bootstrap information from a table included in the service signaling channel; And And accessing a service guide announcement channel by using the service guide bootstrap information. The method of claim 1, And the broadcast signal further includes transmission parameter channel (TPC) data including FIC version information for identifying an update of the FIC data. The method of claim 1, Accessing the service guide announcement channel to obtain service guide management information; And And receiving the service guide information according to the access information of the service guide information included in the service guide management information. The method of claim 3, wherein The service signaling management information includes a service guide delivery descriptor (SGDD). The method of claim 1, 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. The method of claim 1, And the service guide bootstrap information is signaled to a descriptor of a service map table (SMT) included in the service signaling channel. The method of claim 6, And the service guide bootstrap information is signaled in a field of a descriptor included in the ensemble level of the SMT. The method of claim 1, And the service guide bootstrap information is signaled in a field of a guide access table (GAT) included in the service signaling channel. The method of claim 1, And the service guide bootstrap information includes FLUTE session access information of the service guide announcement channel. High-speed information channel (FIC) data including a field indicating that a table signaling service guide bootstrap information is included in a service signaling channel, and mobile service data packetized into an RS frame belonging to an ensemble to be received and the service signaling. A receiver configured to receive a broadcast signal including a channel; A demodulator for demodulating the broadcast signal; A first handler for obtaining service guide bootstrap information from a table included in the service signaling channel; And And a second handler for accessing a service guide announcement channel using the service guide bootstrap information. The method of claim 10, The broadcast signal further includes transmission parameter channel (TPC) data including FIC version information for identifying an update of the FIC data. The method of claim 10, wherein the second handler is A reception system accessing the service guide announcement channel to obtain service guide management information, and receiving service guide information according to access information of the service guide information included in the obtained service guide management information. The method of claim 12, The service signaling management information includes a service guide delivery descriptor (SGDD), and the service guide bootstrap information includes FLUTE session access information of the service guide announcement channel. The method of claim 10, 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. The method of claim 10, And the service guide bootstrap information is signaled in a field of an ensemble level descriptor of a service map table (SMT) included in the service signaling channel.

Images