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

Abstract

A receiving system receiving data for mobile broadcasting and a data processing method for the same are disclosed. The receiving system includes a receiving unit, a first handler, and a second handler. The receiving unit receives a broadcasting signal through a mobile broadcasting network. The broadcasting signal includes mobile service data and a first signaling table, and the first signaling table includes transmission information and bootstrapping information of a service guide for the mobile service data. The first handler acquires the service guide bootstrapping information based on the transmission information of the service guide included in the first signaling table. The second handler accesses the service guide by using the acquired bootstrapping information of the service guide.

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 data for mobile 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. Therefore, when data for mobile broadcasting is transmitted in the VSB transmission scheme, reception performance is further reduced.

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 receiving system and a data processing method for efficiently receiving a service guide.

It is still another object of the present invention to provide a receiving system and a data processing method which are capable of receiving bootstrapping information of a service guide.

It is another object of the present invention to provide a receiving system and a data processing method for receiving bootstrapping information of a service guide transmitted through mobile broadcasting of another channel.

It is another object of the present invention to provide a receiving system and a data processing method for receiving bootstrapping information of a service guide transmitted through another broadcasting network.

It is another object of the present invention to provide a receiving system and a data processing method for receiving bootstrapping information of a service guide transmitted through a bidirectional 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 receiving a broadcast signal through a mobile broadcasting network, the broadcast signal including mobile service data and a first signaling table, Wherein the first signaling table includes transmission information and bootstrapping information of the service guide for the mobile service data, and the first signaling table includes bootstrapping information of the service guide based on transmission information of the service guide included in the first signaling table And accessing the service guide using bootstrapping information of the obtained service guide.

When the transmission information of the service guide indicates that the service guide is included in the broadcast signal including the mobile service data, the bootstrapping information of the service guide includes an identifier of the mobile service including the service guide, Lt; RTI ID = 0.0 > channel < / RTI >

If the transmission information of the service guide indicates that the service guide is included in a broadcast signal of a physical channel different from a physical channel of the broadcast signal including the mobile service data, the bootstrapping information of the service guide may include the service guide A transport stream identifier of the broadcast signal, an identifier of the mobile service including the service guide, and a transmission session identifier for the announcement channel of the service guide.

When the transmission information of the service guide indicates that the service guide is transmitted to a broadcasting network other than the mobile broadcasting network, the bootstrapping information of the service guide may include IP access information for an announcement channel of the service guide, And a transmission session identifier for the announcement channel.

When the transmission information of the service guide indicates that the service guide is transmitted through the bidirectional channel, the bootstrapping information of the service guide includes a URL (Uniform Resource Locator) indicating an entry point location of the service guide.

A receiving system according to an embodiment of the present invention includes a receiving unit, a first handler, and a second handler. The receiving unit receives a broadcasting signal through a mobile broadcasting network. The broadcast signal includes mobile service data and a first signaling table, and the first signaling table includes transmission information and bootstrapping information of a service guide for the mobile service data. The first handler obtains bootstrapping information of the service guide based on transmission information of the service guide included in the first signaling table. The second handler accesses the service guide using bootstrapping information of the obtained service guide.

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, by using the signaling service guide bootstrapping information in the guide access table (GAT) according to the present invention, a service guide related to the current mobile broadcast is currently being transmitted to a mobile broadcast, a mobile broadcast of another channel, The service guide can be accessed.

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

1 is a diagram showing an example in which an SG according to the present invention is transmitted through another physical channel
2 is a diagram showing an example in which an SG according to the present invention is transmitted through another broadcasting network
3 is a diagram showing an example in which an SG according to the present invention is transmitted through another broadcasting network
4 is a diagram showing an example of signaling tables included in a service signaling channel according to the present invention;
5 is a diagram showing an embodiment of the structure of a data group according to the present invention.
6 is a diagram illustrating an RS frame according to an embodiment of the present invention.
7 is a diagram showing the header structure of each M / H transport packet in the RS frame.
8 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.
9 is a diagram showing an embodiment of a data transmission structure for a mobile service according to the present invention.
10 is a diagram illustrating a hierarchical signaling structure in accordance with an embodiment of the present invention.
11 is a diagram showing an embodiment of a syntax structure of an FIC chunk according to the present invention.
12 is a diagram showing an embodiment of a syntax structure of an FIC chunk header according to the present invention.
13 is a diagram showing an embodiment of a syntax structure of an FIC chunk payload according to the present invention;
14 is a diagram showing an embodiment of a syntax structure of an FIC segment header according to the present invention.
15 is a diagram showing an embodiment of a syntax structure of a service map table (SMT) 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;
17 is a diagram showing examples of respective meanings of the SG_delivery_network_type field value in FIG.
18 is a diagram showing an embodiment of the syntax structure of the SG bootstrapping information SG_bootstrap_data () when the SG_delivery_network_type field value according to the present invention is 0x00
19 is a diagram showing an embodiment of the syntax structure of the SG bootstrapping information SG_bootstrap_data () when the SG_delivery_network_type field value according to the present invention is 0x01
20 is a diagram showing an embodiment of the syntax structure of the SG bootstrapping information SG_bootstrap_data () when the SG_delivery_network_type field value is 0x02 according to the present invention.
FIG. 21 is a diagram showing an embodiment of the syntax structure of the SG bootstrapping information SG_bootstrap_data () when the SG_delivery_network_type field value is 0x03 according to the present invention
22 and 23 are flowcharts showing an embodiment of a service guide bootstrap process according to the present invention.
24 is a block diagram showing an embodiment of a receiving system according to the present invention

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. The configuration 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 idea of the present invention and its core configuration and operation 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.

Here, the transmission system corresponds to one mobile broadcasting station, and the mobile broadcasting station transmits the main service data and the mobile service data to each receiving system (also referred to as a receiver or a terminal) using one physical channel. That is, each mobile broadcasting station transmits the main service data and the mobile service data together using the VSB transmitter of the 6 MHz band.

At this time, a service guide (SG) for delivering announcement information on the mobile service data can be transmitted in various ways.

In the present invention, the signaling information necessary for receiving (or accessing) the SG is referred to as service guide bootstrapping information. That is, the service guide bootstrapping information is information necessary for bootstrapping the service guide SG. The service guide bootstrapping information is signaled to the guide access table (GAT) as an embodiment.

In one embodiment, a Service Guide (SG) may be transmitted together via the same physical channel (i.e., the same mobile broadcast) over which the mobile service data is transmitted. In this case, the service guide bootstrapping information necessary for accessing the SG is signaled to the GAT transmitted on the physical channel.

In another embodiment, the service guide may be transmitted over a physical channel other than the physical channel over which the mobile service data is transmitted. For example, as shown in FIG. 1, a market service guide provider collects information (for example, schedule information for a mobile service) for a service guide provided from each mobile broadcasting station and provides an integrated service guide SG) and then transmitted through a separate physical channel (e.g., VSB transmitter in the 6 MHz band). At this time, the market service guide provider has a physical channel (that is, a physical tuning channel (PTC) spectrum) for a separate mobile broadcast, collects information for a service guide provided from each mobile station, And then transmitted to each receiving system through the physical channel held by the market service guide provider. In this case, the present invention transmits service guide bootstrapping information for receiving and processing the integrated SG in the receiving system through a physical channel through which the corresponding mobile service data is transmitted. That is, when the service guide for the mobile service data is transmitted to a physical channel other than the physical channel through which the mobile service data is transmitted, the service guide bootstrapping information for allowing the receiving system to receive and process the mobile service data includes a GAT And transmitted on the same physical channel together with the mobile service data.

In yet another embodiment, the service guide may be transmitted over another broadcast network (e.g., another IP-based broadcast network) rather than mobile broadcast. For example, as shown in FIG. 2, in a hybrid system combining a terrestrial mobile system of the present invention and a DVB-SH (Digital Video Broadcasting-Satellite Services to Handhelds) system for a European digital satellite TV broadcast, After a DVB-SH provider (for example, a DVB-SH service provider) collects information (for example, schedule information for a mobile service) for a service guide provided from a mobile station, , Satellite) to each receiving system. At this time, each mobile broadcasting station transmits main service data and mobile service data to each receiving system using a physical channel assigned to the corresponding broadcasting station. That is, broadcast signals including main service data and mobile service data are transmitted through the mobile (M / H) broadcasting network of the present invention. In this case, the present invention transmits service guide bootstrapping information for receiving and processing an SG transmitted through another broadcasting network in a receiving system through a physical channel through which the corresponding mobile service data is transmitted. That is, when the service guide is transmitted through another broadcasting network other than the mobile broadcasting network to which the mobile service data is transmitted, the service guide bootstrapping information for allowing the receiving system to receive and process the mobile service data is signaled to the GAT, To the same physical channel.

In yet another embodiment, the service guide may be transmitted on a bi-directional channel. For example, in a hybrid system in which a terrestrial mobile system and a bi-directional channel system (e.g., a cellular system, etc.) are combined as shown in FIG. 3, a bi- directional channel SG provider (e.g., a bi-directional channel network such as a cellular network operator, (For example, schedule information for the mobile service, etc.) provided from the mobile broadcasting station, and then transmit the information to the respective receiving systems via the bidirectional channel. At this time, each mobile broadcasting station transmits main service data and mobile service data to each receiving system using a physical channel assigned to the corresponding broadcasting station. That is, the broadcast signal including the main service data and the mobile service data is transmitted through the M / H broadcast network. In this case, the present invention transmits service guide bootstrapping information for receiving and processing an SG transmitted through a bidirectional channel in a receiving system through a physical channel through which the corresponding mobile service data is transmitted. That is, the service guide bootstrapping information for allowing the receiving system to receive and process the service guide when the service guide is transmitted through the bidirectional network instead of the mobile (i.e., M / H) And is transmitted on the same physical channel together with the mobile service data.

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.

Mobile service data (e.g., A / V streaming) is packetized according to a RTP (Real Time Protocol) scheme in a transmission system (e.g., a mobile station) according to the present invention, protocol, and the RTP / UDP packets are 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 signaling table is packetized according to the UDP scheme, and the packetized UDP data is transmitted to the IP scheme Packetized into 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 transmission system of the present invention (for example, a mobile station), an RS frame is formed by collecting the IP datagrams of the mobile service data and the service signaling channel, the data of the RS frame is distributed to a plurality of data groups, For example, the VSB transmission method may be used to modulate and transmit a predetermined transmission scheme. 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.

That is, one RS frame includes an IP datagram of mobile service data for one or more mobile services and an IP datagram of a service signaling channel for reception of the mobile service data.

In the embodiment of the present invention, an ensemble concept is introduced to define a set of services. One ensemble (or M / H ensemble) has the same QoS and is coded with the same FEC code. An ensemble is also a collection of consecutive RS frames with a unique identifier (i.e., ensemble id) and having the same FEC code. At this time, each RS frame is encapsulated into transport packets containing an IP stream (i.e., IP datagram). In other words, the RS frame is an RS-CRC encoded two-dimensional data frame (an ensemble is RS-CRC encoded).

FIG. 4 illustrates a structure of a service signaling channel according to an embodiment of the present invention. FIG. 4 illustrates a service signaling channel structure in an RS frame belonging to an ensemble K. Referring to FIG.

The present invention can be applied to a Service Map Table (SMT), a Guide Access Table (GAT), a cell information table (CIT), a service label table (Service) table Labeling Table (SLT), and Rating Region Table (RRT). Herein, the signaling tables that can be transmitted through the service signaling channel are only exemplary embodiments of the present invention, and the signaling tables that can be transmitted through the service signaling channel are not limited to the above examples.

The SMT provides ensemble level signaling information. Also, each SMT provides IP access information of each mobile service belonging to the ensemble including each SMT. SMT also provides IP stream component level information needed for the mobile service.

The RRT provides rating information related to various regions. That is, the RRT provides content advisory rating information.

The GAT provides information of the SG providers transmitting the service guide. The GAT also provides service guide bootstrapping information needed to access the SG. The service guide bootstrapping information is provided for each SG provider. The service guide bootstrapping information varies depending on the SG transmission scheme. The service guide bootstrapping information includes SG access information. The service guide bootstrapping information may further include a transmission session identifier of an announcement channel.

The CIT provides channel information of each cell, which is a propagation region of a broadcast signal. A range in which a transmitter influences one physical frequency in a Multi-Frequency Network (MFN) environment is called a cell. That is, the CIT provides the adjacent cell carrier frequency information of the current transmitter. Therefore, the receiver can move from one coverage area of the transmitter to another coverage area according to the CIT information (With this information, a receiver can travel from one transmitter's (or Exciter's) coverage area to another).

The SLT provides the necessary minimum information for dedicated channel scan processes. In other words, according to the embodiment of the present invention, besides the SMT, the channel scanning speed can be increased by constructing the minimum information for the channel scanning process using the SLT for exclusive use of the channel scanning process.

In the present invention, each signaling table is divided into one or more sections, each section is encapsulated into a UDP / IP header, and then transmitted through a service signaling channel. In this case, the number of UDP / IP packets transmitted on the service signaling channel may vary according to the number of signaling tables transmitted on the service signaling channel and the number of sections of each signaling table.

At this time, all the UDP / IP packets transmitted to the service signaling channel have the same well-known target IP address and a well-known target UDP port number. For example, assuming that the SMT, RRT, and GAT are transmitted through the service signaling channel, the target IP address and the target UDP port number of all the UDP / IP packets transmitting the SMT, RRT, and GAT are the same. Also, the target IP address and the target UDP port number are known values in the receiving system due to the well-known value, that is, the promise of the transmitting / receiving system.

Therefore, the division of each signaling table included in the service signaling data is performed by a table identifier. The table identifier may be a table_id existing in the corresponding signaling table or a header of the corresponding signaling table section, and may be further classified by referring to a table_id_extension if necessary.

Data format structure

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.

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

5 shows an example in which a 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. 5, 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 the data 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 the M / H block B7 in the data group of FIG. 5 show an example where long known data strings are inserted before and after each M / H block as an area free of 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. 5 are areas where interference of 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.

The M / H block B2 and the M / H block B9 in the data group of FIG. 5 have more interference of the main service data than the B area, and can not 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.

The M / H block B1 and the M / H block B10 in the data group of FIG. 5 have more interference of the main service data than the C area, and similarly, it is impossible to insert a long known data sequence 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. 5, 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.

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

At this time, one M / H TP may include M / H header and not become N bytes.

In this case, a stuffing byte may be allocated to the remaining payload portion of the corresponding M / H TP. For example, after allocating a service signaling channel to one M / H TP, if the length of the M / H TP is N-20 bytes including the M / H header, stuffing bytes are allocated to the remaining 20 bytes .

FIG. 7 shows examples of fields allocated to the M / H header area in the M / H TP according to the present invention, and may include a type_indicator field, an error_indicator field, a stuff_indicator field, and a pointer field.

The type_indicator field can allocate 3 bits in one embodiment and indicates the type of data allocated to the payload in the corresponding M / H TP.

The error_indicator field may be assigned 1 bit in one embodiment and indicates whether the corresponding M / H TP is erroneous. For example, if the value of the error_indicator field is 0, it means that there is no error in the corresponding M / H TP, and if it is 1, it means that there is an error.

The stuff_indicator field may allocate 1 bit in one embodiment and indicates whether a stuffing byte is present in the payload of the corresponding M / H TP. For example, if the value of the stuff_indicator field is 0, it means that there is no stuffing byte in the M / H TP, and if it is 1, it means that there is a stuffing byte.

The pointer field may allocate 11 bits in one embodiment and indicate location information where new data (i.e., a new IP datagram) starts in the corresponding M / H TP. If there is no data to start newly in the corresponding M / H TP, the pointer field value is displayed as a maximum value. In the present invention, 11 bits are allocated to the pointer field. Thus, if 2047 is indicated in the pointer field value, it means that there is no data to be newly started. The point indicated when the pointer field is 0 may be changed according to the type_indicator field value and the stuff_indicator field value.

The order, location, and meaning of the fields allocated to the M / H header in the M / H TP shown in FIG. 7 are only an example for facilitating understanding of the present invention, and the fields assigned to the header in the M / The order, the location, the meaning, and the number of additional allocated fields can be easily changed by those skilled in the art, the present invention is not limited to the above embodiment.

The M / H payload in the M / H TP may include at least one of an IP datagram of mobile service data and an IP datagram of a service signaling channel.

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 signaling channel. An IP datagram of the service signaling channel is received in a corresponding RS frame with a well-known IP address and a well-known UDP port number.

The IP datagram of the service signaling channel includes one or more signaling tables. The IP datagram of the service signaling channel may include at least one of SMT, GAT, CIT, SLT, and RRT as shown in FIG. 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.

In the RS frame of FIG. 6, there are three types of IP datagrams (IP Datagrams 1, 2 and 3), one of which is an IP datagram for a service signaling channel. The remaining IP datagrams may be IP datagrams of mobile service data or IP datagrams for service guides.

The transmission system performs RS coding in the column direction with respect to the RS frame, CRC coding in the row direction with respect to the RS frame, and data of RS frames and CRC encoded RS frames is allocated to a corresponding area 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

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

FIG. 8 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 is transmitted, if the RS frame mode value is 01, the data of the primary RS frame for the A / B area (the primary RS frame for the region A / B) / B area, and the data of the secondary RS frame for region C / D for the C / D area is allocated to the C / D area 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.

FIG. 9 is a diagram illustrating a data transmission structure in a physical layer according to an embodiment of the present invention. In FIG. 9, 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. 9, 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 Segmental concatenated convolutional code (SCCC) encoding are applied to the RS frame data, and RS encoding and parallel concatenated convolutional code (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 structure

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

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

As can be seen in Figure 10, 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.

Fast Information Channel (FIC)

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

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

To this end, the FIC chunk header may include an FIC_major_protocol_version field, an FIC_minor_protocol_version field, a 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, and a num_ensembles 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 above time limit. The above time limit. The change 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).

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

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

The FIC chunk payload includes configuration information of an ensemble and information on a mobile service transmitted through each ensemble, for each ensemble corresponding to the num_ensembles field value in the FIC chunk header of FIG. 12 have.

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 ensemble_protocol_version field, an SLT_ensemble_indicator field, a GAT_ensemble_indicator field, an MH_service_signaling_channel_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, 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 ensemble_protocol_version field allocates 5 bits in one embodiment and indicates a version of the ensemble structure.

The SLT_ensemble_indicator field allocates 1 bit in one embodiment and indicates whether the SLT is transmitted in the service signaling channel of the ensemble. For example, if the value of the SLT_ensemble_indicator field is 1, it indicates that the SLT is transmitted on the service signaling channel, and if it is 0, it indicates that the SLT is not transmitted.

The GAT_ensemble_indicator field allocates 1 bit in one embodiment and indicates whether the GAT is transmitted in the service signaling channel of the ensemble. For example, if the value of the GAT_ensemble_indicator field is 1, it indicates that the GAT is transmitted on the service signaling channel, and if it is 0, it indicates that the GAT is not transmitted.

The MH_service_signaling_channel_version field allocates 5 bits in one embodiment and indicates the version number of the service signaling channel of the ensemble.

In the num_M / H_services field, 8 bits are allocated, and the number of mobile services transmitted in the ensemble is displayed (An 8-bit unsigned integer field represents the number of mobile ( ie, M / H) carried through this 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 multi_ensemble_service field allocates 2 bits in one embodiment and indicates whether the corresponding mobile service is transmitted through one ensemble or a plurality of ensembles. Also, the value of the service_span field indicates whether the mobile service is valid only for the mobile service part transmitted through the ensemble (A two-bit enumerated field that indicates whether the 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).

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. 14 shows an embodiment of a syntax structure of an FIC segment header according to the present invention.

The FIC segment header may include a FIC_segment_type field, a FIC_chunk_major_protocol_version field, a current_next_indicator field, an error_indicator field, an FIC_segment_num field, and a FIC_last_segment_num field. The description of each field is as follows.

The FIC_segment_type field (2 bits) indicates the type of the corresponding FIC segment. 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 FIC_chunk_major_protocol_version field (2 bits) indicates the major protocol version of the corresponding FIC chunk. The value of this field shall be the same as the FIC_major_protocol_version field value in the corresponding FIC chunk header. A detailed description of the major protocol version of the FIC chunk syntax will be omitted since it will be described with reference to the description of the FIC chunk header of FIG. 12 described above.

The current_next_indicator field (1 bit) indicates whether the corresponding FIC segment is applied to the current M / H frame or the next M / H frame. For example, if the field value is set to 1, the corresponding FIC segment indicates that a part of the FIC chunk applicable to the current M / H frame is transmitted. Conversely, if the field value is set to 0, the corresponding FIC segment indicates to transmit a part of the FIC chunk that can be applied to the next M / H frame.

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.

On the other hand, FIG. 15 shows an embodiment of a bitstream syntax structure of the SMT section. 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.

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) indicates whether the corresponding mobile service is transmitted via one or more ensembles. The multi_ensemble_service field has the same meaning as the multi_ensemble_service field included in the FIC chunk, and thus a detailed description thereof will be omitted.

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 source specific multicast (source_IP_address_flag: A 1-bit Boolean flag that indicates indicate, when set, that a source IP address value for this service is present to indicate a source specific multicast).

When the MH_service_destination_IP_address_flag field (1 bit) is set, 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 not when 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) indicates whether the component is a necessary component for the mobile service. For example, if the value of the essential_component_indicator field is set to '1', the corresponding component indicates that it is a necessary component for the mobile service. 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 present, the destination address of the IP datagrams is the address of the M / H_service. The IP address of the M / H_service_destination_IP_address field, which is the address of the M / H_service_destination_IP_address field, 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.

16 shows an embodiment of a bitstream syntax structure of a GAT section according to the present invention. Here, the GAT section is prepared in the form of an MPEG-2 private section for the sake of understanding, but the data format of the GAT section may be any form.

The GAT section according to the present invention is received 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 section includes service guide provider information and service guide bootstrapping information for each provider.

In FIG. 16, the table_id field (8 bits) is an identifier of the table, and an identifier for identifying the GAT may be set.

The section_syntax_indicator field (1 bit) is an indicator that defines the section format of the GAT.

The private_indicator field (1 bit) indicates whether the GAT section conforms to a private section.

The section_length field (12 bits) indicates the length of the section of the remaining GAT after the corresponding field.

In addition, the GAT of FIG. 16 can be used as one of the table identifiers for allocating the 16-bit GAT_protocol version field to the table_id_extension field position and distinguishing the GAT when the GAT is received on the service signaling channel. That is, the GAT_protocol version field indicates a protocol version for permitting the GAT to be transmitted by parameters having a different structure from those defined in the current protocol (GAT_protocol_version: An 16-bit unsigned integer field whose function is to allow the in At present, the value of the GAT_protocol_version shall be zero. The non-zero values of GAT_protocol_version may be used in a future version of this standard. structurally different tables).

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

The current_next_indicator field (1 bit) indicates whether the GAT section is currently applicable.

The section_number field (8 bits) indicates the section number of the current GAT section.

The last_section_number field (8 bits) 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.

Thereafter, 'for' loops (or SG Provider Loops) corresponding to the num_SG_provides field values are performed to provide SG bootstrapping information for each SG provider. In one embodiment, the following field information may be provided for each SG provider.

The SG_provider_name_length field (8 bits) indicates the total length of the SG_provider_name_text () field to be connected, in bytes.

The SG_provider_name_text () field (var) indicates the name of the corresponding SG provider and has a multiple string structure.

The SG_delivery_network_type field (8 bits) indicates the type of the delivery network to which the SG is transmitted. 17 shows the meaning of the SG_delivery_network_type field value according to the present invention.

The SG_bootstrapping_data_length field (8 bits) indicates the total length of the SG_bootstrap_data () field to be connected, in bytes.

The SG_bootstrap_data () field (var) provides SG bootstrapping information according to the SG_delivery_network_type field value as shown in FIGS. 18 to 21.

Also, each SG provider may provide additional information applicable to each SG provider using a descriptor.

According to another embodiment of the present invention, the SG_level_descriptors () included in the SG provider loop include the SG_delivery_network_type field, the SG_bootstrapping_data_length field, and the SG_bootstrap_data () field, and the SG_delivery_network_type And may provide bootstrapping information.

The num_additional_descriptors field (8 bits) indicates the number of descriptors to be continued. The additional_descriptor (), which is repeated by the number corresponding to the num_additional_descriptors field value, describes additional information applicable to all SG providers included in the GAT section.

In one embodiment, if the SG_delivery_network_type field value is 0x00, the SG is transmitted on the same mobile (i.e., M / H) broadcast over which the GAT is transmitted (the SG is delivered to the same M / is delivered.). That is, the SG is included as a mobile service in the RS frame belonging to the ensemble in which the GAT is transmitted.

In another embodiment, if the value of the SG_delivery_network_type field is 0x01, the SG is transmitted through a mobile broadcast other than the mobile broadcast in which the GAT is transmitted (the SG is delivered from a different mobile (i.e., M / H) broadcast from the mobile broadcast where the GAT is delivered. That is, the SG is received as one mobile service in an RS frame belonging to an ensemble other than the ensemble to which the GAT is transmitted. FIG. 1 is a diagram showing an embodiment of such a case. A service guide provider having a separate physical channel collects information for a service guide provided from each broadcasting station, As shown in FIG.

In another embodiment, if the value of the SG_delivery_network_type field is 0x02, the SG is transmitted through another related IP based broadcasting channel rather than mobile broadcasting. FIG. 2 illustrates an embodiment of such a hybrid system in which a terrestrial mobile system and a DVB-SH (Digital Video Broadcasting-Satellite Services to Handhelds) system for a European digital satellite TV broadcast are combined (DVB-SH service provider) collects information (for example, schedule information for mobile services) for a service guide provided from a mobile station, That is, satellite) to each receiving system.

In another embodiment, if the value of the SG_delivery_network_type field is 0x03, the SG is transmitted on a bi-directional channel. FIG. 3 shows an embodiment of such a case. In a hybrid system in which a terrestrial mobile system and a bi-directional channel system (e.g., a cellular system, etc.) are combined, a bidirectional channel SG provider (e.g., a cellular network operator, (E.g., a carrier or a server operator having a two-way channel network) can collect information (for example, schedule information for a mobile service) for a service guide provided from a mobile broadcasting station and then transmit the information to each receiving system via a bidirectional channel.

FIG. 18 shows an embodiment of a bit stream syntax structure of SG_bootstrap_data () when the SG_delivery_network_type field value is 0x00, that is, when the SG is currently transmitted via mobile broadcasting. In other words, an SG that conveys announcement information related to mobile service data is included in a mobile broadcast for transmitting the mobile service data.

The SG bootstrapping information SG_bootstrap_data () in FIG. 18 includes an MH_service_id field (16 bits) and an announcement_channel_TSI field (16 bits) field.

When the SG_delivery_network_type field value is 0x00, the SG is transmitted as one mobile service, and thus the MH_service_id field indicates an identifier capable of identifying the mobile service including the SG data. At this time, the access information of the mobile service for the SG data is signaled to the SMT included in the mobile broadcasting transmitting the SG as shown in FIG. That is, the MH_service_id field value of FIG. 18 matches one of the MH_service_id field values included in the SMT mobile service loop.

The announcement_channel_TSI field indicates a Transmission Session Identifier (TSI) for a FLUTE session, which is an announcement channel of the mobile service including the SG data (A 16-bit unsigned integer number, the FLUTE session which is the Announcement Channel of the SG data service. That is, the announcement_channel_TSI field value is an identifier that uniquely identifies a FLUTE session, which is an announcement channel.

That is, through the matching of the MH_service_id field value of the SMT acquired from the current mobile broadcast and the MH_service_id field value of FIG. 18, IP access information of the mobile service including the SG data (for example, Destination IP address, Nation UDP port number). Then, an IP datagram is obtained from the mobile broadcasting (that is, an RS frame belonging to the ensemble including the SMT and the GAT) using the IP access information, and the IP datagram is obtained from the obtained IP datagram using the announcement_channel_TSI field value. / LCT header, and then connect to the corresponding FLUTE session to receive the SG data.

FIG. 19 shows an embodiment of a bit stream syntax structure of SG_bootstrap_data () of the GAT when the SG_delivery_network_type field value is 0x01, that is, when the SG is transmitted through another mobile broadcast other than the GAT. That is, the SG_bootstrap_data () of the GAT provides bootstrapping information of the SG when the SG associated with the mobile services transmitted through the mobile broadcast including the GAT is transmitted through another mobile broadcast.

The SG bootstrapping information SG_bootstrap_data () in FIG. 19 includes a transport_stream_id field (16 bits), an MH_service_id field (16 bits), and an announcement_channel_TSI field (16 bits) field.

When the value of the SG_delivery_network_type field is 0x01, the transport_stream_id field indicates a label capable of identifying a mobile broadcast transmitting the SG. That is, it indicates the transport stream ID of the mobile broadcast to which the SG is transmitted. The transport_stream_id field value in FIG. 19 is the same as the header of the program map table (PAT) and the transport_stream_id field value in the FIC chunk header in FIG.

Also, even when the SG_delivery_network_type field value is 0x01, since the SG is transmitted as one mobile service, the MH_service_id field indicates an identifier capable of identifying a mobile service of the SG data. At this time, the IP access information of the mobile service including the SG data is signaled to the SMT included in the mobile broadcasting transmitting the SG, rather than the mobile broadcasting transmitting the GAT, as shown in FIG. That is, the MH_service_id field value in FIG. 19 matches one of the MH_service_id field values included in the SMT mobile service loop.

The announcement_channel_TSI field indicates a Transmission Session Identifier (TSI) for a FLUTE session, which is an announcement channel of the mobile service including the SG data (A 16-bit unsigned integer number, the FLUTE session which is the Announcement Channel of the SG data service.

That is, if the SG_delivery_network_type field value is 0x01, after receiving the mobile broadcast corresponding to the transport_stream_id field value of FIG. 19, the MH_service_id field value of the SMT acquired from the received mobile broadcast is matched with the MH_service_id field value of FIG. 19 , IP access information (for example, destination IP address, destination UDP port number) of the mobile service including SG data is obtained from the SMT. Then, an IP datagram is obtained from the mobile broadcast (i.e., an RS frame belonging to the ensemble including the SMT) using the IP access information, the ALC / LCT header is removed from the obtained IP datagram, and the announcement_channel_TSI field value To access the corresponding FLUTE session and receive the SG data.

FIG. 20 shows an embodiment of the bit stream syntax structure of SG_bootstrap_data () of the GAT when the SG_delivery_network_type field value is 0x02, that is, when the SG is transmitted through another IP based broadcasting network. That is, SG_bootstrap_data () of the GAT provides bootstrapping information of the SG when the SG associated with the mobile services transmitted through the mobile broadcast including the GAT is transmitted through another IP-based broadcast network.

The SG bootstrapping information SG_bootstrap_data () of FIG. 20 includes fields of an IP_version_flag field (1 bit), a source_IP_address_flag field (1 bit), an SG_bootstrap_destination_IP_address field (32 or 128 bits), an SG_bootstrap_destination_UDP_port_num field (16 bits), and an announcement_channel_TSI field . Further, the SG_bootstrap_source_IP_address field (32 or 128 bits) may be further included according to the source_IP_address_flag field value.

In FIG. 20, if the source_IP_address_flag field is set to 1, it indicates that a source IP address value for the corresponding SG announcement channel exists to indicate source specific multicast.

When the IP_version_flag field is set to '1', the source_IP_address field and the SG_bootstrap_destination_IP_address field indicate IPv6 addresses, and when set to '0', the source_IP_address field and the SG_bootstrap_destination_IP_address field indicate IPv4 addresses.

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 when the source_IP_address_flag is not set to '0'. If the source_IP_address_flag is '1', the source_IP_address field indicates the source IP address of all the IP datagrams transmitting the SG announcement channel as 32 bits or 128 bits. When the source_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', the source_IP_address field is represented by a 32-bit IPv4 address. If the IP_version_flag field is set to '1', the source_IP_address field is represented by a 128-bit IPv6 address.

The SG_bootstrap_destination_IP_address field indicates the destination IP address of the SG announcement channel. If the IP_version_flag field is set to '0', the SG_bootstrap_destination_IP_address field is displayed as a 32-bit IPv4 address. When the IP_version_flag field is set to '1', the SG_bootstrap_destination_IP_address field is indicated by a 128-bit IPv6 address.

The SG_bootstrap_destination_UDP_port_num field indicates the destination UDP port number of the SG announcement channel.

The announcement_channel_TSI field indicates the transport session identifier (TSI) of the FLUTE session, which is the announcement channel of the SG.

That is, an IP datagram is obtained using the SG_bootstrap_destination_IP_address field and the SG_bootstrap_destination_UDP_port_num field of FIG. 20 from a broadcast signal received through another broadcasting network (ie, another IP-based broadcasting network) transmitting the SG, And then accesses the corresponding FLUTE session using the announcement_channel_TSI field value to receive the SG data.

FIG. 21 shows an embodiment of the bit stream syntax structure of the SG_bootstrap_data () of the GAT when the SG_delivery_network_type field value is 0x03, that is, when the SG is transmitted on the bi-directional channel. That is, the SG_bootstrap_data () of the GAT provides the bootstrapping information of the SG when the SG associated with the M / H services transmitted through the M / H broadcast including the GAT is transmitted through the bi-directional channel.

The SG bootstrapping information SG_bootstrap_data () in FIG. 21 includes an SG_entrypoint_URL_text_length field (8 bits) and an SG_entrypoint_URL_text field (var).

The SG_entrypoint_URL_text_length field indicates the total length of the SG_entrypoint_URL_text field to be connected in bytes.

The SG_entrypoint_URL_text field indicates a URL (Uniform Resource Locator) indicating the location of the SG entry point.

That is, based on the value of the SG_entrypoint_URL_text field, a bidirectional channel for transmitting the SG is accessed to receive SG data.

22 and 23 are flowcharts showing an embodiment of a bootstrap performing method of a service guide according to the present invention.

First, a mobile (i.e., M / H) broadcast signal including a mobile (i.e., M / H) service selected by the user is received and demodulated (S101). In operation S102, FIC chunks are acquired by obtaining FIC segments from the demodulated mobile broadcast signal, and mapping information between the ensemble and the mobile service is configured using information included in the restored FIC chunk. The mapping information between the ensemble and the mobile service may include an ensemble identifier, a mobile service identifier included in the ensemble identified by the ensemble identifier, service type information, and the like.

Further, an RS frame including a mobile service selected by the user is configured from the demodulated mobile broadcast signal, and CRC decoding and RS decoding are performed on the RS frame (S103). The service signaling channel is obtained from the RS frame (i.e., RS frame payload) in which the CRC decoding and the RS decoding are performed (S104), and a GAT section included in the service signaling channel is extracted (S105). That is, a GAT section is extracted from an IP datagram (for example, an IP multicast stream) of a service signaling channel having a well-known IP address and a well-known UDP port number using a table identifier.

Then, the number of SG providers (num_SG_providers) described in the GAT section is obtained from the GAT section (S106). The steps after S106 are repeated as many times as the number of the obtained SG providers to collect SG bootstrapping information for each SG provider and access the SG provided by each SG provider.

That is, the name information (SG_provider_name_length, SG_provider_name_text) of the corresponding SG provider, the SG transport network type (SG_delivery_network_type) to which the SG is transmitted, and the length of the bootstrapping data (SG_bootstrapping_data_length) of the SG are obtained for each SG provider at step S107.

Then, the SG bootstrapping information is obtained according to the SG transport network type (SG_delivery_network_type) acquired in step S107, and the corresponding SG is accessed using the obtained SG bootstrapping information.

If it is determined in step S108 that the SG_delivery_network_type field value is 0x00, a mobile service identifier (MH_service_id) and a transmission session identifier (announcement_channel_TSI) of the announcement channel (announcement_channel_TSI) are obtained from SG_bootstrap_data () as shown in FIG. 18 (S109).

Then, the SMT included in the service signaling channel acquired in S104 is extracted (S110). Next, IP access information related to the M / H service ID acquired in step S109 is acquired from the SMT extracted in step S110 (S111). The IP multicast stream is obtained from the RS frame belonging to the ensemble including the SMT (i.e., the CRC decoded and RS decoded RS frame in S103) on the basis of the obtained IP access information (S112) After the ALC / LCT header is removed from the multicast stream, a FLUTE session related to the announcement_channel_TSI is received or joined (S113), and the SG data is accessed (S114).

That is, through the matching of the MH_service_id field value of the SMT acquired from the current mobile broadcast and the MH_service_id field value of FIG. 18, IP access information of the mobile service including the SG data (for example, Destination IP address, Nation UDP port number). (I.e., an IP multicast stream) from the mobile broadcast (i.e., an RS frame belonging to the ensemble including the SMT) using the IP access information, and acquires an IP datagram from the obtained IP datagram using the ALC / And removes the LCT header and accesses the corresponding FLUTE session using the announcement_channel_TSI field value to receive the SG data.

If it is determined in step S108 that the SG_delivery_network_type field value is 0x01, a transport stream identifier (transport_stream_id), a mobile service identifier (MH_service_id), and a transmission session identifier of an announcement channel (announcement_channel_TSI (S115).

The mobile broadcast signal related to the transport stream identifier (transport_stream_id) is received and demodulated (S116). For example, the mobile broadcast signal received in S116 and the mobile broadcast signal received in S101 have different transport stream identifiers. In step S116, FIC segments are obtained from the mobile broadcast signal demodulated in step S116 to recover the FIC chunk, and an ensemble associated with the mobile service identifier obtained in step S115 is identified from the restored FIC chunk (step S117). Then, an RS frame belonging to the identified ensemble is configured from the mobile broadcast signal demodulated in S116, and CRC decoding and RS decoding are performed on the RS frame. The service signaling channel is obtained from the RS frame (i.e., RS frame payload) in which the CRC decoding and the RS decoding are performed, and the SMT included in the service signaling channel is extracted (S118). That is, an SMT section is extracted from an IP datagram (for example, an IP multicast stream) of a service signaling channel having a well-known IP address and a well-known UDP port number using a table identifier.

In step S119, IP access information related to the mobile service identifier acquired in step S115 is acquired from the SMT extracted in step S118. Acquires an IP multicast stream from the RS frame including the SMT extracted in S118 based on the obtained IP access information (S120), removes the ALC / LCT header from the obtained IP multicast stream, and then transmits the announcement_channel_TSI The relevant FLUTE session is received or joined (S121), and the SG data is accessed (S122).

That is, after receiving the mobile broadcast corresponding to the transport_stream_id field value of FIG. 19, the SG data is retrieved from the SMT through the matching of the MH_service_id field value of the SMT acquired from the received mobile broadcast and the MH_service_id field value of FIG. (For example, a destination IP address, a destination UDP port number) of the mobile service including the IP address of the mobile terminal. Then, an IP datagram (i.e., an IP multicast stream) is obtained from the mobile broadcast (i.e., the RS frame belonging to the ensemble) using the IP access information, and the ALC / LCT header is removed from the obtained IP datagram And then accesses the corresponding FLUTE session using the announcement_channel_TSI field value to receive the SG data.

If it is determined in step S108 that the SG_delivery_network_type field value is 0x02, the IP access information for SG bootstrap and the announcement channel identifier (announcement_channel_TSI) of the announcement channel (announce_channel_TSI) are obtained from SG_bootstrap_data () as shown in FIG. 20 (S123) . The IP access information for the SG bootstrap includes an SG bootstrap destination IP address (SG_bootstrap_destination_IP_address) and an SG bootstrap destination UDP number (SG_bootstrap_destination_UDP_port_num). The IP access information for the SG bootstrap may further include an SG bootstrap source IP address (SG_bootstrap_source_IP_address).

When the SG bootstrapping information of the corresponding SG provider is obtained in step S123, tuning of another broadcasting network transmitting the SG is performed to collect appropriate parameters (step S124), and an IP multicast stream is acquired from the other broadcasting network using the parameters S125). After the ALC / LCT header is removed from the obtained IP multicast stream, a FLUTE session related to the announcement_channel_TSI obtained in S121 is received or joined (S126), and the SG data is accessed (S127).

That is, an IP datagram is obtained using the SG_bootstrap_destination_IP_address field and the SG_bootstrap_destination_UDP_port_num field of FIG. 20 from a broadcast signal received through another broadcasting network (ie, another IP-based broadcasting network) transmitting the SG, And then accesses the corresponding FLUTE session using the announcement_channel_TSI field value to receive the SG data.

If it is determined in step S108 that the SG_delivery_network_type field value is 0x03, connection information for SG bootstrap is obtained from SG_bootstrap_data () as shown in FIG. 21 (S128). The connection information includes an SG entry point URL (SG_entrypoint_URL). Then, the bidirectional channel is accessed based on the connection information (S129), and the SG data is received (S130).

When one of the steps S114, S122, S127, and S130 is performed and SG data is received, 1 is subtracted from the num_SG_providers value obtained in S106 (S131), and it is confirmed whether the num_SG_providers value is 0 (S132). If the value of num_SG_providers is not 0, the process returns to step S107 to extract the bootstrapping information for accessing the SG transmitted by the next SG provider and access the SG. If the num_SG_providers value is 0, the SG bootstrap process is terminated because all the SGs provided by the SG providers included in the GAT section are received.

Receiving system

24 is a block diagram showing an embodiment of a receiving system according to the present invention.

24, a solid line arrow indicates a data path and a dashed line arrow indicates a control signal path.

The receiving system of FIG. 24 includes an operation controller 2100, a tuner 2111, a demodulator 2112, an equalizer 2113, a known data detector 2114, a block decoder 2115, a primary RS frame Decoder 2116, a secondary RS frame decoder 2117, a signaling decoding unit 2118, and a baseband controller 2119. [ Here, the receiving system may further include an FIC handler 2121, a service manager 2122, a service signaling handler 2123, and a first storage unit 2124. The receiving system may further include a primary RS frame buffer 2131, a secondary RS frame buffer 2132, and a transport packet (TP) handler 2133. The receiving system includes an Internet protocol (IP) datagram handler 2141, a descrambler 2142, a user datagram protocol (UDP) datagram handler 2143, an RTP / RTCP (Real- time Transport Control Protocol (NTP) datagram handler 2144, an NTP (Network Time Protocol) datagram handler 2145, a service protection stream handler 2146, a second storage unit 2147, an ALC / LCT (Extensible Mark-up Language) parser 2150 and an FDT (Field Device Tool) handler 2151. The Layered Coding / Layered Coding Transport have. The receiving system may further include an A / V decoder 2161, a file decoder 2162, a third storage unit 2163, a middleware engine 2164, and an SG handler 2165. The receiving system may further include an EPG manager 2171, an application manager 2172, and a UI (User Interface) The receiving system further includes another broadcasting network interface unit 2001 for receiving a service guide transmitted through another broadcasting network and a bidirectional network interface unit 2003 for receiving a service guide transmitted through a bidirectional channel. The bidirectional network interface unit 2003 is configured to interface with an IP-based bidirectional network irrespective of a physical medium such as wireless or optics.

Hereinafter, for the sake of convenience of description, a description will be made of a tuner 2111, a demodulator 2112, an equalizer 2113, a known data detector 2114, a block decoder 2115, a primary RS frame decoder 2116, a secondary RS A signal decoder 2118 and a baseband controller 2119 and is referred to as a baseband processor 2110. The FIC handler 2121, the service manager 2122, the service signaling handler 2123, 1 storage unit 2124 to be referred to as a service demultiplexer 2120. The IP adaptation module 2130 includes the primary RS frame buffer 2131, the secondary RS frame buffer 2132 and the transport packet handler 2133. The IP adaptation module 2130 includes an IP datagram handler 2141, a descrambler 2142, a UDP datagram handler 2143, an RTP / RTCP datagram handler 2144, an NTP datagram handler 2145, a service protection stream handler 2146, a second storage 2147, an ALC / LCT stream handler 2148, a decompressor 2149, an XML parser 2150, and an FDT handler 2151. The application module 2160 includes the A / V decoder 2161, the file decoder 2162, the third storage unit 2163, the middleware engine 2164, and the SG handler 2165.

Although the term used in FIG. 24 is a general term that is widely used at present, it has been arbitrarily used by the applicant in the present invention in accordance with the emergence of a new technology. . Therefore, it should be understood that the present invention should be grasped as a meaning of a term that is not a name of a simple term in understanding the present invention.

24, the baseband controller 2119 controls the operation of each block of the baseband processor 2110. [

That is, the tuner 2111 tunes the receiving system at a frequency of a specific physical channel (or a physical transmission channel, PTC) to transmit main service data, which is a broadcast signal for the fixed broadcast receiving apparatus, Lt; / RTI > mobile service data. The tuner 2111 down-converts the frequency of the tuned specific channel to an intermediate frequency (IF) signal and outputs the down-converted signal to a demodulator 2112 and a known data detector 2114.

At this time, the tuner 2111 may receive main service data and mobile service data, and may receive service guide data related to the mobile service data or service guide data related to other mobile service data.

That is, the service guide for transmitting announcement information on the mobile service data included in the mobile broadcast signal currently received through the tuner 2111 may be received in the mobile broadcast signal, Or may be received via a mobile broadcast signal. The service guide in this case is received and processed by the tuner 2111 of the baseband processing section 2110 under the control of the service manager 2122 and / or the operation controller 2100. The service guide transmitted through another broadcasting network may be transmitted to another broadcasting network interface unit 2001 under the control of the service manager 2122 and / or the operation controller 2100 Lt; / RTI > The service guide transmitted through the bidirectional channel may be transmitted through the bidirectional network interface unit 2003 by the service manager 2122 and / or the operation controller 2100 Received and processed.

The passband digital IF signal output from the tuner 2111 may include only main service data, may include only mobile service data, or may include main service data and mobile service data.

The demodulator 2112 performs automatic gain control, carrier recovery, and timing recovery on the digital IF signal of the passband inputted from the tuner 2111 to generate a baseband signal, and then outputs an equalizer 2113 and a known data detector 2114 . The demodulator 2112 can improve the demodulation performance by using the known data symbol sequence received from the known data detector 2114 during timing recovery or carrier recovery.

The equalizer 2113 compensates for the distortion on the channel included in the demodulated signal from the demodulator 2112, and outputs the compensated signal to the block decoder 2115. The equalizer 2113 can improve the equalization performance by using the known data symbol sequence received from the known data detector 2114. [ Also, the equalizer 2113 may improve the equalization performance by receiving the decoding result of the block decoder 2115.

The known data detector 2114 detects the known data positions inserted at the transmitting side from the input / output data of the demodulator 2112, that is, the data before the demodulation or the demodulated data, and generates the known data at the position To the demodulator 2112, the equalizer 2113, and the baseband controller 2119. [0156] The known data detector 2114 outputs information for enabling the block decoder 2115 to distinguish the mobile service data that has been further encoded in the transmitting side and the main service data that has not undergone the additional coding to the block decoder 2115 do.

The block decoder 2115 receives the data after the channel equalization in the equalizer 2113 and the data in which both the block encoding and the trellis encoding of the serial concatenated convolutional code (SCCC) (I.e., main data), it performs trellis decoding and block decoding inversely to the transmitting side. If the data is only Trellis-encoded (i.e., main service data) without performing block encoding, only Trellis decoding .

The signaling decoder 2118 decodes the signaling data input after being equalized by the equalizer 2113. It is assumed that the signaling data (or signaling information) input to the signaling decoder 2118 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 2118 performs the recursive turbo decoding of the data of the signaling information area of the input data in parallel concatenated convolutional code (PCCC), then outputs FIC data and TPC Separate the data. In addition, the signaling decoder 2118 performs RS decoding on the separated TPC data in reverse to the transmitting side, and outputs it to the baseband controller 2119. The signaling decoder 2118 deinterleaves the separated FIC data on a subframe basis, performs RS decoding inverse to the transmitting side, and outputs the resultant signal to the FIC handler 2121. The transmission unit of the FIC data deinterleaved and RS-decoded by the signaling decoder 2118 and output to the FIC handler 2121 is an FIC segment.

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

The FIC segment buffer buffers the FIC segments in units of M / H frames input from the signaling decoder 2118, and outputs the FIC segments to the FIC segment parser. The FIC segment parser extracts and analyzes the header of each FIC segment stored in the FIC segment buffer, and outputs the payload of the corresponding FIC segment to the FIC chunk parser according to the analysis result. The FIC chunk parser reconstructs and analyzes the FIC chunk data structure from the FIC segment payloads using the results analyzed in the FIC segment parser to extract signaling information for service acquisition. The signaling information obtained from the FIC chunk parser is output to the service manager 2122.

The service signaling handler 2123 includes a service signaling buffer and a service signaling parser. The service signaling handler 2123 includes table sections included in a service signaling channel transmitted from the UDP datagram handler 2143, for example, an SMT section, a GAT Sections are buffered and analyzed and processed. SMT information and GAT information processed by the service signaling handler 2123 are also output to the service manager 2122.

The service signaling channel for transmitting the SMT section and the GAT section is received in a corresponding RS frame in the form of a UDP / IP packet having a well-known IP destination address and a well-known destination UDP port numb d . Therefore, the receiving system can acquire the service signaling channel without requesting the separate IP access information, and distinguishes each signaling table (e.g., SMT, GAT, etc.) in the obtained service signaling channel by using the table identifier.

The SMT section provides signaling information (including IP access information) for all services in the ensemble including the SMT section. Therefore, the IP stream component belonging to the service desired to be received can be accessed using the information parsed from the SMT, and the corresponding service can be provided to the user. Also, the SMT section provides IP access information of the mobile service including the SG data if the service guide data is received as one mobile service by being included in the ensemble including the SMT.

The GAT section provides information on the SG providers transmitting the service guide and service guide bootstrapping information necessary for accessing the SG provided by each SG provider. The SG bootstrapping information varies depending on a transmission method of the SG and includes access information of the corresponding SG. The SG bootstrapping information may further include a transmission session identifier of the announcement channel.

The service manager 2122 transmits the current RS frame, the tuner 2111, the other network interface unit 2001, the bidirectional network interface unit 2003, and the RS frame using the SG bootstrapping information signaled for each SG provider included in the GAT. The corresponding SG is received. That is, based on the SG bootstrapping information signaled to the GAT extracted from the mobile broadcast signal received through the tuner 2111, the service guide related to the mobile broadcast signal is divided into a mobile broadcast signal, a mobile broadcast signal of another physical channel, And receives it from any one of the other broadcasting network and the bidirectional channel. The received SG is output to the ALC / LCT handler 2148 or output to the SG handler 2165.

The process of receiving the corresponding SG using the SG bootstrapping information is described in detail with reference to FIGS. 16 to 23, and will not be described here.

Information parsed from the SMT is also collected by the service manager 2122 and stored in the first storage unit 2124. The service manager 2122 stores the information extracted from the SMT in the first storage unit 2124 in the form of a service map and guide data.

That is, the service manager 2122 configures a service map using the signaling information collected from the FIC handler 2121 and the service signaling handler 2123, and transmits the service guide (service guide) SG) to create a program guide. The baseband controller 2119 controls the baseband controller 2119 so that the user can receive a desired mobile service by referring to the service map and the created service guide. Also, the program guide is displayed on at least a part of the screen .

The first storage unit 2124 stores a service map and a service guide created in the service manager 2122. Data stored in the first storage unit 2124 is extracted and transmitted to the service manager 2122 and / or the EPG manager 2171 at the request of the service manager 2122 and the EPG manager 2171.

The baseband controller 2119 receives M / H frame time information, existence of a data group of a selected parade, location information of known data in a data group, power control information, and the like, by receiving known data location information and TPC data To the respective blocks of the baseband processor 2110. A detailed description of the TPC data will be given later.

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

The primary RS frame decoder 2116 receives the output of the block decoder 2115 as an input. In this case, the primary RS frame decoder 2116 receives Reed Solomon (RS) encoded and / or CRC (Cyclic Redundancy Check) encoded mobile service data from the block decoder 2115 as an example. The primary RS frame decoder 2116 can receive Reed Solomon (RS) and / or CRC (Cyclic Redundancy Check) encoded SMT, GAT section data, or SG data from the block decoder 2115.

The primary RS frame decoder 2116 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 2116 collects a plurality of data groups to form a primary RS frame, and then performs error correction on a primary RS frame basis. In other words, the primary RS frame decoder 2116 decodes the primary RS frame transmitted for an actual broadcast service or the like. The primary RS frame decoded by the primary RS frame decoder 2116 is output to the primary RS frame buffer 2131. The primary RS frame buffer 2131 buffers the primary RS frame, forms an M / H TP for each row, and outputs the M / H TP to the TP handler 2133.

The secondary RS frame decoder 2117 receives the output of the block decoder 2115 as an input. In this case, the secondary RS frame decoder 2117 also receives RS (Reed Solomon) encoded and / or CRC (Cyclic Redundancy Check) encoded mobile service data from the block decoder 2115. The secondary RS frame decoder 2117 can receive an SMT section, GAT section data, or SG data encoded by RS (Reed Solomon) encoding and / or CRC (Cyclic Redundancy Check) from the block decoder 2115.

The secondary RS frame decoder 2117 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the secondary RS frame. That is, the secondary RS frame decoder 2117 collects a plurality of data groups to form a secondary RS frame, and then performs error correction on a secondary RS frame basis. In other words, the secondary RS frame decoder 2117 decodes a secondary RS frame transmitted for mobile audio service data, mobile video service data, guide data, and the like. The data of the secondary RS frame decoded by the secondary RS frame decoder 2117 is output to the secondary RS frame buffer 2132. The secondary RS frame buffer 2132 buffers the secondary RS frame, forms an M / H TP for each row, and outputs the M / H TP to the TP handler 2133.

The TP handler 2133 includes a TP buffer and a TP parser. The TP handler 2133 buffers the M / H TPs received from the primary and secondary RS frame buffers 2131 and 2132, And restores the IP datagram from the payload of the corresponding M / H TP. The restored IP datagram is output to the IP datagram handler 2141.

The IP datagram handler 2141 includes an IP datagram buffer and an IP datagram parser. The IP datagram handler 2141 buffers the IP datagram received from the TP handler 2133, extracts a header of the buffered IP datagram, And restores the UDP datagram from the payload of the IP datagram. The restored UDP datagram is output to the UDP datagram handler 2143.

If the UDP datagram is scrambled, the scrambled IP datagram is descrambled by the descrambler 2142 and output to the UDP datagram handler 2143. For example, when scrambling is applied to a UDP datagram among the received IP datagrams, the descrambler 2142 receives an encryption key and the like from the service protection stream handler 2146, And outputs it to the UDP datagram handler 2143 after scrambling.

The UDP datagram handler 2143 comprises a UDP datagram buffer and a UDP datagram parser. The UDP datagram handler 2141 buffers a UDP datagram input from the IP datagram handler 2141 or the descrambler 2142, Extracts and analyzes the header of the datagram and restores the data transmitted to the payload of the corresponding UDP datagram. If the restored data is an RTP / RTCP datagram, the RTP / RTCP datagram handler 2144 outputs the restored data. If the restored data is an NTP datagram, the NTP datagram is output to the NTP handler 2145. And outputs the restored data to the service protection stream handler 2146 if the restored data is a service protection stream and to the ALC / LCT stream handler 2148 if it is an ALC / LCT stream. And outputs the restored data to the service signaling section handler 2123 if the restored data is SMT section data.

Since the SMT section or the service signaling channel transmitting the SMT section is an IP datagram having a well-known IP desination address and a well-known des- pination UDP port number, the IP datagram handler 2141 and the UDP datagram handler 2143 May output the data including the SMT section to the service signaling section handler 2123 without requiring any additional information.

The RTP / RTCP datagram handler 2144 comprises an RTP / RTCP datagram buffer and an RTP / RTCP datagram parser. The RTP / RTCP datagram handler 2144 buffers data of the RTP / RTCP structure output from the UDP datagram handler 2143, Extracts the audio / video stream from the buffered data. The extracted audio / video stream is output to an audio / video (A / V) decoder 2161. The A / V decoder 2161 decodes the audio stream and the video stream output from the RTP / RTCP datagram handler 2144 using respective decoding algorithms, and outputs the decoded audio stream and the video stream to the presentation manager 2170. For example, the audio decoding algorithm may be an audio decoding algorithm such as an AC-3 decoding algorithm, an MPEG 2 audio decoding algorithm, an MPEG 4 audio decoding algorithm, an AAC decoding algorithm, an AAC + decoding algorithm, a HE AAC decoding algorithm, an AAC SBR decoding algorithm, And the video decoding algorithm may apply at least one of an MPEG 2 video decoding algorithm, an MPEG 4 video decoding algorithm, an H.264 decoding algorithm, an SVC decoding algorithm, and a VC-1 decoding algorithm.

The NTP datagram handler 2145 comprises an NTP datagram buffer and an NTP datagram parser. The NTP datagram handler 2145 buffers data of the NTP structure output from the UDP datagram handler 2143 and extracts an NTP stream from the buffered data. do. The extracted NTP stream is output to the A / V decoder 2161 and decoded.

The service protection stream handler 2146 may further include a service protection stream buffer for buffering data for service protection output from the UDP datagram handler 2143 and for descrambling information from the buffered data, . The information for descrambling includes a key value for descrambling such as SKTM, LKTM, and the like. The information for descrambling is stored in the second storage unit 2147 and is output to the descrambler 2142 if necessary.

The ALC / LCT stream handler 2148 comprises an ALC / LCT stream buffer and an ALC / LCT stream parser. The ALC / LCT stream handler 2148 buffers data of the ALC / LCT structure output from the UDP datagram handler 2143, And analyzes the header and header extension of the ALC / LCT session. As a result of analyzing the header and header extension of the ALC / LCT session, if the data to be the ALC / LCT session is an XML structure, the parser 2150 outputs the data to the XML parser 2150.

At this time, if the data transmitted in the ALC / LCT session is compressed, the compressed data is released from the decompressor 2149 and output to the XML parser 2150 or the file decoder 2162.

The XML parser 2150 analyzes the XML data transmitted through the ALC / LCT session and outputs the parsed data to the FDT handler 2151 if the analyzed data is data for a file-based service. If the analyzed data is data for a service guide, (2165).

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

The SG handler 2165 collects and analyzes data for a service guide transmitted in an XML structure, and outputs the collected data to the service manager 2122.

The file decoder 2162 decodes the file structure data transmitted through the ALC / LCT session and outputs the decoded data to the middleware engine 2164 or the third storage unit 2163.

The middleware engine 2164 interprets and executes the data of the file structure, that is, the application. The application may be output to an output device such as a screen or a speaker through the presentation manager 2170. The middleware engine 2164 is a Java (JAVA) based middleware engine.

The EPG manager 2171 receives EPG data from the service manager 2122 or the SG handler 2165 according to an input from the user, converts the EPG data into a display format, and outputs the EPG data to the presentation manager 2170.

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

The operation controller 2100 controls at least one of the service manager 2122, the EPG manager 2171, the application manager 2172, and the presentation manager 2170 according to a user command inputted through the UI manager 2173 So that the function according to the command of the user is performed.

The UI manager 2173 transfers the user's input to the operation controller 2100 through the UI.

The presentation manager 2170 may output at least one of audio and video data output from the A / V decoder 2161, file data output from the middleware engine 2164, and EPG data output from the EPG manager 2171, / Or provide it to the user via the screen.

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

Claims (10)

Comprising the steps of: Forward Error Correction (FEC) encoding data of data packets including at least broadcast data or signaling data;
First encoding transmission parameters including physical layer information;
Encoding the first encoded transmission parameters; And
And transmitting a broadcast signal including the FEC encoded data and the second encoded transmission parameters,
Wherein the signaling data comprises first signaling data and second signaling data,
Wherein the service guide information is transmitted through at least one of a broadcasting network and a communication network,
Wherein when the service guide information is transmitted as a service through the broadcasting network, the first signaling data includes a first service identifier for identifying the service, and the second signaling data includes the same value as the first service identifier A second service identifier and access information for accessing the service,
Wherein the first signaling data includes service guide bootstrapping information when the service guide information is transmitted through the communication network and the service guide bootstrapping information includes unified resource information for obtaining the service guide information, And transmitting the data to the transmitter.
The method according to claim 1,
Wherein the address information and the port information for accessing the first signaling data are well known.
The method according to claim 1,
Wherein at least one of the first signaling data and the second signaling data further includes a transmission session identifier for identifying a session for transmitting the service guide information.
The method according to claim 1,
Wherein the access information for accessing the service includes at least source address information or destination address information.
The method according to claim 1,
Wherein the first signaling data further comprises provider information related to the service.
A first encoding unit that FEC-encodes data of data packets including at least broadcast data or signaling data;
A second encoding unit for first encoding transmission parameters including physical layer information;
A third encoding unit that encodes the first encoded transmission parameters; And
And a transmitter for transmitting a broadcast signal including the FEC encoded data and the second encoded transmission parameters,
Wherein the signaling data comprises first signaling data and second signaling data,
Wherein the service guide information is transmitted through at least one of a broadcasting network and a communication network,
Wherein when the service guide information is transmitted as a service through the broadcasting network, the first signaling data includes a first service identifier for identifying the service, and the second signaling data includes the same value as the first service identifier A second service identifier and access information for accessing the service,
Wherein when the service guide information is transmitted through the communication network, the first signaling data includes service guide bootstrapping information, and the service guide bootstrapping information includes integrated resource information for obtaining the service guide information .
The method according to claim 6,
Wherein address information and port information for accessing the first signaling data are known in advance.
The method according to claim 6,
Wherein at least one of the first signaling data and the second signaling data further comprises a transmission session identifier for identifying a session for transmitting the service guide information.
The method according to claim 6,
Wherein the access information for accessing the service includes at least source address information or destination address information.
The method according to claim 6,
Wherein the first signaling data further comprises provider information related to the service.

Images