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

Abstract

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

FIC, service guide, service map table

Description

TECHNICAL FIELD [0001] The present invention relates to a transmission / reception system and a data processing method,

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

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

Accordingly, it is an object of the present invention to provide a digital broadcasting transmission / reception system and a data processing method which are resistant to channel variation and noise.

It is another object of the present invention to provide a digital broadcasting transmission / reception system and a data processing method for signaling service guide information using an FIC (Fast Information Channel).

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

It is still another object of the present invention to provide a digital broadcasting transmission / reception system and a data processing method for receiving service guide information using signaling information of an 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 includes a step of transmitting a service guide bootstrap information to a service signaling channel through a FIC ) Data, and a broadcast signal including the service signaling channel and mobile service data packetized into an RS frame belonging to an ensemble to which reception is desired, demodulating the broadcast signal, determining a table included in the service signaling channel Obtaining service guide bootstrap information from the service guide bootstrap information, and accessing the 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 capable of identifying an update of the FIC data.

A data processing method of a receiving system according to the present invention is characterized by comprising the steps of: acquiring service guide management information by accessing the service guide announcement channel; acquiring service guide information according to access information of the service guide information included in the service guide management information; The method comprising the steps of:

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

The FIC data comprises 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 to 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.

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

Other objects, features and advantages of the present invention will become apparent from the detailed description of embodiments with reference to the accompanying drawings.

In 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 an FIC, thereby enabling quick service acquisition in a receiving system.

Also, the present invention efficiently identifies an ensemble for transmitting service guide information by using the signaling information of the FIC chunk and the signaling information received through the service signaling channel, receives service guide information from the RS frame belonging to the ensemble, So that it can be used.

The present invention is advantageous in that it is error-resistant when transmitting mobile service data through a channel and is also compatible with existing receivers. The present invention is advantageous in that mobile service data can be received without error even in a channel with ghost and severe noise. The present invention can improve reception performance of a receiving system in an environment where a channel change is severe by inserting and transmitting known data at a specific location in a data area. Particularly, the present invention is more effective when applied to portable and mobile receivers where channel changes are severe and robustness against noise is required.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. The structure and operation of the present invention shown in the drawings and described by the drawings are described as at least one embodiment, and the technical ideas and the core structure and operation of the present invention are not limited thereby.

Definitions of terms used in the present invention

The terms used in the present invention are selected from general terms that are widely used in the present invention while considering the functions of the present invention. However, the terms may vary depending on the intention or custom of the artisan or the emergence of new technology. Also, in certain cases, there may be a term selected arbitrarily by the applicant, in which case the meaning thereof will be described in detail in the description of the corresponding invention. Therefore, it is to be understood that the term used in the present invention should be defined based on the meaning of the term rather than the name of the term, and on the contents of the present invention throughout.

Among the terms used in the present invention, main service data may include audio / video (A / V) data as data that can be received by a fixed receiving system. That is, the main service data may include HD (High Definition) or SD (Standard Definition) A / V data, and various data for data broadcasting may be included. The known data is previously known data by the promise 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 type. The M / H service data includes at least one of mobile service data and handheld service data. For convenience of explanation, the M / H service data is also referred to as mobile service data. At this time, the mobile service data may include not only M / H service data but also service data indicating movement or carrying, so that the mobile service data will not be limited to the M / H service data. The data required for mobile services is also referred to as mobile service data.

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

The data service using the mobile service data may include a weather service, a traffic service, a securities service, a viewer participation quiz program, a real-time opinion survey, an interactive education broadcast, a game service, a plot of a drama, Providing information on programs by service, media, hourly, or topic that enables information service for information, information on past competitions of sports, profiles and grades of athletes, and product information and orders Or the like, and the present invention is not limited thereto.

The transmission system of the present invention allows backward compatible, main service data and mobile service data to be multiplexed on the same physical channel without any influence on reception of main service data in an existing receiving system.

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

By using the transmission system according to the present invention, it is possible to receive and receive mobile service data in a receiving system, and to receive stable mobile service data even with various distortions and noises occurring in a channel.

In addition, the transmitting / receiving system of the present invention operates two data channels. One of the data channels is an RS frame data channel for content transmission, and the other data channel is a Fast Information Channel (FIC) for service acquisition. In 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 an FIC, thereby enabling quick service acquisition in a receiving system.

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

That is, in the transmission system, the mobile service data (for example, A / V streaming) is packetized according to the RTP (Real Time Protocol) method, the RTP packet is packetized again according to the UDP (User Datagram Protocol) / 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 in the present invention for convenience of explanation.

The service signaling channel for transmitting the table (for example, the service map table, SMT) is packetized according to the UDP scheme, and the packetized The UDP data is again packetized according to the IP scheme to become UDP / IP data. The UDP / IP data is also referred to as an IP datagram in the present invention for convenience of explanation. At this time, 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 adaptation layer collects the IP datagrams to form an RS frame, disperses the data of the RS frame into a plurality of data groups, and then modulates the transmission method, for example, a VSB transmission method, And transmits it. The FIC segment is included in each data group. The relationship between the RS frame and the FIC segment will be described later in detail.

Meanwhile, a service guide delivery descriptor (SGDD) including access information of announcement information for mobile services may be included in the RS frame and transmitted. In this case, 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, and packetized according to an ALC / LCT (Asynchronous Layered Coding / Layered Coding Transport) 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, As shown in Fig.

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 Forward Error Correction codes is referred to as an ensemble.

In the present invention, it is an embodiment to signal to the FIC information capable of identifying an entry point of the service guide, that is, an ensemble including SGDD.

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

In an embodiment of the present invention, the service guide announcement channel connection information includes service guide bootstrap information. That is, the service guide bootstrap information is information necessary for bootstrapping the service guide of the mobile service. The service guide bootstrap information includes connection information (e.g., TSI) of a FLUTE session transmitting the service guide announcement channel.

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

For convenience of description, data included in the RS frame is also referred to as mobile service data.

Data format structure

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

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

In the data structure according to FIG. 2, the data group is divided into 10 M / H blocks (M / H blocks B1 to B10). And each M / H block has a length of 16 segments. In FIG. 2, only the RS parity data is allocated to a part of the 5 segments preceding the M / H block B1 and the 5 segments after the M / H block B10, and is excluded from the A area to the D area of the data group.

That is, assuming that one data group is divided into A, B, C, and D regions, each M / H block is divided into any one of the A region to the D region according to the characteristics of each M / Can be included. In this case, each M / H block may be included in any one of the A region to the D region according to the degree of interference of the main service data.

The reason why the data group is divided into a plurality of regions is to differentiate each use. That is, a region where there is no interference of the main service data or a region where there is no interference can show robust reception performance than the region where no interference occurs. In addition, when a system for inserting known data known by the promise of a transmitting / receiving end into a data group and transmitting the data is applied, when it is desired to periodically insert consecutively long base data into mobile service data, It is possible to periodically insert a known length of known data into an area where there is no interference of data (that is, an area where main service data is not mixed). However, it is difficult to periodically insert the known data due to the interference of the main service data in the area where interference of the main service data exists, and it is also difficult to continuously insert the known data.

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

The M / H block B4 to M / H block B7 in the data group of FIG. 2 shows an example in which a long known data string is inserted before and after each M / H block as an area without interference of main service data. In the present invention, the A region (= B4 + B5 + B6 + B7) including the M / H block B4 to the M / H block B7 will be described. As described above, in the case of the A region having the known data sequence for each M / H block back and forth, the receiving system can perform equalization using the channel information obtained from the known data. Thus, the most robust equalization Performance can be obtained.

The M / H block B3 and the M / H block B8 in the data group of FIG. 2 are areas where the interference of the main service data is small, and an example in which a long known data row is inserted into only one of both M / H blocks is shown. That is, due to the interference of the main service data, the M / H block B3 inserts a long base data string only after the corresponding M / H block, and the M / H block B8 inserts a long base data string only in front of the corresponding M / H block . In the present invention, the B region (= B3 + B8) including the M / H block B3 and the M / H block B8 will be described. As described above, in the case of the B region having the known data sequence in either one of the M / H blocks, the receiving system can perform equalization using the channel information obtained from the known data, The equalization performance can be obtained.

In the M / H block B2 and the M / H block B9 in the data group of FIG. 2, the interference of the main service data is larger than the area B, and it is impossible to insert a long known data row back and forth in both M / H blocks. In the present invention, a C region (= B2 + B9) including the M / H block B2 and the M / H block B9 will be described.

In the M / H block B1 and the M / H block B10 in the data group of FIG. 2, the interference of the main service data is larger than the area C, and similarly, it is impossible to insert a long known data row back and forth in both M / H blocks. In the present invention, the D region (= B1 + B10) including the M / H block B1 and the M / H block B10 will be described. Since the C / D region is far away from the known data sequence, the reception performance may be poor if the channel changes rapidly.

Also, the data group includes a signaling information area to which signaling data (or signaling information) is allocated.

The present invention can use a part of the second segment from the first segment of the M / H block B4 in the data group as the signaling information area.

The present invention uses 276 (= 207 + 69) bytes of the M / H block B4 of each data group as a signaling information area. That is, the signaling information area is composed 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 173rd segment of the VSB field.

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

Since the TPC data mainly includes parameters used in a physical layer module and is transmitted without being interleaved, the TPC data can be accessed on a slot-by-slot basis.

The FIC data is provided to enable fast service acquisition in a receiving system and includes cross-layer information between a physical layer and an upper layer. The FIC data is interleaved and transmitted in units of subframes.

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

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

The RS frame is received in each M / H frame in a state of being switched to the time slicing mode.

The RS frame according to an embodiment of the present invention is composed of a plurality of M / H TPs (Transport Packets). Each M / H TP consists of 2 bytes of M / H header and N-2 bytes of 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 one embodiment, the IP datagram of the SMT or the service signaling channel for transmitting the SMT is included in a corresponding RS frame with a well-known IP destination address and a well-known destination UDP port number, do.

The RS frame may also include the IP datagram of the SGDD. The access information of the SGDD or the service guide announcement channel for transmitting the SGDD is signaled to the SMT. The access information of the service guide announcement channel includes service guide bootstrap information.

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 datagrams may be IP datagrams of mobile service data, or IP datagrams for SGDD.

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

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.

FIG. 4 shows an example in which one M / H frame is composed of 5 subframes, and one subframe is composed of 16 slots. In this case, one M / H frame includes 5 subframes and 80 slots.

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

One VSB frame is composed of two VSB fields (i.e., an odd field and an even field). Each VSB field is composed of one field sync segment and 312 data segments.

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

If the first 118 data packets in the slot correspond 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 is made up of 156 main service data packets.

On the other hand, the data in one RS frame may be all allocated to the A / B / C / D area in the data group or may be allocated to at least one area of the A / B / C / D area. In the present invention, data in one RS frame may be all allocated to the A / B / C / D region or allocated only to one of the A / B region and the C / D region. That is, in the latter case, the RS frame allocated to the A / B area in the data group is different from the RS frame allocated to the C / D area. According to an embodiment of the present invention, an RS frame allocated to an A / B area in a data group is referred to as a primary RS frame, and an RS frame allocated to a C / D area is referred to as a secondary RS frame frame. The primary RS frame and the secondary RS frame constitute one parade. That is, if data in one RS frame is all allocated in the A / B / C / D area in the data group, one parade transmits one RS frame. On the other hand, if data in one RS frame is allocated to the A / B area in the data group and data in the other RS frame is allocated to the C / D area in the corresponding data group, Lt; / RTI >

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 the 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 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 the RS frame mode. Referring to Table 1, if the RS frame mode value is 00, it indicates that one parade transmits one RS frame. If the RS frame mode value is 01, one parade is transmitted to two RS frames, that is, a primary RS Frame and the secondary RS frame. That is, when the RS frame mode value is 01, the data of the primary RS frame for region A / B for the A / B region is allocated and transmitted to the A / B region of the data group, And the data of the secondary RS frame (region C / D) for the region is assigned to the C / D region of the corresponding data group and is transmitted.

As in the case of the allocation of the data group, the parades are allocated as far as possible in the subframe as one embodiment. This makes it possible to strongly respond to burst errors that may occur in one subframe.

And, the allocation method of parades can be applied differently for each M / H frame, and the same applies to all M / H frames. The same applies to all subframes within one M / H frame, or may be applied to each subframe differently. The present invention can be changed for each M / H frame, and is applied to all subframes in one M / H frame. That is, the M / H frame structure can be changed in units of M / H frames, which enables flexible adjustment of the ensemble data rate.

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

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

As described above, the M / H frame for about 0.968 seconds is divided into five subframes, and data groups corresponding to a plurality of ensembles exist in each subframe. A data group corresponding to each ensemble exists Are interleaved in units of M / H frames to form an RS frame belonging to one ensemble. In Fig. 5, there are two ensembles (NoG = 4, NoG = 3). Also, a certain portion (e.g., 37 bytes / data group) of each data group is used to transmit FIC data to which encoding is applied separately from the RS frame data channel. The FIC area allocated to each data group constitutes one FIC segment, and these FIC segments are interleaved on a subframe basis. For example, RS encoding and serial concatenated convolutional code (SCCC) encoding are applied to the RS frame data, and RS encoding and parallel concatenated convolutional coding (PCCC) encoding are applied to the FIC data . On the other hand, RS encoding and parallel concatenated convolutional code (PCCC) encoding are applied to the TPC data as well as the FIC data. In this case, (187 + P, 187) -RS encoding is applied to the RS frame data, (51,37) -RS encoding is applied to the FIC data, and the TPC data is One embodiment is applied. Here, P is the number of parity bytes.

Hierarchical Signaling  rescue

FIG. 6 is a diagram illustrating a hierarchical signaling structure according to an embodiment of the present invention. The mobile broadcasting technology according to the present embodiment employs a signaling method using FIC and SMT as shown in FIG. This is referred to as a hierarchical signaling structure in the present invention.

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

As can be seen in Figure 6, the FIC chunk uses its fast nature to deliver the mapping relationship between the mobile service and the ensemble to the receiving system. That is, the FIC chunk provides signaling data to the receiving system to quickly find an ensemble for delivering a desired service in the receiving system and to quickly receive the RS frames of the ensemble.

FIC ( Fast Information Channel )

In addition, the receiving system according to the present invention allows the FIC (Fast Information Channel) to access the currently broadcast mobile service more quickly.

FIG. 7 shows the syntax structure of the FIC chunk, which serves to map the relationship between the mobile service and the ensemble through the FIC.

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

FIG. 8 shows an embodiment of the syntax structure of the 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 backwards compatible with the corresponding FIC chunk Signaling a minor protocol version change, an FIC chunk header extension, an ensemble loop header extension, and a mobile service loop extension, which may be caused by a minor protocol version change .

If a receiving system that can accommodate the minor protocol version change processes the corresponding extension field while a legacy receiving system that can not accommodate the minor protocol version change uses the corresponding length information It is an embodiment to skip the corresponding extension field. For example, if the receiving system can accommodate the minor protocol version change, the contents indicated by the extension field can be known, and the operation according to the contents indicated by the extension field can be performed.

In 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 an extension length of the FIC chunk header, or if the specific field in the FIC chunk payload is lost, or if the number of bits allocated to that field , And when the definition of the field is changed, it is an embodiment to update the major protocol version of the corresponding FIC chunk.

Further, the FIC chunk header indicates whether the data of the FIC chunk payload contains mapping information between the ensemble and the mobile service in the current M / H frame, or mapping information between the ensemble and the mobile service in the next M / H frame, The transport stream ID of the mobile broadcast in which the FIC chunk is currently transmitted, and the number of ensembles transmitted through the mobile broadcast.

In addition, the FIC chunk header according to the present invention can signal an identifier of an ensemble through which an Electronic Service Guide (ESG) entry point, that is, a Service Guide Delivery Descriptor (SGDD) is transmitted. In this case, the receiving system can know in which ensemble the corresponding SGDD is 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_id field, an SG_version field, a num_ensembles field and an ESG_Entrypoint_location field.

The FIC_major_protocol_version field allocates 2 bits in one embodiment and indicates a major protocol version of the corresponding FIC chunk syntax. The change of the major protocol version indicates a change in level that is not backward compatible. If this field value is updated, then the FIC chunk is not processed by a legacy receiving system capable of processing the previous major protocol version of the FIC chunk protocol (A two-bit unsigned integer field that represents the major version level of The FIC-Chunk protocol shall be attempted to avoid attempting to use the FIC-Chunk protocol. The FIC-Chunk protocol shall be a non-backward-compatible level of change. process the FIC Chunk).

The FIC_minor_protocol_version field allocates 3 bits in one embodiment and indicates a minor protocol version of the corresponding FIC chunk syntax. The change of the minor protocol version indicates a backward compatible level change. If this field is updated, then a legacy receiving system capable of handling the same major protocol version of the FIC chunk protocol can process a portion of the FIC chunk (A three-bit unsigned integer field that represents the minor The FIC-Chunk is the same as the FIC-Chunk, and the FIC-Chunk is the same as the FIC-Chunk. The FIC Chunk protocol may be a part of the FIC Chunk).

The FIC_Chunk_header_extension_length field allocates 3 bits in one 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 extension bytes are appended to the end of the corresponding FIC chunk header (this 3-bit unsigned integer field identifies the length of the FIC-Chunk header extension bytes caused by the minor protocol version of the FIC-Chunk, where the extension bytes are appended at the end of the FIC-Chunk header).

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

The M / H_service_loop_extension_length field is allocated 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 extension bytes are appended to the end of the corresponding mobile service loop (This 3-bit unsigned integer field identifies the length of the ensemble header extension caused by the minor protocol version of the M / H service loop, where the extension bytes are appended at the end of the M / H service loop).

For example, suppose that there are two ensembles in the FIC chunk (i.e., ensemble 0, ensemble 1), two mobile services through ensemble 0, and one mobile service via ensemble 1. At this time, if the FIC chunk header is extended by one byte while the minor protocol version is changed, the FIC_chunk_header_extension_length field indicates 001. In this case, a 1-byte extension field (FIC_Chunk_header_extension_bytes field) is added to the end of the FIC chunk header. In the existing receiving system, 1-byte extension field added to the end of the FIC chunk header is skipped without being processed.

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, an extension field (Ensemble_loop_header_extension_bytes field) of 2 bytes is added to each end of the ensemble 0 loop header and the ensemble 1 loop header. In the existing receiving system, 2 bytes of extension added to the end of the ensemble 0 loop header and the ensemble 1 loop header The field is skipped without processing.

Also, 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 extension field (M / H_service_loop_extension_bytes field) is added to each of two mobile service loops transmitted through ensemble 0 and one mobile service loop transmitted through ensemble 1. In the existing receiving system, the two mobile service loops transmitted through the ensemble 0 and the one-byte extended field added at the end of one mobile service loop transmitted through the ensemble 1 are skipped without being processed.

When the FIC_minor_protocol version field value is changed, the receiving system that can not accommodate the change of the minor protocol version of the existing receiving system, that is, the FIC chunk, processes the remaining fields except for the extension field, and sets FIC_chunk_header_extension_length, ensemble_loop_header_extension_length, and M / H_service_loop_extension_length fields The corresponding extension fields are skipped without being processed. If the receiving system can accommodate the change of the minor protocol version of the FIC chunk, it will process the corresponding extension field using each length field.

The current_next_indicator field allocates 1 bit in one embodiment, and when the field value is set to '1', it indicates that the FIC chunk is applied to the current M / H frame. If the field value is set to '0', it indicates that the corresponding FIC chunk is applied to the next M / H frame (A one-bit indicator, which when set to '1' The FIC-Chunk transmitted with the current_next_indicator bit is set to '1', and the FIC-Chunk will be used for the next M / H Frame. shall be currently applicable). That is, if the field value is set to '1', the FIC chunk indicates that the signaling data of the current M / H frame is transmitted. If the field value is set to 0, the FIC chunk indicates that the signaling data of the next M / H frame is transmitted. When reconfiguration in which mapping information between an ensemble and a mobile service in a current M / H frame is different from mapping information between an ensemble and a mobile service in a next M / H frame, reconfiguration occurs before the reconfiguration occurs, H frame is referred to as a current M / H frame, and an M / H frame in which reconfiguration occurs is referred to as a next M / H frame.

The transport_stream_id field allocates 16 bits in one embodiment and indicates a transport stream ID of a mobile broadcast in which the current FIC chunk is transmitted. This field value is identical to the transport_stream_id field value of the program map table (PAT). (This 16-bit unsigned integer number field serves as a label to identify this M / H Broadcast. the transport_stream_id field in the PAT in the MPEG-2 transport stream of the main ATSC broadcast).

The SG_version field allocates 5 bits in one embodiment and displays 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 the num_ensembles field, an 8-bit field is allocated, and an 8-bit unsigned integer field indicates the number of ensembles to be transmitted on the corresponding physical transport channel. .

The ESG_EntryPoint_Location field assigns 8 bits in one embodiment and indicates an ensemble ID of an ensemble to which an entry point of an ESG, i.e., an SGDD, is transmitted. Therefore, in the receiving system, it becomes possible to know in which ensemble the corresponding 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 the ensemble and information on the mobile service transmitted through each ensemble for each ensemble corresponding to the num_ensembles field value in the FIC chunk header of FIG. 8 have. In addition, the FIC chunk payload includes information indicating whether an entry point of the service guide, that is, SGDD, exists in the ensemble for each ensemble. At this time, the receiving system can know whether or not the service signaling channel includes the table including the service guide bootstrap information by using the instruction information. The table may be SMT or GAT.

The FIC chunk payload consists of an ensemble loop and a mobile service loop under the ensemble loop. Through the FIC chunk payload, the receiving system can recognize which ensemble the desired mobile service is transmitted (which is composed of 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 by 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 repeated by a num_MH_services field value.

The ensemble_id field allocates 8 bits in one embodiment and indicates a unique identifier of the ensemble. For example, values of 0x00 to 0x7F may be assigned to the field values. This field binds mobile services and ensembles. The value of the field may be derived from the parade_id of the TPC data. For example, when the ensemble is transmitted through the primary RS frame, the MSB is set to '0', and the remaining 7 bits are used as the parade_id value of the corresponding parade. On the other hand, when the 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 range 0x00 to 0x7F 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 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 performed over the Primary RS Frames and using '1' for the most significant bit when the M / H Ensemble is performed 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).

The SG_entry_point_indicator field allocates 1 bit in one embodiment and indicates whether an entry point of the service guide, i.e., SGDD, exists in the ensemble. For example, if the value of the SG_entry_point_indicator field is 1, it indicates that SGDD is included in the ensemble, and if it is 0, it indicates that SGDD is not included. If the value of the SG_entry_point_indicator field is 1, access information of a service guide announcement channel, that is, service guide bootstrap information, is signaled to a service signaling channel included in the ensemble.

Accordingly, the receiving system can identify whether the SGDD is included in the ensemble according to the value of the SG_entry_point_indicator field. Also, the receiving system can identify whether the access guide of the service guide announcement channel, that is, the service guide bootstrap information, is signaled to the service signaling channel included in the ensemble according to the value of the SG_entry_point_indicator field. That is, the receiving system can determine whether or not the service signaling channel includes a table including service guide bootstrap information according to the value of the SG_entry_point_indicator field. The table may be SMT or GAT.

At this time, in the present invention, an ESG_EntryPoint_Location field is included in the FIC chunk header and an SG_entry_point_indicator field is included in the FIC chunk payload. At this time, the receiving system may refer to both field values to determine which ensemble includes the SGDD, or may refer to only one of the two fields to determine which ensemble includes the SGDD. As another embodiment, the present invention may include only one of two fields. For example, the FIC chunk header includes the ESG_EntryPoint_Location field, the FIC chunk payload does not include the SG_entry_point_indicator field, and vice versa.

The SMT_version field allocates 5 bits in one embodiment and indicates version information of SMT data of the ensemble.

The num_M / H_services field allocates 8 bits in one embodiment and indicates the number of mobile services transmitted in the ensemble. (An 8-bit unsigned integer field represents the number of M / H services carried through M / H Ensemble).

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

The M / H_service_id field of the mobile service loop allocates 16 bits in one embodiment and indicates a unique identifier of the corresponding mobile service. The field value has a unique value in the mobile broadcast (A 16-bit unsigned integer number that identifies the M / H Service.) This number shall be unique within the M / H Broadcast. The M / H_service_id value shall be the same as that of the FIC, which shall be the same as the M / , 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 will represent the overall combined service, thereby maintaining the uniqueness of the M / H_service_id.

The MH_service_type field allocates 5 bits in one embodiment and indicates a type of the corresponding mobile service.

The multi_ensemble_service field allocates 2 bits in one embodiment and indicates whether the corresponding mobile service is transmitted through one or more ensembles. Also, this field value indicates whether the mobile service is valid only for the mobile service portion transmitted through the ensemble. (A two-bit enumerated field that indicates whether this M / H Service is carried across more than one M / H Ensemble. Also, this field identifies whether the M / H Service can be rendered meaningfully with only a 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 the status of the 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 will identify the status of this M / H Service. The most significant bit is whether this M / H Service is active (when set to 1) or inactive (when set to 0) not (when set to 0).

The SP_indicator field is a 1 bit allocated to the mobile service, and indicates whether the mobile service is protected by a service (A 1-bit field indicates that 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).

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

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

At this time, the transmission system (not shown) according to the present invention divides the FIC chunk into a plurality of FIC segments and transmits them to the reception system on an FIC segment basis. 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 FIC chunk header and FIC chunk payload is segmented by 35 bytes. Then, a 2-byte FIC segment header is added to each of the segmented 35 bytes to form an 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 physical transmission channel and the number of mobile services included in each ensemble.

And the FIC chunk payload may include stuffing data. In this case, the stuffing data is used for the 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 the stuffing data, waste of the FIC segment can be reduced.

The number of stuffing data bytes to be inserted into the FIC chunk can be obtained by applying the following equation (1).

Number of stuffing data bytes = 35 - j

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

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

In the present invention, FIC segments divided from one FIC chunk may be transmitted through one subframe or a plurality of subframes. If the amount of data to be transmitted through the FIC chunk is larger than the amount of FIC segments transmitted through one subframe (in this case, a plurality of services with a very low bit rate And the like), it is possible to transmit all the necessary signaling data through the FIC chunk.

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

Also, the present invention can add a null FIC segment. The null FIC segment is used to process the remaining FIC segments when stuffing is required in the corresponding M / H frame despite repeated transmission of FIC chunks. For example, suppose TNoG is 3 and the FIC chunk is divided into two FIC segments. At this time, when the FIC chunk is repeatedly transmitted through five subframes in one M / H frame, two FIC segments (i.e., the last subframe in time order) . 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 boundaries of the FIC chunk and the boundary of the M / H frame. At this time, since the null FIC segment is not an FIC segment segmented from the FIC chunk, the null FIC segment is not assigned an FIC segment number.

In the present invention, when one FIC chunk is divided into a plurality of FIC segments and included in each data group of at least one subframe in the M / H frame, the FIC chunk is allocated in the reverse order from the last subframe on the M / do. And when the null FIC segment is present, the null FIC segment is placed in the subframe on the M / H frame so that the null FIC segment is transmitted the latest.

In order to discard the null FIC segment without processing in the receiving system, identification information that can distinguish the null FIC segment is required.

The present invention uses the FIC_type field in the header of the null FIC segment as identification information capable of distinguishing the null FIC segment. The present invention sets the FIC_type field value in the header of the null FIC segment to '11' to distinguish the null FIC segment. That is, if the FIC_type field value of the null FIC segment is set to '11' and transmitted to the receiving system, the payload of the FIC segment whose FIC_type field value is set to '11' in the receiving system can be discarded without processing . The '11' is an embodiment for facilitating the understanding of the present invention, and any value that can distinguish the null FIC segment can be used if an agreement is made between the transmitting and receiving sides in advance. It will not be limited. Further, the identification information for distinguishing the null FIC segment may be displayed using another field in the FIC segment header.

FIG. 10 shows 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. The description of each field is as follows.

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

The error_indicator field (1 bit) indicates whether an error has occurred in the corresponding FIC segment during transmission. The error_indicator field is set to '1' when an error occurs and to '0' when there is no error. That is, when there is an error that can not be recovered in the process of configuring 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. For example, if the corresponding FIC segment is the first FIC segment of the FIC chunk, the FIC_seg_number field value is set to 0x0, and if the FIC segment is 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 additional segment in the FIC Chunk). If the FIC chunk is divided into four FIC segments, the FIC_seg_number field value 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 of the complete FIC chunk (that is, the FIC segment having the highest FIC_segment_num field value) (A 4-bit unsigned integer number field which gives the number of the last FIC -Segment (i.e., the FIC Segment with the highest FIC_segment_num) of the complete FIC Chunk).

In this case, since FIC segment numbers are sequentially assigned to FIC segments in one subframe, the last FIC segment number and TNOG always match in this case. However, in the FIC segment number allocation scheme according to the present invention, the last FIC segment number and the TNOG do not always coincide with each other. That is, they may or may not match. The TNoG is the total number of data groups allocated to one subframe. For example, if TNoG is 6 and the FIC chunk is divided into 8 FIC segments, then 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 separated using the FIC_segment_num field value in the FIC segment header. That is, since the FIC segment number is not allocated to the null FIC segment, the transmission system allocates null data to the FIC_segment_num field value of the null FIC segment and transmits the null data. In the receiving system, the FIC segment to which the null data is allocated in the FIC_segment_num field value, It may be recognized as an FIC segment. It is also possible to allocate previously promised data in the transmitting / receiving system instead of the null data to the FIC_segment_num field value.

As described above, the FIC chunk may be divided into a plurality of FIC segments and transmitted through one subframe or 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. Here, the number assigned to each FIC segment is not a number in the corresponding subframe, but a number in the corresponding FIC chunk (i.e., the FIC_seg_number field value). In order to align the boundary of the M / H frame and the boundary of the FIC chunk, a null FIC segment may be transmitted. In this case, no segment number is allocated to the null FIC segment.

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. However, the FIC segments may be interleaved and transmitted in units of subframes As an embodiment.

Meanwhile, FIG. 11 shows an embodiment of a bitstream syntax structure of an SMT section that provides connection information of an SGDD included in an RS frame. Here, the SMT section is prepared in the form of an MPEG-2 private section for the sake of understanding, but the format of the data of the SMT section may be any form.

The SMT may provide access information of mobile services in the ensemble including the SMT. In addition, the SMT can provide information necessary for rendering a mobile service. The SMT may include one or more descriptors, and other additional information may be described through the descriptor.

According to an embodiment of the present invention, when an SGDD is received in an ensemble including the SMT, connection information of the SGDD is provided using the descriptor of the SMT. The SMT descriptor is an ensemble level descriptor.

At this time, the service signaling channel for transmitting the SMT may further include a signaling table (e.g., GAT) other than the SMT. At this time, the IP datagrams of the service signaling channel have the same well-known IP address and a well-known UDP port number. Therefore, the classification of the SMT included in the service signaling data is made by the table identifier. That is, the table identifier may be a table_id existing in the corresponding table or the header of the corresponding table section, and may be distinguished by reference to a table_id_extension, if necessary.

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

The table_id field (8 bits) is a field for identifying the type of the table, so that the table is SMT.

The section_syntax_indicator field (1 bit) is an indicator for defining the SMT section format. The section format may be MPEG short-form syntax ('0') or the like (section_syntax_indicator: This 1-bit field shall be set to '0' to always indicate that this table is derived from the "short" form of the MPEG-2 private section table.

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

The section_length field (12 bits) indicates the length of the section of the remaining SMT after the field (section_length: A 12-bit field.

The table_id_extension field (16 bits) is table-dependent and is a logical part of the table_id field that provides a range of remaining fields (table_id_extension: This is a 16-bit field and is table-dependent. 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.

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

The ensemble_id field (8 bits) is an ID value associated with the ensemble, and values of 0x00 to 0x3F may be assigned. The value of this field is preferably derived from the parade_id of the 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. On the other hand, if the ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to '1', and the remaining seven bits are used as the parade_id value of the parade.

The version_number field (5 bits) indicates the version number of the SMT.

The current_next_indicator field (1 bit) indicates whether or not the SMT section is currently applicable.

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

The num_MH_services field (8 bits) indicates the number of mobile services in the SMT section. (num_MH_services: This 8 bit field specifies the number of services in this SMT section.).

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

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

The Multi_ensemble_service field (2 bits) identifies whether the mobile service is transmitted via one or more ensembles.

The MH_service_status field (2 bits) identifies the state 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').

The SP_indicator field (1 bit) indicates whether or not the corresponding mobile service is service protected. If the value of the SP_indicator field is equal to 1, the service protection is applied to at least one of the components required to provide a meaningful presentation of the mobile service (see (1-bit field indicates that, 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 indicates the short name of the corresponding mobile service.

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

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

When the IP_version_flag field is set to '1', the source_IP_address field, the MH_service_destination_IP_address field, and the component_destination_IP_address field are IPv6 addresses, and when set to '0', the source_IP_address field, the MH_service_destination_IP_address field, and the component_destination_IP_address field are IPv4 addresses (I = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 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, a flag indicating that the source IP address value for the service exists to indicate the source specific multicast (source_IP_address_flag: A 1-bit Boolean flag that indicates indicate, 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, it indicates that the corresponding IP stream component is transmitted via 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 destination_IP_address to access the corresponding IP stream component and ignores the MH_service_destination_IP_address field in the num_MH_services loop.

The source_IP_address field (32 or 128 bits) needs to be interpreted when the source_IP_address_flag is set to '1', but it need not be interpreted if the source_IP_address_flag is not set to '0'. When the source_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit IPv4 address representing the source of the mobile service. If the IP_version_flag field is set to '1', this field indicates a 32-bit IPv6 address indicating the source of the mobile service.

The MH_service_destination_IP_address field (32 or 128 bits) needs to be interpreted when the MH_service_destination_IP_address_flag is set to '1', but it need not be interpreted if the MH_service_destination_IP_address_flag is set to '0'. When the MH_service_destination_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit Destination IPv4 address for the corresponding mobile service. When the 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 can not be interpreted, the component_destination_IP_address field in the num_components loop must be interpreted and the receiving system must use component_destination_IP_address to access the IP stream component.

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

Thereafter, a 'for' loop (or a component loop) is performed by the number of components corresponding to the num_components field value to provide connection information for a plurality of components. That is, it provides connection information of each component included in the mobile service. At this time, the following field information can be provided for each component.

The essential_component_indicator field (1 bit), if set to '1', indicates that the component is a required component for mobile services. Otherwise, the component indicates that it is an optional component (essential_component_indicator: A one-bit indicator which indicates when this component is an essential component for the service. Otherwise, this field indicates that this component is an optional component).

The component_destination_IP_address_flag field (1 bit) is a flag indicating that the component_destination_IP_address field exists for the corresponding component if set to '1' (component_destination_IP_address_flag: A 1-bit Boolean flag that indicates that when set to '1', that the component_destination_IP_address is present for this component).

The port_num_count field (6 bits) indicates the number of the UDP port associated with the corresponding UDP / IP stream component. Destination UDP port number value increases by 1, starting from the destination_UDP_port_num field value.

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

The component_destination_IP_address field (32 or 128 bits) indicates that the IP_version_flag field is set to '0', 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 component_destination_IP_address_flag is set to '1' and shall not be When this field is not present, the destination address of the IP datagrams carrying this component of the M / H Service shall match the address in this field. The IPv6 address is the address of the M / H_service_destination_IP_address field, which is the address of the IPv6 address. currently defined).

The num_component_level_descriptors field (4 bits) indicates the number of descriptors providing additional information at the component level.

Component_level_descriptors () are included in the component loop by the number corresponding to the num_component_level_descriptors field value, thereby providing additional information on the component.

The num_MH_service_level_descriptors field (4 bits) indicates the number of descriptors providing additional information of the mobile service level.

Service_level_descriptors () are included in the mobile service loop by the number corresponding to the num_MH_service_level_descriptors field value, thereby providing additional information for the mobile service.

The num_ensemble_level_descriptors field (4 bits) is the number of descriptors providing additional information at the ensemble level.

The ensemble_level_descriptor () is included in the ensemble loop by the number corresponding to the num_ensemble_level_descriptors field value, thereby providing additional information on the ensemble.

On the other hand, if the FIC indicates that an ensemble corresponding to the ensemble identifier of the SMT includes an ESG entry point, i.e., SGDD, the SGT_Access_Descriptor is included in the ensemble level descriptor of the SMT. For example, suppose the FIC indicates that an SGDD is included in an ensemble having an ensemble identifier of A using at least one of the ESG_EntryPoint_Location field and the SG_entry_point_indicator field. At this time, if the value of the ensemble_id field of the SMT is A, the SG connection descriptor SG_Access_Descriptor is included in the SMT and received.

The SG connection descriptor SG_Access_Descriptor provides connection 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 transmission session identifier of a FLUTE session that transmits the service guide announcement channel.

12 shows an embodiment of the bit stream syntax structure of the SG connection descriptor SG_Access_Descriptor () according to the present invention.

A description of each field of the SG connection descriptor SG_Access_Descriptor () is as follows.

In FIG. 12, the descriptor_tag field (8 bits) is a descriptor identifier, and an identifier for identifying the SG connection descriptor SG_Access_Descriptor () is displayed.

The descriptor_length field (8 bits) indicates the remaining length of the descriptor in bytes after the descriptor_length field to the end of the 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'.

The address_count field (7 bits) is a counter that indicates how many IP addresses from the destination_IP_address field described next are transmitted for transport of the corresponding mobile service data.

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

The destination_UDP_port_num field (16 bits) represents the destination UDP port number of the FLUTE session that is transmitting the 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 the transport session identifier for the FLUTE session in which the service guide announcement channel is transmitted.

That is, it obtains an IP datagram of a service guide announcement channel that transmits SGDD from the ensemble using the destination_IP_address field and the destination_UDP_port_num field, removes the ALC / LCT header from the obtained IP datagram, and transmits an announcement_channel_TSI field And accesses the corresponding FLUTE session to receive the SGDD. It is possible to acquire FLUTE session information of SGDUs from the received SGDD and access SGDUs by accessing all FLUTE sessions according to the FLUTE session information. The SGDU includes one or more fragments.

At this time, 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.

On the other hand, the connection information of the SGDD as shown in FIG. 12 may be provided in a table format. In this case, a table including connection information of the SGDD is transmitted through a service signaling channel. In addition, the division of the table including the connection information of the SGDD is made by a table identifier. The table identifier may be a table_id existing in the corresponding table or a header of the corresponding table section, and may be distinguished by referring to a table_id_extension if necessary.

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

In FIG. 13, the service guide includes an administrative group for providing superior configuration information of the entire service guide, a provisioning group for providing service subscription and purchase information, a service guide such as a service, A core group for providing core information, and an access group for providing access information for accessing a service or contents.

In FIG. 13, the Administrative Group is a group providing basic information for receiving a service guide in the receiving system, and includes a service guide delivery descriptor (SGDD). The SGDD informs access information of a FLUTE session (FLUTE Session) where a Service Guide Delivery Unit (SGDU) including at least one fragment, which is a minimum unit constituting a service guide, is located, Grouping " information and a " Notification " message.

The supply group is a group for providing charge information for service reception, and includes a Purchase Item fragment, a Purchase data fragment, and a Purchase channel fragment. The core group is a group providing information on the service itself, and includes a service fragment, a schedule fragment, and a content fragment. The access group includes an access fragment and a session description fragment. The service guide may include a preview data fragment and an interactive data fragment in addition to the group. In Fig. 13, arrows indicate reference relationships. According to this example, a perceived item fragment, a content fragment, a schedule fragment, and an access fragment can refer to a service fragment. Schedule fragments can reference service fragments and content fragments. The numbers illustrated in the respective arrows in Fig. 13 indicate the possible number of each subunit information. And the number represents the possible number of each fragment.

The main fragments of the exemplified fragments will be described as follows.

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

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

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

The perceived item fragment includes item information related to purchase.

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

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

For 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 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 by necessity in providing service guides.

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

In FIG. 14, when a physical transmission channel including a mobile service selected by the user is tuned, a mobile broadcasting signal for transmitting a mobile service selected by the user is confirmed from the tuned physical transmission channel (S101). Then, the mobile broadcast signal is demodulated (S102). Then, FIC segments are acquired from the demodulated mobile broadcast signal to restore FIC chunks (S103, S104).

That is, a subframe in which the demodulated mobile broadcast signal is transmitted and a slot allocated in the subframe are found out. And then collects data groups received through the slots of the found subframe. Then, PCCC decoding is performed on the FIC data received in each signaling information area of the collected data groups, deinterleaving is performed on a subframe-by-frame basis, and RS decoding is performed in the reverse of the transmitting side. Then, FIC segments are restored for each subframe. This process is performed on one or more subframes and the FIC chunk is restored from the payload of the FIC segments according to the FIC_type field, the FIC_segment_num field, and the FIC_last_segment_num field in each header of the restored FIC segments from one or more subframes.

The restored FIC chunk includes an FIC chunk header as shown in FIG. 8 and an FIC chunk payload as shown in FIG. 9. Referring to FIG.

The transport stream ID of the mobile broadcast to 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 step S107, it is checked whether the SGDD is included in the ensemble from the restored FIC chunk.

In the present invention, 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 can be checked to determine which SGDD is included in an ensemble. Also, by referring to only one of two fields, it is possible to check which ensemble includes an SGDD have.

If the ensemble including SGDD is identified in step 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). One embodiment of the present invention receives RS frames belonging to an ensemble in which the SG_entry_point_indicator field value in the FIC chunk payload is set to 1.

The SMT is acquired from the received RS frame (S109). The SMT is received in a service signaling channel having a well-known IP address and a well-known UDP port number. That is, the SMT is obtained using the table identifier from the IP datagram of the service signaling channel having the well-known IP address and the well-known UDP port number.

The SG access descriptor among the descriptors included in the obtained SMT is processed to obtain the entry point of the ESG, that is, the IP connection information of the SGDD (S110). 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 for transmitting the SGDD from the RS frame using the destination IP address and the destination UDP port number is obtained (S111).

After removing the ALC / LCT header from the obtained IP datagram, the SGDD is received by accessing the corresponding FLUTE session using the announcement_channel_TSI field (S112). Acquires the connection information of the SGDUs from the received SGDD, and connects to each FLUSE session according to the acquired connection information to collect SGDUs (S113). The SGDU includes one or more fragments. And extracts and stores SG data from the fragments included in the collected SGDUs. Then, when the user's request is made, the receiving system displays the SG information according to the stored SG data.

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

Receiving system

15 is a block diagram illustrating a configuration of a reception system according to an embodiment of the present invention. In FIG. 15, a solid line arrow indicates a data path, and a dotted line 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, a known sequence detector A mobile handheld block decoder 160, a primary RS frame decoder 170, a secondary RS frame decoder 180, and a signaling decoder 190, . ≪ / RTI >

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 receiving apparatus, and mobile service data, which is a broadcast signal for a mobile broadcast receiving apparatus, by tuning the receiving system at a specific physical channel frequency . At this time, the frequency of the tuned specific channel is down-converted to an intermediate frequency (IF) signal and output to the demodulator 130 and the known data detector 140. The passband digital IF signal output from the tuner 120 may include only main service data, only mobile service data, or both main service data and mobile service data. The mobile service data may be data of an RS frame or data for a mobile service in a data group.

The demodulator 130 performs automatic gain control, carrier recovery, and timing recovery on a digital IF signal of a passband inputted from the tuner 120, converts the signal into a baseband signal, and then outputs the baseband signal to an equalizer 140 and a known data detector 150). The demodulator 130 can improve demodulation performance by using a known data symbol sequence received from the known data detector 150 during timing recovery or carrier recovery.

The equalizer 140 compensates for the distortion on the channel included in the demodulated signal from the demodulator 130 and outputs the compensated signal to the block decoder 160. The equalizer 140 can improve equalization performance by using a known data symbol sequence input from the known data detector 150. [ Also, the equalizer 140 may feedback the decoding result of the block decoder 150 to improve the equalization performance.

The known data detector 150 detects the known data position inserted from the transmitting side from the input / output data of the demodulator 130, that is, the data before the demodulation or the demodulated data, To a demodulator 130 and an equalizer 140. The demodulator 130 and the equalizer 140 generate a sequence of known data sequences. Also, the known data detector 150 outputs to the block decoder 160 information for enabling the block decoder 160 to distinguish the mobile service data that has been further encoded on the transmitting side and the main service data that has not undergone the additional coding .

The block decoder 160 decodes the data, which is input after the channel equalization in the equalizer 140, on both the block encode and the trellis encoding of the serial concatenated convolutional code (SCCC) Internal data), performs trellis decoding and block decoding inversely to the transmitting side, and performs only trellis decoding if the data is only Trellis-encoded (i.e., main service data) without performing block encoding.

The signaling decoder 190 decodes the signaling data input after being equalized by the equalizer 140. It is assumed that the 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. Examples of such signaling data include transmission parameter channel (TPC) data and fast information channel (FIC) data. For example, the signaling decoder 190 performs the recursive turbo decoding of the data of the signaling information area of the input data in parallel concatenated convolutional code (PCCC), then extracts the FIC data and the TPC Separate the data. The signaling decoder 190 RS-decodes the separated TPC data in the reverse direction of the transmitting side and outputs the decoded TPC data to the TPC handler 214. Then, the signaling decoder 190 deinterleaves the separated FIC data in units of subframes, performs RS decoding inverse to the transmitting side, and outputs it to the FIC handler 215. The transmission unit of the 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, the primary RS frame and the secondary RS frame are distinguished from each other according to the importance of data.

The primary RS frame decoder 170 receives the output of the block decoder 160 as an input. In this case, the primary RS frame decoder 170 receives the data of the primary RS frame encoded by the RS (Reed Solomon) encoding and / or the CRC (Cyclic Redundancy Check) from the block decoder 160 . 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 the output of the block decoder 160 as an input. At this time, the secondary RS frame decoder 180 receives data of RS secondary RS frame and / or CRC encoded secondary RS frame. The secondary RS frame decoder 180 performs an inverse process of the 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 on a secondary RS frame basis.

The management processor 200 according to an exemplary embodiment of the present invention includes an M / H physical adaptation processor 210, an IP network stack 220, a streaming handler 210, handler 230, an SI handler 240, a file handler 250, a MIME type handler 260, an ESG handler An ESG decoder 280, and a storage unit 290. The ESG decoder 280 may be an ESG decoder.

The M / H physical adaptation processor 210 includes a primary RS frame handler 211, a secondary RS frame handler 212, an M / H-TP handler M / A TP handler 213, a TPC handler 214, a FIC handler 215, and a physical adaptation control signal handler 216.

The TPC handler 214 extracts a sub-frame number, a slot number, a parade ID, a stating group number, and the like from the TPC data output from the signaling decoder 190, (RSG), a group number (NOG), a parade repetition cycle (PRC), an RS frame mode, an RS code mode, an SCCC block mode SCCC outer code mode, FIC version, total number of groups (TNoG), parade continuity counter (PCC), TPC protocol version TPC protocol version) and outputs it 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 the parade to which the data group belongs. At this time, parade id communication between the physical layer and the upper layer is performed by an ensemble identifier formed by adding one bit to the left of the parade id. An ensemble identifier for identifying a primary ensemble transmitted through the parade may be formed by marking 0 in the added MSB and an ensemble identifier for identifying a secondary ensemble may be formed by marking 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 the repetition period of the parade transmitted in units of M / H frames. The RS frame mode indicates whether one RS frame or two RS frames are transmitted in one parade. The RS code mode indicates the RS code mode of the RS frame. The SCCC Block mode indicates how the M / H blocks in the data group are allocated to the SCCC block. The SCCC outer code mode indicates the SCCC outer code mode of the data group. The FIC version indicates the version of the FIC data. The Parade_continuity_counter field is incremented from 0 to 15, and increases by 1 for each (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 total number of data groups allocated in one subframe. The TPC protocol version indicates a version of the corresponding TPC syntax structure. The information included in the TPC data is only an example for facilitating understanding of the present invention. Addition and deletion of information included in the TPC data can be easily changed by those skilled in the art. I will not.

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

The primary RS frame handler 211 divides the primary RS frame received from the primary RS frame decoder 170 of the baseband processor 100 into units of rows to constitute an M / H-TP, / H-TP handler 213 as shown in Fig.

The secondary RS frame handler 212 divides the secondary RS frame received from the secondary RS frame decoder 180 of the baseband processor 100 into units of rows to form an M / H-TP, And outputs it to the 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 and determines data included in the corresponding M / H-TP . If the determined corresponding data is SI data, the data is output to the physical adaptive control signal handler 216 (i.e., the SI data is not encapsulated in the IP datagram). In case of the IP datagram, the IP network stack 220 .

The IP network stack 220 processes broadcast data transmitted in an IP datagram format. That is, the IP network stack 220 includes a UDP (User Datagram Protocol), an RTP (Real-time Transport Protocol), an RTCP (Real-time Transport Control Protocol), an Asynchronous Layered Coding / Layered Coding Transport (File Delivery over Unidirectional Transport) or the like. If the processed data is streaming data, the streaming data is output to the streaming handler 230. If the processed data is data of a file format, the data is output to the file handler 250, . In one 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 the SI data in the form of an IP datagram input to the IP network stack 220.

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

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

The file handler 250 receives data in the form of an object according to the ALC / LCT and the FLUTE structure from the IP network stack 220. The file handler 250 collects the received data to form a file. When the file includes an electronic service guide (ESG), the file handler 250 outputs the file to the ESG handler 270. Data for other file- And outputs it 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 processed ESG data in the storage unit 290 or outputs the ESG data to the ESG decoder 280 so that the ESG data is used in the ESG decoder 280 .

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

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 and outputs the ESG data to the presentation controller 330 Output.

The streaming handler 230 receives data from the IP network stack 220 according to the RTP and RTCP structures. The streaming handler 230 extracts an audio / video stream from the received data and outputs the extracted audio / video stream 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 decoded audio and video signals from the A / V decoder 310 and provides the decoded audio and video signals to a user through a speaker and / or a screen.

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

The channel service manager 340 interfaces with the user in order to allow the user to use the channel service based on the channel, such as channel map management and channel service access.

The Application Manager (350) is responsible for interfacing with the user to use application services other than the ESG display or other channel services.

That is, the FIC handler 215 restores the FIC chunk from the FIC segments deinterleaved and RS-decoded in the signaling decoder 190, analyzes the recovered FIC chunk and extracts signaling information for service acquisition And outputs it to the physical adaptive control signal handler 216.

The FIC handler 215 extracts FIC chunks from the payload of the FIC segments according to the FIC_type field, the FIC_segment_num field, and the FIC_last_segment_num field in each header of the FIC segments reconstructed from the one or more subframes decoded by the signaling decoder 190, . The information included in the restored FIC chunk is used to check which ensemble is included in the ensemble, and the result is output to the physical adaptive control signal handler 216. In the present invention, 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 can be checked to determine which SGDD is included in an ensemble. Also, by referring to only one of two fields, it is possible to determine which SGDD is included in an ensemble have.

The physical adaptive control signal handler 216 uses the TPC data output from the TPC handler 214, the FIC data output from the FIC handler 215, and the SMT data output from the SI handler 240, And controls the baseband processor 100 to receive the RS frames belonging to the ensemble for each M / H frame by switching to a time slicing mode for receiving the identified ensemble. Then, the access control unit acquires access information of a service guide announcement channel for transmitting the SGDD or SGDD from the SMT included in the received RS frame, and controls to receive SGDD according to the acquired access information. Also, SGDUs are acquired from the received SGDDs, SGDUs are connected to each FLUSE session according to the acquired connection information, SGDUs are collected, SG data are extracted from the fragments included in the collected SGDUs, . Then, the presentation processor 300 displays the SG information on the screen according to the SG data stored in the storage unit 290.

Up to now, the access information of the service guide announcement channel including the service guide bootstrap information may be signaled through an ensemble level descriptor (e.g., SG connection descriptor) of the SMT included in the service signaling channel. Respectively.

In another embodiment of the present invention, access information of a service guide announcement channel including the service guide bootstrap information may be signaled through a guide access table (GAT). The GAT is included in the service signaling channel. At this time, since the IP datagrams of the service signaling channel have the same well-known IP address and a well-known UDP port number, the GAT included in the service signaling data is classified according to the table identifier. That is, the table identifier may be a table_id existing in the corresponding table or the header of the corresponding table section, and may be distinguished by reference to a table_id_extension, if necessary. The GAT includes an announcement_channel_TSI field included in the SG connection descriptor of FIG. 12 as an embodiment.

If the access information of the service guide announcement channel including the service guide bootstrap information is signaled using the GAT, the SG_entry_point_indicator field of FIG. 9 indicates whether the GAT is transmitted to the service signaling channel included in the ensemble . For example, if the value of the SG_entry_point_indicator field is 1, it indicates that the GAT is transmitted to the service signaling channel included in the ensemble.

Also, when the GAT is included in the service signaling channel, the receiving system of Fig. 15 and Fig. 15 can be used. In this case, it is different from obtaining the access information of the service guide announcement channel from GAT, not SMT.

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

In FIG. 16, the table_id field is an identifier of the table, and an identifier for identifying the GAT can be set. The GAT in FIG. 16 can be used as one of the table identifiers for allocating the 8-bit ensemble_id field and the 8-bit GAT_protocol version field at the table_id_extension field position and distinguishing the GAT when the GAT is received on the service signaling channel.

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

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

The section_length field indicates 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 the ensemble, and values of 0x00 to 0x3F may be assigned. The value of this field is preferably derived from the parade_id of the 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. On the other hand, if the ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to '1', and the remaining seven bits are used as the parade_id value of the parade.

The version_number field indicates the version number of the GAT.

The section_number field indicates the section number of the current GAT section.

The last_section_number field indicates 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 continued.

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

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

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

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

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, .

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

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

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

4 is a diagram showing an example of an M / H frame structure for transmission and reception of mobile service data according to the present invention;

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

Figure 6 illustrates a hierarchical signaling structure in accordance with an embodiment of the present invention.

7 is a diagram showing an embodiment of the syntax structure of the FIC chunk according to the present invention.

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

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

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

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

12 is a diagram showing an embodiment of a syntax structure of an SG connection descriptor included in the SMT;

13 is a view showing the SG structure and the relationship between the FIC chunk and the SMT;

14 is a flowchart illustrating an embodiment of a method of 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 is a diagram showing an embodiment of a syntax structure of a section of a guide access table (GAT) according to the present invention;

Claims (15)

Receiving data packets including broadcast service data for a broadcast service and service information for the broadcast service; Encoding the data of the received data packets; First encoding a transmission parameter; Second encoding the first encoded transmission parameter; And And transmitting a broadcast signal including the encoded data and the second encoded transmission parameter, Here, the service information includes information for acquiring a service guide related to the broadcast service and identification information for identifying the broadcast service, Wherein the transmission parameter includes encoding information of the data. The method according to claim 1, Wherein the information for accessing the service information includes at least one of a predetermined IP address and a predetermined UDP port number. The method according to claim 1,  Wherein the service information further includes information indicating whether the broadcast service is hidden. The method according to claim 1, Wherein the information for obtaining the service guide includes service guide bootstrap information. An encoding unit for receiving data packets including broadcast service data for a broadcast service and service information for the broadcast service, and encoding data of received data packets; A first encoder for first encoding a transmission parameter; A second encoder for second encoding the first encoded transmission parameter; And And a transmitter for transmitting a broadcast signal including the encoded data and the second encoded transmission parameter, Here, the service information includes information for acquiring a service guide related to the broadcast service and identification information for identifying the broadcast service, Wherein the transmission parameter comprises encoding information of the data. 6. The method of claim 5, Wherein the information for accessing the service information includes at least one of a predetermined IP address and a predetermined UDP port number. 6. The method of claim 5, Wherein the service information further includes information indicating whether the broadcast service is hidden. 6. The method of claim 5, Wherein the information for obtaining the service guide includes service guide bootstrap information. delete delete delete delete delete delete delete

Images