KR101581359B1 - method of receiving a broadcasting signal and receiving system for receiving a broadcasting signal - Google Patents

Abstract

A broadcast signal receiving method and a receiving system are disclosed. The receiving system may include a first processing unit, a second processing unit, and a storage medium. The first processing unit receives and processes a signaling table including first signaling information including access information of non-real-time service data and second signaling information including information about media object of the non-real-time service data. The second processing unit receives the non-real-time service data based on the connection information and the media object related information processed in the first processing unit, and processes the file including the received non-real-time service data. The storage medium stores a file of the processed non-real-time service data.

Non real-time, real-time, signaling, table

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention [0001] The present invention relates to a broadcast signal receiving method and a broadcast signal receiving method,

The present invention relates to a method and a device for receiving a broadcast signal transmitted in real time and a broadcast signal transmitted in non-real time.

Digital television (DTV) has been able to provide a variety of services in addition to video and audio, which are unique functions of television (TV). For example, it is possible to provide an electronic program guide (EPG) or the like to a user, and to simultaneously provide a broadcast service received from two or more channels. In particular, the number of services that a receiving system can provide using broadcast signals is increasing, in connection with an Internet or data communication channel capable of bi-directional communication with a large-capacity storage device.

In such an environment, a broadcasting signal transmitting / receiving method combining a real time broadcasting service with a non-real time broadcasting service and a receiving system capable of realizing the same have been developed.

An object of the present invention is to provide a broadcasting signal receiving method and a receiving system capable of efficiently combining a real-time broadcasting service and a non-real-time broadcasting service.

It is another object of the present invention to provide a broadcasting signal receiving method and a receiving system for enabling reception of an IP-based non-real-time service in an MPEG-2 based broadcasting system.

It is still another object of the present invention to provide a broadcasting signal receiving method and system for signaling an IP-based non-real-time service access method for receiving an IP-based non-real-time service in an MPEG-2 based broadcasting system.

According to an aspect of the present invention, there is provided a broadcast signal receiving method including receiving first signaling information including access information of non-real-time service data and processing the first signaling information; Receiving and processing second signaling information including media object association information of the non-real-time service data; Receiving the non-real-time service data based on the access information included in the first signaling information; And processing the received non-real-time service data according to the media object association information included in the second signaling information.

The first signaling information and the second signaling information are received in a signaling table for a non-real time (NRT) service.

The media object association information includes at least one of container information of the NRT service data, encoding information, and decoding parameters of a file constituting the NRT service.

The media object association information is provided in a text form using at least one field of the descriptor received in the signaling table.

The media object association information is provided in the form of a stream or a file, and the descriptor includes connection information of the stream or file.

If the media object related information is provided in the form of a file, the descriptor is further received with a parameter including an identifier of a FLUTE session for transmitting the file and time information.

If the NRT service is a Fiexed NRT service, the file configuring the NRT service and the signaling table are received after IP packetization, addressable section packetization, and MPEG-2 TS packetization are sequentially performed.

If the NRT service is a mobile NRT service, the file constituting the NRT service and the signaling table are IP packetized and received in one ensemble.

A receiving system according to an embodiment of the present invention may include a first processing unit, a second processing unit, and a storage medium. The first processing unit receives and processes a signaling table including first signaling information including access information of non-real-time service data and second signaling information including information about media object of the non-real-time service data. The second processing unit receives the non-real-time service data based on the connection information and the media object related information processed in the first processing unit, and processes the file including the received non-real-time service data. The storage medium stores a file of the processed non-real-time service data.

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

The method and system for receiving a broadcast signal according to the present invention can efficiently combine a real-time broadcast service and a non-real-time broadcast service.

In addition, the present invention can provide access information for the FLUTE session at the IP level for the fixed NRT service and the mobile NRT service. Information necessary for rendering a component / file of the NRT service transmitted through the FLUTE session may be provided through an IP-based signaling information channel.

Also, in the receiving system according to the present invention, it is possible to receive information essential for rendering a component / file of the NRT service, and determine whether to process the corresponding NRT service according to the received information. That is, if the received information has information that can not be processed by the receiving system, for example, if the receiving system does not have a codec capable of decoding the NRT service, the corresponding NRT service is ignored rather than being processed.

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

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.

The present invention enables a broadcasting service to be received in non-real time (NRT) through a medium such as a terrestrial wave or a cable. For convenience of description, the present invention is referred to as NRT service, and the broadcast service data at this time is referred to as NRT service data.

The received NRT service data is stored in a storage medium and then displayed on a display device according to a predetermined time or a user's request. The NRT service data is received in a file form and stored in a storage medium. The storage medium is an internal HDD mounted inside the broadcast receiving apparatus. As another example, the storage medium may be a universal serial bus (USB) memory connected to the outside of the broadcast receiving apparatus, an external HDD, or the like.

Signaling information is required to receive the files constituting the NRT service and store the received files in a storage medium. The present invention is referred to as NRT service signaling information or NRT service signaling data.

The NRT service according to the present invention can largely be divided into a fixed NRT service and a mobile NRT service. In the present invention, the Fixed NRT service will first be described, and then the Mobile NRT service will be described.

Fixed NRT  service

In the present invention, for the Fixed NRT service, the NRT service of the file type is IP packetized in the IP layer and then transmitted in the form of MPEG-2 TS through a specific virtual channel.

In the present invention, the presence or absence of an NRT service in a virtual channel through a virtual channel table (VCT), for example, a PSI (Program Specific Information) / PSIP (Program and System Information Protocol) table based on MPEG- And signaling the identification information of the NRT service.

The present invention is characterized in that an NRT service signaling channel for transmitting NRT service signaling data for signaling access information of an IP-based NRT service is IP-packetized from a IP layer to a specific IP stream and then transmitted in the form of MPEG-2 TS .

1 discloses a concept of providing a real-time (RT) service and a non-real-time (NRT) service.

The non-real-time service is a service that receives and stores NRT service data transmitted in non-real-time using an extra bandwidth among some broadcast channels, particularly broadcast channels, and provides the NRT service data to a user when necessary, . Therefore, the NRT service is mainly used for post-storage reproduction rather than real-time viewing.

The real-time service is a broadcasting service that receives broadcast service data in real time as in the current terrestrial broadcast and provides it to the user.

For example, a broadcasting station can transmit broadcasting service data in real time and transmit news clips, weather information, advertisements, Push VOD, etc. in non-real time. In addition, the NRT service may be specific scenes of a real-time broadcast stream, as well as news clips, weather information, advertisements, Push VODs.

Conventional broadcast receivers (i.e., legacy devices) can receive and process real-time services, but can not receive and process non-real-time services.

A broadcast receiver (i.e., an NRT device) according to the present invention can provide various services by combining a non-real-time service and a real-time service.

As shown in FIG. 2, one NRT service according to the present invention includes one or more content (or NRT content), and one content includes one or more files. In the present invention, files and objects are used in the same sense.

The NRT content is a minimum unit that can be independently reproduced. For example, when there is news provided in non-real time, and the news includes economic news, political news, and daily news, the news may be called NRT service, and economic news, political news, NRT content. And, each of economic news, political news, and daily news consists of at least one file.

At this time, the NRT service can be transmitted in the form of an MPEG-2 transport stream (TS) packet through the same broadcast channel or dedicated broadcast channel as the RT service. In this case, a unique PID is assigned and transmitted to the TS packet of the NRT service data to identify the NRT service. The present invention is one embodiment in which IP-based NRT service data is transmitted as an MPEG-2 TS packetized.

At this time, the NRT service signaling data required to receive the NRT service data is transmitted through the NRT service signaling channel. The NRT service signaling channel is transmitted over a specific IP stream on the IP layer, and the IP stream is also transmitted as an MPEG-2 TS packet. The NRT service signaling data transmitted on the NRT service signaling channel provides access information of NRT services driven in the IP layer.

That is, the broadcasting station packetizes the NRT contents / files according to the file transfer protocol and packetizes them according to the ALC / LCT (Asynchronous Layered Coding / Layered Coding Transport) method as shown in FIG. The packetized ALC / LCT data is again packetized according to the UDP scheme, and the packetized ALC / LCT / UDP data is again packetized according to the IP scheme to become ALC / LCT / UDP / IP data. The packetized ALC / LCT / UDP / IP data is referred to as an IP datagram in the present invention for convenience of explanation.

The NRT service signaling channel required for receiving the NRT content / files is transmitted through an NRT service signaling channel. The NRT service signaling channel is packetized according to a UDP (User Datagram Protocol) scheme, and the packetized UDP data Is packetized into UDP / IP data again according to the IP method. The UDP / IP data is also referred to as an IP datagram in the present invention for convenience of explanation. At this time, the NRT service signaling channel is encapsulated in an IP datagram having a well-known IP des- nation address and a well-known des- pination UDP port number, and is multicast.

In the present invention, the IP datagrams of the NRT service and the NRT service signaling channel are encapsulated into addressable section structures, and packetized into an MPEG-2 TS format. That is, one addressable section structure has a form in which an IP datagram is additionally provided with a section header and a CRC checksum. The format of the addressable section structure conforms to the Digital Storage Media Command and Control (DSM-CC) section format for private data transmission. Therefore, the addressable section may be referred to as a DSM-CC addressable section. When dividing the addressable section data into 184-byte units and adding 4-byte MPEG headers to 184 bytes, 188-byte MPEG-2 TS packets can be created. At this time, the value assigned to the PID of the MPEG header is a unique value that can identify the TS packet transmitting the NRT service and the NRT service signaling channel.

PSI (Program Specific Information) and PSIP (Program and System Information Protocol) table section data are also MPEG-2 TS packetized.

The PSI table includes, for example, a virtual channel table (VCT), a system time table (STT), a radio resource control table (RRT) (DCT), Direct Channel Change Selection Code Table (DCCSCT), Event Information Table (EIT), and Master Guide Table (MGT) .

The MPEG-2 TS packets are modulated by a transmission scheme (for example, VSB transmission scheme) predetermined in the physical layer and transmitted to the reception system.

In the present invention, signaling through the PSI / PSIP table is performed to determine whether or not the NRT service is transmitted. For example, signaling the transmission of the NRT service to the virtual channel table (VCT) is an embodiment.

FIG. 4 shows an embodiment of the syntax structure of the virtual channel table (VCT) section.

The VCT section transmits information on a virtual channel, for example, channel information for channel selection and packet identifier (PID) for audio and / or video reception. That is, when the VCT section is parsed, the PID of the audio and video of the broadcast program loaded in the channel together with the channel name, the channel number, and the like can be known.

The syntax of the VCT section includes at least one of a table_id field, a section_syntax_indicator field, a private_indicator field, a section_length field, a transport_stream_id field, a version_number field, a current_next_indicator field, a section_number field, a last_section_number field, a protocol_version field and a num_channels_in_section field.

The syntax of the VCT section further includes a first loop of a 'for' loop (ie, a virtual channel loop) in which the num_channels_in_section field value is repeated. In the first loop, a short_name field, a major_channel_number field, a minor_channel_number field, , a carrier_frequency field, a channel_TSID field, a program_number field, an ETM_location field, an access_controlled field, a hidden field, a service_type field, a source_id field, a descriptor_length field, Or the like. In the present invention, the second loop is referred to as a first descriptor loop for convenience of explanation. Descriptors descriptors () included in the first descriptor loop are descriptors individually applied to each virtual channel.

The VCT section syntax may further include an additional_descriptor_length field and a third loop composed of 'for' loops repeated for the number of descriptors added to the VCT section. In the present invention, the third loop is referred to as a second descriptor loop for convenience of explanation. The descriptor additional_descriptors () included in the second descriptor loop is a descriptor commonly applied to all virtual channels described in the VCT section.

4, the table_id field indicates a unique identifier (ID) for recognizing that information transmitted to the table is a VCT. That is, the table_id field indicates a value indicating that the table to which this section belongs is a VCT, and may be assigned, for example, 0xC8.

The version_number field indicates the version value of the VCT, the section_number field indicates the number of this section, and the last_section_number field indicates the number of the last section of the complete VCT. The num_channels_in_section field specifies the total number of virtual channels in the VCT section.

The short_name field in the first loop of the 'for' loop indicates a virtual channel name, the major_channel_number field indicates a 'major' channel number associated with a virtual channel defined in the first loop, the minor_channel_number field indicates' Minor 'channel number. That is, each virtual channel number should be connected to the major and minor channel numbers, and the major and minor channel numbers serve as user reference numbers for the corresponding virtual channel.

The program_number field is used to connect an MPEG-2 PAT (Program Association Table) and a virtual channel defined by a PMT (Program Map Table), and coincides with a program number in the PAT / PMT. Here, the PAT describes the components of the program for each program number, and indicates the PID of the transport packet for transmitting the PMT. The PMT describes a program identification number and a PID list and associated information of a transport packet in which individual bit strings such as video and audio constituting a program are transmitted.

The service_type field indicates a service type in the virtual channel.

In one embodiment, the virtual channel may include both at least one RT service including audio and / or video and at least one NRT service.

In this case, a service type value may be allocated as shown in FIG. 5, and an NRT service may be transmitted to the virtual channel using 0x04 indicating an ATSC data only service.

In another embodiment, the virtual channel may include only one or more NRT services. In this case, as shown in FIG. 6, 0x05 is newly defined as the service_type field value, and the NRT service can be indicated to be transmitted to the virtual channel.

The source_id field indicates a program source connected to the virtual channel.

Here, a source refers to one specific source such as video, text, data, or sound. The source_id field value has a unique value in the transport stream for transmitting the VCT.

On the other hand, the descriptor loop (descriptor {}) within the loop of the next 'for' loop may contain a service location descriptor.

The service location descriptor may include a stream type, an elementary_PID, and a language code field for each elementary stream.

7 shows an embodiment of a syntax structure of an NRT service descriptor (NRT_service_descriptor ()) included in the first descriptor loop of the VCT when the service_type field indicates that the NRT service is transmitted to the corresponding virtual channel .

The NRT service descriptor (NRT_service_descriptor ()) is applied only to the corresponding virtual channel, and provides identification information of NRT services included in the corresponding virtual channel.

In Fig. 7, the descriptor_tag field is a descriptor identifier, and an identifier that identifies the NRT service descriptor may be set.

The descriptor_length field indicates the remaining length of the descriptor in bytes after the descriptor_length field to the end of the descriptor.

The num_NRT_services field may allocate 8 bits in one embodiment and indicates the number of NRT services included in the virtual channel. Then, a 'for' loop is performed for the number of NRT services corresponding to the value of the num_NRT_services field to display identification information of each NRT service included in the virtual channel. That is, the 'for' loop may include an NRT_service_id field, an NRT_service_short_name field, an NRT_service_category field, and an NRT_service_status field.

In the NRT_service_id field, 16 bits are allocated to the NRT_service_id field, and a value capable of uniquely identifying the corresponding NRT service in the virtual channel is displayed (A 16-bit unsigned integer number, which will uniquely identify the NRT service within the scope of this virtual channel.).

The NRT_service_short_name field indicates a short name of the NRT service. If there is no short name of the NRT service, the field may be filled with a null value.

The NRT_service_category field allocates 5 bits in one embodiment and indicates a service type transmitted from the NRT service.

The NRT_service_status field allocates 2 bits in one embodiment and indicates the state of the NRT service. For example, if the upper bit of the NRT_service_status field value is set to 1, the corresponding NRT service is in an active state, and if it is set to 0, it is inactive. If the lower bit of the NRT_service_status field value is set to 1, the corresponding NRT service is in a hidden state. If it is set to 0, it indicates that the NRT service is not in a hidden state. or inactive (when set to 0) and the least significant bit at least NRT service is hidden (when set to 1) or not (when set to 0).

8 is a flowchart illustrating a method of receiving and servicing an NRT service using an ATSC A / 92 standard for transmitting an ATSC A / 90 standard and an IP multicast stream for transmitting a data broadcast stream in a receiving system according to the present invention. .

That is, the information of the stream constituting each virtual channel is signaled to the service location descriptor of the VCT or the ES_loop of the PMT. For example, when the service type of the VCT is 0x02 (i.e., digital A / V / Data) or 0x04 (i.e., Data only) or 0x05 (i.e., NRT Only) service, the NRT service stream may be transmitted to the virtual channel. At this time, if 0x95 (i.e., DST transmission) is assigned to the stream_type field value included in the service location descriptor of the VCT (or the ES loop of the PMT), data broadcasting is transmitted. If the stream_type field value does not exist or is not 0x95, only the general A / V is transmitted. That is, if the stream_type field value included in the service location descripter indicates 0x95, the Elementary_PID field value at this time is the PID value of the DST (Data Service Table). Therefore, the DST can be received through the Elementary_PID.

Through the DST, the type of the application and the detailed information of the data broadcast stream transmitted through the channel can be known. In the present invention, an NRT application (i.e., an NRT service) is identified using DST.

That is, the App_id_description field of the DST specifies the format and interpretation of the following application identification bytes. The present invention assigns '0x0003' to the App_id_description field to identify the NRT application. The numerical values shown above are only examples, and the numerical values do not limit the scope of the present invention.

If the value of the App_id_description field is '0x0003', the next Application_id_byte value becomes the Service ID value of the NRT application. The service ID for the NRT application may have a URI value for globally and uniquely identifying the service.

After identifying the NRT application as described above, the PID of the MPEG-2 TS packet segmented from the IP datagram of the NRT service signaling channel is searched through the Tap information. Then, an IP datagram transmitting the NRT service signaling channel can be obtained from the MPEG-2 TS packets having the PID found through the tap information, and the NRT service signaling data can be obtained from the obtained IP datagram . The IP connection information of the NRT service signaling channel may be well-known IP connection information, that is, a well-known IP address and a well-known UDP port number.

That is, if the Protocol_encapsulation field value is 0x04 in the DST, the asynchronous IP stream is transmitted. If the Selector_type field value is 0x0102, the device_id value indicating the destination address is transmitted through selector_bytes. A multiprotocol_encaplsulation_descriptor is used to correctly interpret the selector_bytes value, and signals the number of valid bytes in the device_id value. As a result, the IP multicast address (or address range) of the NRT service signaling channel transmitted through the corresponding PID can be known through the Tap information.

Therefore, it connects to the IP multicast address (or address range) to receive the IP stream, that is, the IP packet, and extracts the NRT service signaling data from the received IP packet.

Based on the extracted NRT service signaling data, NRT service data, i.e. NRT content / files, can be received and stored in a storage medium or displayed on a display device.

In another embodiment of the present invention, the NRT service can be signaled using a new value, for example, 0x96, instead of 0x95 in the stream type field value of the DST. This is because, if the existing receiver operates only by determining whether the stream of the data broadcasting stream exists or not in the stream having the stream type of 0x95, there is a possibility of malfunctioning of the NRT service as a new application. In this case, by specifying a stream type newly, existing receivers can be ignored, thereby ensuring backward compatibility.

Meanwhile, the NRT service signaling data transmitted through the NRT service signaling channel includes an NRT service map table (Service Map Table or NST) for providing NRT service access information. The NST has a table format similar to the MPEG-2 Private section format.

The NST can provide connection information of IP-based NRT services included in one virtual channel. For example, the NST may provide connection information of each FLUTE session constituting one NRT service.

In addition, the NST can provide information necessary for rendering the content / files of the NRT service transmitted through the FLUTE session. In one embodiment, the NST may provide container information needed to render the content / files transmitted in each FLUTE session. In another embodiment, the NST may provide the encoding information (e.g., media / codec type) needed to render the content / files transmitted in each FLUTE session. The NST may provide a decoding parameter of the media required to render the content / files transmitted in each FLUTE session.

The NRT service signaling data may further include a signaling table other than the NST. In this case, the IP datagrams of the NRT service signaling channel have the same well-known IP address and a well-known UDP port number. Therefore, the NST included in the NRT service signaling data is distinguished 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.

At this time, whether a single NST is composed of one section or a plurality of sections can be known through a table_id field, a section_number field, a last_section_number field and the like in the NST section. After removing the IP header and the UDP header of the IP datagrams of the NRT service signaling channel, the corresponding tables can be completed by collecting sections having the same table identifier. For example, NST can be completed by gathering sections with table identifiers assigned to the NST.

9 is a diagram illustrating an embodiment of a bitstream syntax structure for an NST section according to the present invention. A detailed description of each field of the NST section is as follows.

In Fig. 9, the table_id field (8 bits) is an identifier of the table, and an identifier for identifying the NST may be set. One example is to assign 0xDF to the table_id field to identify the NST.

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

The private_indicator field (1 bit) indicates whether the NST complies with a private section.

The section_length field (12 bits) indicates the section length of the NST.

The NST can be used as one of the table identifiers for allocating a 16-bit source_id field to the table_id_extension field position and distinguishing the NST when the NST is received on the NRT service signaling channel.

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

The current_next_indicator field (1 bit) indicates whether the information included in the NST section is currently applicable information or future applicable information.

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

The last_section_number field (8 bits) indicates the last section number of the NST.

The NST_protocol_version field (8 bits) tells the protocol version to allow the NST to transmit parameters with different structures than those defined in the current protocol (An 8-bit unsigned integer field whose function is to allow for the future, NST_protocol_version NST_protocol_version may be used for a future version of this standard. This NRT Service Map may be used to define the NST_protocol_version. indicate structurally different tables.)

The transport_stream_id field (16 bits) indicates a unique identifier of a broadcast stream to which the corresponding NST section is being transmitted.

The Num_NRT_services field (8 bits) indicates the number of NRT services included in the NRT section (This 8 bit field shall specify the number of NRT Services in this NST section.).

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

That is, the NRT_service_id field (16 bits) indicates a value that can uniquely identify the corresponding NRT service (A 16-bit unsigned integer number, which will uniquely identify this NRT service within the scope of this NRT section). The value of the NRT_service_id field of one service does not change while the service is maintained. In order to avoid confusion at this time, if a certain service is terminated, the value of the NRT_service_id field of the service may not be used until a predetermined time elapses (The NRT_service_id of a service shall not change throughout the life of the service. , it is recommended that a service is terminated, then the NRT_service_id for the service should not be used for another service until after a suitable interval of time has elapsed.).

The NRT_service_category field (5 bits) indicates the service type of the corresponding NRT service.

The NRT_service_status field (2 bits) indicates the state of the corresponding NRT service. For example, if the upper bit of the NRT_service_status field value is set to 1, the corresponding NRT service is in an active state, and if it is set to 0, it is inactive. If the lower bit of the NRT_service_status field value is set to 1, the corresponding NRT service is in a hidden state. If it is set to 0, it indicates that the NRT service is not in a hidden state. or inactive (when set to 0) and the least significant bit at least NRT service is hidden (when set to 1) or not (when set to 0).

The SP_indicator field (1 bit) indicates whether the corresponding NRT service is service protection. 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 corresponding NRT service (see (1-bit field that indicates, when set to 1, service protection is applied to at least one of the components needed to provide a meaningful presentation of this NRT Service).

The Short_NRT_service_name field (8 * 8 bits) indicates the short name of the NRT service. If there is no short name of the NRT service, the field may be filled with a null value (e.g., 0x00).

The num_FLUTE_sessions field (8 bits) indicates the number of FLUTE sessions constituting the NRT service.

Then, a 'for' loop (or a FLUTE session loop) is performed for the number of FLUTE sessions corresponding to the value of the num_FLUTE_sessions field to provide access information for a plurality of FLUTE sessions. That is, the access information of the corresponding FLUTE session is provided for each FLUTE session included in the NRT service. At this time, the following field information can be provided for each FLUTE session.

The FLUTE_session_type field (3 bits) identifies the type of FLUTE session according to the data objects transmitted in the FLUTE session. The assignment of the FLUTE_session_type field value and its meaning are shown in FIG. For example, if the value of the FLUTE_session_type field is 000, the corresponding FLUTE session indicates a FLUTE file delivery session for transmitting the content / file for the actual NRT service. The remaining values are not used in the present invention. That is, when the value of the FLUTE_session_type field is 000, the FLUTE file delivery descriptor (NRT_FLUTE_File_Delivery_descriptor ()) as shown in FIG. 11 is transmitted as FLUTE_session_level_descriptor (). The field descriptions of the FLUTE file delivery descriptor will be described later.

The media_object_association_indicator field (1 bit) indicates whether or not media object related information related to the FLUTE session exists. For example, when the media_object_association_indicator field is set to 1, it indicates that there is a descriptor (e.g., NRT_media_object_association_descriptor ()) related to the FLUTE session or media object related information provided in a stream or a file (This 1- (or a file or a file) that is associated with the FLUTE session, by the media_object_association_descriptor (). That is, if the field is 1, an NRT_media_object_association_descriptor () is included in a FLUTE session loop and is received. At this time, the media_object_association_indicator field may be omitted in the NST. In this case, if media object related information exists, NRT_media_object_association_descriptor () is received in the FLUTE session level descriptor. The receiver parses all the descriptors included in the FLUTE session level descriptor, and identifies the NRT_media_object_association_descriptor () using the identifier of the descriptor.

When the essential_component_delivery_indicator field (1 bit) is set to '1', it indicates that the corresponding FLUTE session transmits a necessary component (i.e., content / file) for the NRT service. Otherwise, this field indicates that the component (i. E., Content / file) transmitted via the corresponding FLUTE session is an optional component. (A one-bit indicator, when set, indicates that this FLUTE session carries an essential component for the NRT service. Otherwise, this field indicates that the components are carried through this FLUTE session is optional components.

When the IP_version_flag field (1 bit) is set to '0', it indicates that the FLUTE_session_source_IP_address and FLUTE_session_destination_IP_address fields are IPv4 addresses, and when set to '1', the FLUTE_session_source_IP_address and FLUTE_session_destination_IP_address fields indicate the IPv6 address When set to zero, the FLUTE_session_source_IP_address, FLUTE_session_destination_IP_address fields are IPv4 addresses. Otherwise, this field indicates that FLUTE_session_source_IP_address, FLUTE_session_destination_IP_address fields are IPv6 addresses.

If the source_specific_multicast_flag field (1 bit) is set to '1', it indicates that the source specific multicast is used for the FLUTE session. Therefore, FLUTE_session_source_IP_address must be present (A-1 bit Boolean flag, when set, when the source specific multicast is used for this FLUTE session.) Thus, the FLUTE_session_source_IP_address shall be present.

The FLUTE_session_source_IP_address field (32 or 128 bits) is present when the source_specific_multicast_flag field is set to '1', but not when the source_specific_multicast_flag field is set to '0'. If present, this field shall be the source IP address of the same server that is transmitting all the channels of the FLUTE session (this field shall be present if source_specific_multicast_flag is set to '1', and shall not be present if source_specific_multicast_flag is set to '0 'If present, this field shall contain the source IP address of the IP datagrams carrying the components of this FLUTE session.

The FLUTE_session_destination_IP_address field (32 or 128 bits) contains the destination of all IP datagrams that carry the components of the FLUTE session (this field shall contain the destination IP datagrams carrying the components of this FLUTE session. ).

The FLUTE_session_destination_UDP_port_num field (16 bits) indicates the destination UDP port number of the UDP / IP stream transmitting the FLUTE session (A 16-bit unsigned integer field, which represents the destination UDP port number for the UDP / session.).

The Num_FLUTE_session_level_descriptors field (4 bits) indicates the number of descriptors (FLUTE_session_level_descriptor ()) included in the FLUTE session loop.

The FLUTE session loops include FLUTE_session_level_descriptors () in the number corresponding to the Num_FLUTE_session_level_descriptors field value to provide additional information for the FLUTE session (one or more descriptors are provided for additional FLUTE session, may be included). .

The Num_NRT_service_level_descriptors field (4 bits) indicates the number of descriptors (NRT_service_level_descriptors ()) included in the NRT service loop.

NRT_service_level_descriptors () are included in the NRT service loop by the number corresponding to the Num_NRT_service_level_descriptors field value, thereby providing additional information on the NRT service (additional information for NRT service may be included).

FIG. 11 shows an example of a bitstream syntax structure of NRT_FLUTE_File_Delivery_descriptor () provided as FLUTE_session_level_descriptor () according to the present invention. That is, NRT_FLUTE_File_Delivery_descriptor () is used as one of FLUTE_session_level_descriptor () of NST and includes additional signaling information for accessing the corresponding FLUTE session. The NRT_FLUTE_File_Delivery_descriptor () is received as a FLUTE session level descriptor when the value of the FLUTE_session_type field is 000. The description of each field of the NRT_FLUTE_File_Delivery_descriptor () is as follows.

In Fig. 11, the descriptor_tag field (8 bits) is a descriptor identifier, and an identifier that identifies the NRT FLUTE file delivery descriptor NRT_FLUTE_File_Delivery_descriptor () can be set.

The descriptor_length field (8 bits) indicates the remaining length of the descriptor in bytes after the descriptor_length field to the end of the descriptor.

The FLUTE_session_TSI field (16 bits) indicates the TSI of the FLUTE session. That is, the TSI is an identifier that uniquely identifies the FLUTE session (A 16-bit unsigned integer field, which will be the TSI of the FLUTE session).

The session_start_time field (16 bits) indicates the time at which the FLUTE session starts. If the value of the corresponding field is all '0', the FLUTE session can be interpreted as already started (session_start_time: The time at which the FLUTE session starts. If the value of this field is set to all zero, then it shall be interpreted to mean that the session has already started).

The session_end_time field (16 bits) indicates the time at which the FLUTE session ends. If the value of the corresponding field is all '0', the FLUTE session can be interpreted as continuing indefinitely (session_end_time: The time at which the FLUTE session ends. If the value of this field is set to all zero, then it shall be interpreted to mean that the session continues indefinitely.

The tias_bandwidth_indicator field (1 bit) indicates whether to include Transport Independent Application Specific (TIAS) bandwidth information. To indicate that the TIAS bandwidth field is present, the corresponding bit shall be set to '1' and the corresponding bit shall be set to '0' to indicate that the TIAS bandwidth field does not exist (A 1-bit field that flags the The inclusion of TIAS bandwidth information. This bit shall be set to '1' to indicate the TIAS bandwidth field is present, and it shall be set to '0' to indicate the TIAS bandwidth field is absent.

The as_bandwidth_indicator field (1 bit) indicates whether or not application specific (AS) bandwidth information is included. To indicate that the AS bandwidth field is present, the corresponding bit shall be set to '1' and to indicate that the AS bandwidth field does not exist, the corresponding bit shall be set to '0' (A 1-bit field that flags The inclusion of AS bandwidth information shall indicate that the AS bandwidth field is present, and that it shall be set to '0' to indicate the AS bandwidth field is absent.

The FEC_OTI_indicator field (1 bit) indicates whether FEC object transmission information (OTI) is provided (A 1-bit indicator indicating whether FEC Object Transmission Information is provided).

The tias_bandwidth field (16 bits) exists when the as_bandwidth_indicator field is set to '1' and indicates the TIAS maximum bandwidth (This value shall be one to thousandth of the Transport Independent Application Specific Maximum Bandwidth as defined in RFC 3890, This is the TIAS bandwidth in kilobits per second.

The as_bandwidth field (16 bits) exists when the as_bandwidth_indicator field is set to '1' and indicates the AS maximum bandwidth (This value will be defined in RFC 4566. This gives the AS bandwidth in kilobits per second.

The FEC_encoding_id field is present when the FEC_OTI_indicator field is set to '1', and indicates the FEC encoding ID used in the corresponding FLUTE session (FEC encoding ID used in this FLUTE session, as defined in RFC 3926).

The FEC_instance_id field exists when the FEC_OTI_indicator field is set to '1', and indicates the FEC instance ID used in the corresponding FLUTE session (FEC instance ID used in this FLUTE session, as defined in RFC 3926).

By signaling the above parameters via the NRT FLUTE file delivery descriptor NRT_FLUTE_File_Delivery_descriptor () in the FLUTE session loop, it is possible to provide all the information necessary for receiving the FULTE session.

That is, the corresponding FLUTE session may be opened according to the time information set by the session_start_time field and the session_end_time field to receive the FDT (File DescriptioN Table) describing the files constituting the NRT service and the signaling information of the files.

Meanwhile, if the value of the media_object_association_indicator field is set to '1' in the NST, media object related information related to the FLUTE session is signaled using the NRT media object association descriptor. For example, the media object association information is provided in the form of a text expressed in a Multipurpose Internet Mail Extensions (MIME) type.

12 shows an embodiment of a bitstream syntax structure of an NRT media object association descriptor NRT_media_object_association_descriptor () according to the present invention. The NRT media object association descriptor is used as one of the FLUTE_session_level_descriptor () of the NST. The NRT media object association descriptor signals parameters necessary for rendering a content / file (or media object / file) transmitted through the corresponding FLUTE session.

The fields of the NRT media object association descriptor NRT_media_object_association_descriptor () are as follows.

In FIG. 12, the descriptor_tag field (8 bits) is a descriptor identifier, and an identifier for identifying the NRT media object association descriptor NRT_media_object_association_descriptor () is displayed.

The descriptor_length field (8 bits) indicates the remaining length of the descriptor in bytes after the descriptor_length field to the end of the descriptor.

The object_association_type field (3 bits) indicates how the media object related information is signaled. This 3-bit enumerated field indicates that the media object association information is signaled. In one embodiment, the media object association information may be signaled via the inline field of the descriptor in the form of a MIME type text. In another embodiment, the media object association information may be signaled via a media object association stream in the form of a MIME type text. In yet another embodiment, the media object association information may be signaled via a media object association file in the form of a MIME type text. (The media object association may be made through the in-line fields of this descriptor or may be done through the media object association stream or media object association file.

FIG. 13 shows an example of definitions of values and values assigned to the object_association_type field.

For example, if the object_association_type field value is '000', the media object related information required to render the content for transmitting the related object is provided as the inline text of the descriptor It is necessary for the rendering of the content and the associated object is carried, as provided in the text of this descriptor.

As another example, if the object_association_type field value is '001', the media object related information required to render the content transmitting the related object is provided as a separate UDP / IP stream. The UDP / IP stream transmits a data structure such as SAP / SDP. (The media object association information, which is necessary for rendering the content, is provided by a UDP / IP stream, which carries SAP / SDP like data structure.

As another example, if the object_association_type field value is '010', the media object related information required to render the content for transmitting the related object is provided as a file such as SDP. A file such as the SDP is provided through a separate FLUTE file delivery session. The media object association information, which is necessary for rendering the content, is provided by a SDP-like file, a separated FLUTE file delivery session.

Accordingly, if the object_association_type field value is '000', the media object association information is directly described using at least one field in the NRT media object association descriptor.

If the object_association_type field value is '001' or '010', the NRT media object association descriptor provides connection information of a stream or a file for transmitting the media object association information. If the object_association_type field value is '010', the NRT media object association descriptor provides not only the access information of the file, but also parameters necessary for receiving the FLUTE session for transmitting the file.

That is, if the object_association_type field value is '000', the NRT media object association descriptor includes a num_media_objects_in_session field and a for loop iteration field repeated by a number corresponding to the num_media_objects_in_session field value. The for loop loop statement may include a media_object_TOI field, an object_container_type_text_length field, an object_container_type_text () field, an object_media_type_text_length field, an object_media_type_text () field, an object_decoding_parameters_text_length field, and object_decoding_parameters_text ().

The num_media_objects_in_session field (8 bits) indicates the number of media objects requiring object-related signaling in the FLUTE session (This 8-bit unsigned integer field specifies the number of media objects that the object association signaling .).

The media_object_TOI field (32 bits) indicates a Transport Object Identifier (TOI) of the transport object transmitted through the FLUTE session (This 32-bit unsigned integer field, which is the transport object identifier associated with this transport Object carrying throught the FLUTE session.). That is, the media_object_TOI field indicates a value identifying a content / file transmitted through the FLUTE session.

The object_container_type_text_length field (8 bits) indicates the byte length of the object_container_type_text () character string. (This field shall specify the length (in bytes) of the object_container_type_text () character string.

The object_container_type_text () field indicates the file or object container type in which the object is encapsulated in text form. That is, in order to identify the type of the container, it is usually represented as a string that appears as an entry in the SDP. (The file or object container type where this object is encapsulated. Expressed in string that would normally appear as an entry in an SDP to identify the type of the container. For example, the object_container_type_text () field indicates a file format or the like in a text form.

The object_media_type_text_length field (8 bits) indicates the byte length of the object_media_type_text () character string. (This field shall specify the length (in bytes) of the object_media_type_text () character string.

The object_media_type_text () field indicates the media type that identifies the encoding format of the object described in this descriptor. That is, the encoding format of the object is displayed in a text form (The media type is the encoding format of the object that describes the descriptor describing the character string that normally appears in an 'a = rtpmap' entry in an SDP to identify the type of the media. For example, the object_media_type_text () field provides encoding format information such as audio and video transmitted in the NRT service in text form.

The object_decoding_parameters_text_length field (8 bits) indicates the byte length of the object_decoding_parameters_text () character string. (This field shall specify the length (in bytes) of the object_decoding_parameters_text () character string.

The object_decoding_parameters_text () field displays the decoding parameters of the object described in the descriptor in a text form (A text string that identifies the decoding parameters of the object that describes this descriptor).

If the object_association_type field value is '001' or '010', the descriptor may include an IP_version_flag field, a source_specific_multicast_flag field, an object_association_stream_source_IP_address field, an object_association_stream_destination_UDP_port_num field, and an object_association_stream_destination_IP_address field. That is, the descriptor provides connection information of an IP datagram transmitting the file or stream.

When the IP_version_flag field (1 bit) is set to '0', the object_association_stream_source_IP_address and object_association_stream_destination_IP_address fields are IPv4 addresses, and when set to '1', the object_association_stream_source_IP_address and object_association_stream_destination_IP_address fields are IPv6 addresses This field indicates that object_association_stream_source_IP_address and object_association_stream_destination_IP_address fields are IPv4 addresses. Otherwise, this field indicates that the object_association_stream_destination_IP_address fields and the object_association_stream_destination_IP_address fields are IPv6 addresses.

If the source_specific_multicast_flag field (1 bit) is set to '1', it indicates that the source specific multicast is used for the FLUTE session. Therefore, in this case, object_association_stream_source_IP_address must exist (A-1 bit Boolean flag, when set, that the source specific multicast is used for this FLUTE session. Thus, the object_association_stream_source_IP_address shall be present.

The object_association_stream_IP_address field (32 or 128 bits) is present when the source_specific_multicast_flag field is set to '1', but not when the source_specific_multicast_flag field is set to '0'. If present, this field contains the source IP address of all IP datagrams transmitting the component (i. E., Content / files) of the FLUTE session (this field shall be present if source_specific_multicast_flag is set to '1' and shall not be If present, this field shall contain the source IP address of all the IP datagrams carrying the components of this FLUTE session.

The object_association_stream_destination_IP_address field (32 or 128 bits) indicates the destination IP address of all IP datagrams transmitting the component (i.e., content / file) of the object related stream. carrying the components of this object association stream.

The object_association_stream_destination_UDP_port_num field (16 bits) indicates the destination UDP port number of the UDP / IP stream that transmits the object related stream (A 16-bit unsigned integer field, which represents the destination UDP port number for the UDP / IP stream carrying this object association stream.).

If the object_association_type field value is '010', the descriptor further includes an object_association_session_TSI field, an object_association_session_start_time field, an object_association_session_end_time field, a tias_bandwidth_indicator field, an as_bandwidth_indicator field, an FEC_OTI_indicator field, a tias_bandwidth field, an as_bandwidth field, an FEC_encoding_id field and an FEC_instance_id field. That is, the descriptor describes parameters necessary to receive the corresponding FLUTE session.

The object_association_session_TSI (16 bits) indicates a TSI of a FLUTE session for transmitting the object related file. That is, the TSI is an identifier that uniquely identifies the FLUTE session. (A 16-bit unsigned integer field, which is the TSI of the FLUTE session that carries the object association file.)

The object_association_session_start_time (16 bits) indicates the time at which the FLUTE session for transmitting the object related file starts. If the value of the corresponding field is all '0', the FLUTE session can be interpreted as already started (The time at which the FLUTE session that carries the object association file starts. If the value of this field is set to all- zero, then it will be interpreted to mean that the session has already started.

The object_association_session_end_time field (16 bits) indicates the time at which the FLUTE session for transmitting the object related file ends. If the value of the corresponding field is '0', the FLUTE session can be interpreted as continuing indefinitely (the time at which the FLUTE session that carries the object association file ends. If the value of this field is set to all zero , then it will be interpreted to mean that the session continues indefinitely.

The tias_bandwidth_indicator field (1 bit) indicates whether to include TIAS (Transport Independent Application Specific) bandwidth information. To indicate that the TIAS bandwidth field is present, the corresponding bit shall be set to '1' and the corresponding bit shall be set to '0' to indicate that the TIAS bandwidth field does not exist (A 1-bit field that flags the The inclusion of TIAS bandwidth information. This bit shall be set to '1' to indicate the TIAS bandwidth field is present, and it shall be set to '0' to indicate the TIAS bandwidth field is absent.

The as_bandwidth_indicator field (1 bit) indicates whether application specific (AS) bandwidth information is included. To indicate that the AS bandwidth field is present, the corresponding bit shall be set to '1' and to indicate that the AS bandwidth field does not exist, the corresponding bit shall be set to '0' (A 1-bit field that flags The inclusion of AS bandwidth information shall indicate that the AS bandwidth field is present, and that it shall be set to '0' to indicate the AS bandwidth field is absent.

The FEC_OTI_indicator field (1 bit) indicates whether the FEC Object Transmission Information (OTI) is provided (A 1-bit indicator indicating whether the FEC Object Transmission Information is provided).

The tias_bandwidth field (16 bits) is present when the as_bandwidth_indicator field is set to '1' and indicates the TIAS maximum bandwidth. (This value shall be one to two thousandths of the transport independent application specific maximum bandwidth as defined in RFC 3890 , rounded up to the next highest integer if necessary. This gives the TIAS bandwidth in kilobits per second).

The as_bandwidth field (16 bits) exists when the as_bandwidth_indicator field is set to '1' and indicates the AS maximum bandwidth (This value will be defined as RFC 4566. This gives the AS bandwidth in kilobits per second).

The FEC_encoding_id field is present when the FEC_OTI_indicator field is set to '1' and indicates the FEC encoding ID used in the corresponding FLUTE session (FEC encoding ID used in this FLUTE session, as defined in RFC 3926).

The FEC_instance_id field exists when the FEC_OTI_indicator field is set to '1', and indicates the FEC instance ID used in the corresponding FLUTE session (FEC instance ID used in this FLUTE session, as defined in RFC 3926).

For example, when the media object related information is transmitted in a stream or a file format, the stream may be a session announcement protocol (SAP) stream, and the file may be a SDP (Session Description Protocol) file. If the media object related information is transmitted in the SAP stream, the IP_version_flag field, the source_specific_multicast_flag field, the object_association_stream_source_IP_address field, the object_association_stream_destination_UDP_port_num field, and the object_association_stream_destination_IP_address field are access information of an IP datagram transmitting the SAP stream. Accordingly, the IP datagram of the SAP stream can be received based on the access information of the IP datagram, and the media object related information can be extracted from the IP datagram of the received SAP stream.

If the media object related information is transmitted as an SDP file, the IP_version_flag field, the source_specific_multicast_flag field, the object_association_stream_source_IP_address field, the object_association_stream_destination_UDP_port_num field, and the object_association_stream_destination_IP_address field are access information of the corresponding IP datagram or the FLUTE session for transmitting the SDP file . Accordingly, the IP datagram of the SDP file can be received based on the access information of the IP datagram, and the media object related information can be extracted from the IP datagram of the received SDP file.

FIG. 14 and FIG. 15 are diagrams showing still another embodiment of the bitstream syntax structure of the NST section according to the present invention.

Here, the syntax is written in the form of an MPEG-2 private section for the sake of understanding, but the format of the data may be any form. For example, other methods such as signaling through the Session Announcement Protocol (SAP) expressed in the form of SDP (Session Description Protocol) can be used.

In FIG. 14 and FIG. 15, the table_id field (8 bits) is a field for identifying the type of the corresponding table section. Through this field, it can be seen that the corresponding table section is a table section constituting the NST (An 8-bit unsigned integer number This indicates the type of table being defined in the NRT Service Table (NST).

The section_syntax_indicator field (1 bit) is an indicator for defining the section format of the NST. 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 type of the section conforms to the private section type (private_indicator: This 1-bit field shall be set to '1').

The section_length field (12 bits) indicates the length of the remaining table sections after the corresponding field (section_length: A 12-bit field. It specifies the number of remaining bytes this table section immediately follows this field. (0xFFD)).

The table_id_extension field (16 bits) is a table-dependent, logical part of the table_id field that provides the range of fields remaining (table_id_extension: This is a 16-bit field and is table-dependent. logically part of the table_id field providing the scope for the remaining fields). Here, the table_id_extension field includes an NST_protocol_version field.

The NST_protocol_version field (8 bits) indicates a protocol version for allowing NSTs to be transmitted by parameters having different structures from those defined in the current protocol (NST_protocol_version: An 8-bit unsigned integer field whose function is to allow, in NST_protocol_version may be used for a future version of this standard. The NST_protocol_version may be used to specify the value of NST_protocol_version. indicate structurally different tables).

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

The current_next_indicator field (1 bit) indicates whether the transmitted NST section is currently applicable (current_next_indicator: A one-bit indicator, which when set to '1' indicates that the NST sent is currently applicable. to '0', it will show that the table is not yet applicable and will be the next table to be valid. This standard imposes no requirement that "next" tables (those with current_next_indicator set to '0' update to the currently applicable table shall be signaled by incrementing the version_number field).

The section_number field (8 bits) indicates the number of the current NST section. (section_number: This 8-bit field shall give the section number of this NST section. The section number of the first section in an NST shall be '0x00'. The section number shall be incremented by 1 with each additional section in the NST).

The last_section_number field (8 bits) indicates the last section number constituting the NST table (last_section_number: This 8-bit field shall give the number of the last section (ie, the section with the highest section_number) is a part).

The carrier_frequency field (32 bits) indicates the transmission frequency corresponding to the channel.

The transport_stream_id field (16 bits) indicates a unique identifier of a broadcast stream to which the corresponding NST section is being transmitted.

The source_id field (16 bits) indicates the programming source associated with the virtual channel.

The num_NRT_services field (8 bits) indicates the number of NRT services in the NST section (num_services: This 8 bit field specifies the number of services in this NST section).

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

The NRT_service_status field (2 bits) identifies the state of the corresponding NRT service. Here, the MSB indicates whether the corresponding NRT service is active ('1') or inactive ('0'), and the LSB indicates whether the corresponding NRT service is hidden ('1') or not ('0'). (NRT_service_status: A 2-bit enumerated field that shall identify the status of this NRT Service. The most significant bit shall indicate whether this NRT Service is active (when set to '1') or inactive (when set to '0') and The NRT service is hidden (when set to '1') or not (when set to '0'). Hidden services are normally used for proprietary applications, and ordinary receiving devices should ignore them.

The SP_indicator field (1 bit) indicates whether the corresponding NRT service is service protection. 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 corresponding NRT service (see (1-bit field that indicates, when set to 1, service protection is applied to at least one of the components needed to provide a meaningful presentation of this NRT Service).

The CP_indicator field (1 bit) indicates whether the corresponding NRT service is content protection. If the value of the CP_indicator field is equal to 1, the content protection is applied to at least one of the components required to provide a meaningful presentation of the corresponding NRT service (CP_indicator: protection is applied to at least one of the components needed to provide a meaningful presentation of this NRT Service).

The NRT_service_id field (16 bits) indicates a value that uniquely identifies the corresponding NRT service. (A 16-bit unsigned integer number indicates that the NRT service will not uniquely identify this NRT service within the scope of this NRT section.) The value of the NRT_service_id field of one service does not change while the service is maintained. In order to avoid confusion at this time, if a certain service is terminated, the value of the NRT_service_id field of the service may not be used until a predetermined time elapses (The NRT_service_id of a service shall not change throughout the life of the service. , it is recommended that a service is terminated, then the NRT_service_id for the service should not be used for another service until after a suitable interval of time has elapsed.).

The Short_NRT_service_name field (8 * 8 bits) indicates the short name of the NRT service. If there is no short name of the NRT service, the field may be filled with a null value (e.g., 0x00).

The NRT_service_category field (6 bits) identifies the type of service to be transmitted in the corresponding NRT service, as defined in Table 1 below (NRT_service_category: A 6-bit enumerated type field that will identify the type of service carried in this NRT Service as defined in [Table 1]).

NRT_service_category Meaning 0x00 [Reserved] 0x0E NRT_channel_discovery: Transmit channel discovery information of NRT service. 0x0F NRT_content_discovery: Transmit the content discovery information of the NRT service. 0x10 NRT_SG_data_service: The NRT service includes electronic service guide data. 0x11-0x3F [Reserved for future ATSC use]

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

When the IP_version_flag field (1 bit) is set to '0', the source_IP_address field, the NRT_service_destination_IP_address field and the component_destination_IP_address field are IPv4 addresses, and when set to '1', the source_IP_address field, the NRT_service_destination_IP_address field and the component_destination_IP_address field are IPv6 addresses (NRT_service_destination_IP_address, NRT_service_destination_IP_address, NRT_service_destination_IP_address, NRT_service_destination_IP_address, NRT_service_destination_IP_address, NRT_service_destination_IP_address, NRT_service_destination_IP_address, NRT_service_destination_IP_address, and component_destination_IP_address fields are for IPv6).

The source_IP_address_flag field (1 bit) indicates that, when the flag is set, the source IP address value for the corresponding NRT 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 NRT Service is present to indicate a source specific multicast).

If the NRT_service_destination_IP_address_flag field (1 bit) is set to '1', there is an NRT_service_destination_IP_address field to provide a default IP address for the corresponding NRT service components (NRT_service_destination_IP_address_flag: A 1-bit Boolean flag indicating that when set to ' 1 'that a NRT_service_destination_IP_address value is present, to serve as the default IP address for the NRT Service).

When the source_IP_address_flag field is set to '1', the source_IP_address field (128 bits) is present, but if the source_IP_address_flag field is set to '0', the corresponding field will not exist. If the corresponding field is present, the corresponding field will contain the source IP address of all IP datagrams carrying the components of the corresponding NRT service. The limited use of the 128-bit long address in the field is intended to enable future use of IPv6, although the current use of IPv6 is not defined. Source_IP_address is the source IP address of the same server that is sending all the channels of the FLUTE session (source_IP_address: This field shall be present if the source_IP_address_flag is set to '1' and shall not be present if the source_IP_address_flag is set If this field is set to '0', then this field shall contain the source IP address of all the IP datagrams carrying the components of this NRT Service. The conditional use of the 128- in the future, although IPv6 is not currently defined).

If the source_IP_address_flag field is set to '1', the corresponding source_IP_address field is present but the source_IP_address_flag field is set to '0', the source_IP_address field will not be present in the NRT_service_destination_IP_address field (128 bits). If the corresponding source_IP_address field does not exist, then the component_destination_IP_address field will exist for each component in the num_components loop. The limited use of the 128-bit long address in the source_IP_address field is intended to enable the use of IPv6 in the future, although the current use of IPv6 is not defined. NRT_service_destination_IP_Address is signaled if there is a destination IP address of the session level of this FLUTE session (NRT_service_destination_IP_address: This field shall be present if NRT_service_destination_IP_address_flag is set to '1' and shall not present the NRT_service_destination_IP_address_flag is set to '0'. If this NRT_service_destination_IP_address is not present, then the component_destination_IP_address field shall be present for each component in the num_components loop. The conditional use of the 128 bit-long address , although use of IPv6 is not currently defined).

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, connection information of each component included in the NRT service is provided. At this time, the following field information can be provided for each component. Here, one component corresponds to one FLUTE session.

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

The port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component. The value of destination UDP port numbers is incremented by 1, starting from the value of the component_destination_UDP_port_num field (port_num_count: this field indicates the number of destination UDP ports associated with this UDP / IP stream component. from the component_destination_UDP_port_num field and shall be incremented by one).

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

When the component_destination_IP_address_flag is set to '1', the corresponding field is present, but if the component_destination_IP_address_flag is set to '0', the corresponding field will not exist. If the corresponding field is present, the corresponding field will contain the source IP address of all IP datagrams carrying the components of the corresponding NRT service. The limited use of the 128-bit long address in the field is intended to enable the use of IPv6 in the future, although the current use of IPv6 is undefined (component_destination_IP_address: this field shall be present if the component_destination_IP_address_flag is set to '1' When this field is present, the destination address of the IP datagrams is the address of this field. This field is not present, The IPv6 address is the address of the destination address of the IP datagram, which is the address of the destination address of the destination node. defined.

The component_destination_UDP_port_num field (16 bits) indicates the destination UDP port number for the corresponding UDP / IP stream component (component_destination_UDP_port_num: A 16-bit unsigned integer field, which represents the destination UDP port number for this UDP / IP stream component).

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_NRT_service_level_descriptors field (4 bits) indicates the number of descriptors providing additional information of the NRT service level.

NRT_service_level_descriptors () are included in the NRT service loop by the number corresponding to the value of the num_NRT_service_level_descriptors field, thereby providing additional information on the NRT service.

The num_virtual_channel_level_descriptors field (4 bits) is the number of descriptors providing additional information of the virtual channel level.

Virtual_channel_level_descriptors () are included in the virtual channel loop by the number corresponding to the value of the num_virtual_channel_level_descriptors field, thereby providing additional information on the virtual channel.

FIG. 16 shows an embodiment of a bitstream syntax structure of component_descriptor () provided as component_level_descriptors (). That is, the component_descriptor () is used as one of the component level descriptors component_level_descriptors () of the NST and describes additional signaling information of the corresponding component.

The description of each field of the component_descriptor () is as follows.

16, the descriptor_tag field (8 bits) is a descriptor identifier, and an identifier that identifies the component_descriptor () may be set.

The descriptor_length field (8 bits) indicates the remaining length of the descriptor in bytes after the descriptor_length field to the end of the descriptor.

The component_type field (7 bits) indicates a value that identifies the encoding format of the component. The identification value may be one of values assigned for the payload_type of the RTP / AVP stream. Or it may be one of the predetermined values by the promise of the transmitting / receiving side, or may be a dynamic value between 96 and 127. [ The value of the component_type field shall match the value in the payload_type in the RTP header of the IP stream that transmits the component (component_type: This 7-bit field shall identify the encoding format of the component. The value may be any of the values assigned by IANA for the payload_type of an RTP / AVP stream, or may be any of the values assigned by ATSC, or may be a "dynamic value" in the range 96-127 For RTP, the value of this field shall match the value of the payload_type field in the RTP header of the IP stream carrying this component. Note that additional values of the component_type field in the range of 43-71 can be defined in future versions of this standard.

  The component_data (component_type) field provides the encoding parameters and / or other parameters needed to render the component. Here, the structure of the component_data element is determined by the value of the component_type field (component_data (component_type): The component_data () element provides the encoding parameters and / or other parameters necessary for rendering this component. value of component_type field).

For example, if the component_type field value is 35, the component_data (component_type) field provides component data for the H.264 / AVC video stream.

As another example, if the component_type field value is 38, the component_data (component_type) field provides data for FLUTE file delivery as shown in FIG. The description of each field in Fig. 17 will be omitted since it will be referred to Fig.

That is, the signaling information necessary for receiving the corresponding FULTE session may be provided using the NRT_FLUTE_File_Delivery_descriptor () of FIG. 11, or may be provided using the component_descriptor () descriptor of FIG.

In FIG. 16, the component_encryption_flag field (1 bit) indicates whether the corresponding component is encrypted or not.

The Num_STKM_streams field (8 bits) indicates the number of STKM streams associated with the component if the component_encryption_flag field indicates encryption (num_STKM_streams: An 8-bit unsigned integer field that identifies the number of STKM streams associated with this component).

The STKM_stream_id field (8 bits) is repeated by the value of the Num_STKM_streams field to indicate a value for identifying an SKTM stream from which a key required for decryption can be obtained.

On the other hand, the NST in FIGS. 14 and 15 can also provide media object association information.

In one embodiment, if the media object related information exists, the NRT_media_object_association_descriptor () shown in FIG. 12 is provided to the component level descriptor. In this case, the receiver parses all the descriptors included in the component level descriptor, and identifies the NRT_media_object_association_descriptor () using the identifier of the descriptor. The description of each field of the NRT_media_object_association_descriptor () and the process of extracting the media object related information in text form from the NRT_media_object_association_descriptor () will be omitted because it will be described with reference to the NST description in FIG. At this time, a media_object_association_indicator field (1 bit) may be allocated to the NST of FIG. 14 and FIG. 15 to identify whether the NRT_media_object_association_descriptor () exists in the component loop.

In another embodiment, the media object related information may be provided using the component_descriptor () shown in FIG. At this time, the component_type field value may use one of the values between 43 and 71. In the present invention, 43 is allocated to provide the media object association information as component data. The numerical values shown above are only examples, and the numerical values do not limit the scope of the present invention. That is, if the component_type field value is 43, the component_data (component_type) field provides the component data for media object association information as shown in FIG. The description of each field in Fig. 17 will be referred to Fig. 12, and thus will not be described here.

In another embodiment, when the media object related information is provided using the component_descriptor () shown in FIG. 16, the value of the component_type field may be assigned to any value within the dynamic range (i.e., 96-127). In this case, the media object related information can be provided using the component data as shown in Fig.

FIG. 19 shows an embodiment of a bitstream syntax structure of component_data () when a value within a dynamic range (i.e., 96-127) is assigned as a component_type field value.

In Figure 19, the general_media_type field (4 bits) indicates the general media type of the component. For example, if the general_media_type field value is 0x0, the following media_type_text () field and decoding_parameters_text () field are used to provide the encoding format and decoding parameter applied to the video stream in text form. For example, the media_type_text () field and the decoding_parameters_text () field provide an encoding format and a decoding parameter in a text format expressed by a Multipurpose Internet Mail Extensions (MIME) type.

The present invention may allocate 0x2 as the general_media_type field value or assign a value of 0x4 to 0xF and provide media object related information in a text form using the media_type_text () field and the decoding_parameters_text () field .

In FIG. 19, the ISO_639_language_code field (24 bits) indicates the language used when the 0x0 is assigned as the general_media_type field value, that is, the audio stream.

The media_type_text_length field (8 bits) indicates the byte length of the next media_type_text () character string. (This field shall specify the length (in bytes) of the media_type_text () character string.)

The media_type_text () field indicates the media type that identifies the encoding format. That is, the encoding format of the stream corresponding to the general media type is displayed in text form

The decoding_parameters_text_length field (8 bits) indicates the length of the next decoding_parameters_text () character string. (This field shall specify the length (in bytes) of the decoding_parameters_text () character string.)

The decoding_parameters_text () field indicates the decoding parameters of the stream corresponding to the general media type in text form.

20 is a flowchart illustrating an NRT service signaling data and an NRT service data extraction process according to the present invention. In FIG. 20, 0x05 is assigned to the service_type field value in the VCT as shown in FIG. 6 to indicate that one or more NRT services are transmitted to the corresponding virtual channel.

That is, when the physical transmission channel is tuned (S301), the VCT and the PMT are obtained from the broadcasting signal received through the tuned physical transmission channel (S302). Then, the obtained VCT is parsed to check whether there is an NRT service (S303). This can be ascertained by checking the value of the service_type field in the virtual channel loop of the VCT. S301 is performed in the tuner, and S302 and S303 are performed in the PSI / PSIP section handler.

For example, if the service_type field value is not 0x05, the virtual channel does not transmit the NRT service. At this time, since the virtual channel transmits an existing service (i.e., legacy ATSC service), the receiver performs an appropriate operation according to the information included in the virtual channel.

If the service_type field value is 0x05, the virtual channel transmits the NRT service. In this case, since the NRT service descriptor (NRT_service_descriptor ()) as shown in FIG. 7 is included in the virtual channel loop, the identification information of each NRT service is extracted from the NRT service descriptor and stored (S304). That is, an identifier, short name, service type, and service status information (NRT_service_id, NRT_service_short_name, NRT_service_category, NRT_service_status) of each NRT service transmitted to the virtual channel from the NRT service descriptor are extracted. S301 is performed in the tuner, and S302 through S304 are performed in the service manager or the PSI / PSIP section handler.

If the stream_type field value included in the service location descriptor (or the ES loop of the PMT) of the VCT is 0x95 (i.e., DST transmission), the DST is received using the Elementary_PID field value at this time (S305, S306). S305 and S306 are performed in the demultiplexer under the control of the service manager.

The NRT service is identified from the received DST (S307), and the PID of the MPEG-2 TS packet segmented from the IP datagram of the NRT service signaling channel transmitting the signaling data of the identified NRT service, for example, the NST, is obtained . The NRT service can be confirmed from the value of the App_id_description field.

The present invention assigns '0x0003' to the App_id_descrption field to identify an NRT application (i.e., an NRT service). The numerical values shown above are only examples, and the numerical values do not limit the scope of the present invention.

If the value of the App_id_description field in the DST is '0x0003', the next Application_id_byte value becomes the Service ID value of the NRT application (i.e., the NRT service). Therefore, after identifying the NRT application (i.e., the NRT service) as described above, the Tap is extracted to find the PID of the MPEG-2 TS packet segmented from the IP datagram of the NRT service signaling channel (S308). Then, a stream PID including an association_tag of the extracted Tap is extracted from the PMT (S309). The steps S307 to S309 are performed in the service manager or the PSI / PSIP section handler.

When the MPEG-2 TS packets corresponding to the extracted stream PID are received and the decapsulation, i.e., the MPEG-2 header is removed, the DSM-CC addressable section is restored (S310). S310 is performed in the addressable section handler.

If the section header and the CRC checksum are removed from the DSM-CC addressable section, the IP datagram transmitting the NRT service signaling channel can be recovered. The access information of the IP datagram transmitting the NRT service signaling channel is a well-known destination IP address and a well-known destination UDP port number.

FIG. 21 is a flowchart illustrating an exemplary process of obtaining an NST shown in FIG. 9 from an IP datagram restored in FIG. 20 and receiving an NRT service based on the obtained NST.

That is, an IP multicast stream for transmitting an NRT service signaling channel is acquired with a well-known destination IP multicast address and a well-known destination UDP port number through the process of FIG. 20 (S401).

Then, the IP datagram transmitted through the IP multicast stream is collected to configure the NST (S402). That is, the NST is identified from the NRT service signaling data included in the IP datagram by using the table identifier. S401 and S402 are performed in the IP datagram handler and the UDP datagram handler.

When the NST is parsed, connection information of a FLUTE session for transmitting content / files constituting an NRT service and signaling information necessary for rendering the NRT service can be extracted. For example, it is possible to extract information necessary for rendering the content / files of the NRT service transmitted from the NST to each FLUTE session. The information necessary for rendering the content / files of the NRT service may be container information, encoding information, or a decoding parameter of the media object.

That is, IP connection information for a FLUTE session for transmitting the content / file constituting the NRT service is obtained from the FLUTE session loop of the NST (S403).

The media_object_association_indicator field in the FLUTE session loop is checked (S404), and it is confirmed whether the media_object_association_indicator field value is true (i.e., 1) (S405). If the value of the media_object_association_indicator field indicates true, the NRT_media_object_association_descriptor () received as one of the FLUTE_session_level_descriptor of the NST is parsed (S406). That is, if the value of the media_object_association_indicator field is true, media object related information related to the FLUTE session is signaled directly in the form of a text in NRT_media_object_association_descriptor (), or provided in the form of a stream or a file. When the media object related information is transmitted in the form of a stream or a file, the NRT_media_object_association_descriptor () provides access information for receiving the stream or file. When the media object related information is transmitted in a file format, the NRT_media_object_association_descriptor () signals parameters necessary to receive a FLUTE session for transmitting the file.

Accordingly, it is checked whether the object_association_type field value of the NRT_media_object_association_descriptor () parsed in S406 is '000' (S407) in order to identify whether the media object related information is transmitted as a descriptor, a stream, or a file .

If the object_association_type field value is '000', container information, encoding information, and decoding parameters of the media object, which are essential for rendering the content / files constituting the NRT service, are obtained from the NRT_media_object_association_descriptor () (S409).

If the object_association_type field value is '001' or '010', it obtains IP connection information from the NRT_media_object_association_descriptor () and receives an IP multicast stream for transmitting the media object related information, or transmits the object related data structure of the file A FLUTE session is received (S408). In step S409, container information, encoding information, and decoding parameters of a media object necessary for rendering the content / files constituting the NRT service from the received IP multicast stream or FLUTE session are acquired.

If it is determined in step S409 that the media_object_association_indicator field value is not true in step S405, the NRT_FLUTE_File_delivery_descriptor () received as the FLUTE_session_level_descriptor of the NST is parsed to obtain FLUTE level access information (S410). In step S411, the FLUTE file access server accesses the FLUTE file delivery session using the FLUTE level access information obtained in step S410, and collects files belonging to the session. When the files are collected, one NRT service is configured and stored in a storage medium or displayed on a display device (S412). S403 to S407, S409 and S410 are performed in the service signaling section handler, and S408 is performed in the IP datagram handler, UDP datagram handler, and ALC / LCT stream handler. The S411 is performed in the ALC / LCT stream handler.

If the object_association_type field is not allocated to the NST as shown in FIGS. 14 and 15, steps S404 and S405 are omitted.

In this manner, container information, encoding information, and decoding parameters of the media object, which are essential for rendering the content / files constituting the NRT service according to the present invention, are signaled to the corresponding NST on a FLUTE session basis or on a component basis.

Meanwhile, the NRT service signaling data transmitted in the NRT service signaling channel according to the present invention may further include an NCT (NRT Content Table). The NCT is used for signaling / announcing signaled NRT content through the NST. At this time, since the IP datagrams of the NRT service signaling channel have the same well-known IP address and a well-known UDP port number, the division of the NCT included in the NRT service signaling data is performed by the table identifier. Similarly, whether a single NCT is composed of one section or a plurality of sections can be known through a table_id field, a section_number field, a last_section_number field, and the like in the NCT section. After removing the IP header and the UDP header of the IP datagrams of the NRT service signaling channel, the corresponding tables can be completed by collecting sections having the same table identifier. For example, you can complete the NCT by gathering sections with table identifiers assigned to the NCT.

22 is a diagram showing an embodiment of a bitstream syntax structure for an NCT section according to the present invention. Details of each field of the NCT section are as follows.

In FIG. 22, the table_id field (8 bits) is an identifier of the table, and an identifier that identifies the NCT can be set.

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

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

The section_length field (12 bits) indicates the section length of the NST.

The NRT_service_id field (16 bits) indicates a value that can uniquely identify the NRT service including the content described by the NCT.

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

The current_next_indicator field (1 bit) indicates whether the information included in the corresponding NCT section is currently applicable information or future applicable information.

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

The last_section_number field (8 bits) indicates the last section number of the NCT.

The protocol_version field (8 bits) tells the protocol version to allow the NCT to transmit parameters with a different structure than those defined in the current protocol (An 8-bit unsigned integer field whose function is to allow, This NRT Content Table may carry different parameters that may be structured differently than the current protocol. At present, the value for the protocol_version shall be zero. structurally different tables.)

The num_contents_in_section field (8 bits) indicates the number of contents described in this NCT. At this time, the number of contents indicates the number of contents (or files) to be transmitted through the virtual channel specified by the source_id.

Then, a 'for' loop (or a content loop) is performed for the number of contents corresponding to the num_contents_in_section field value, and detailed information of the corresponding content is provided for each content.

The content_version field (32 bits) indicates the version number for the content (or file) with a particular content_id value. That is, suppose that the content having the same content, that is, the content having the content_id value of 0x0010, is transmitted with the content_id of the previously received and stored content of the receiver being 0x0010. At this time, if the value of the content_version field is changed, the content newly announced through the NCT is received, and the previously stored content is updated or replaced. In the present embodiment, the value of the content_version field indicates a serial number indicating the version of release, but the published time may be directly expressed. At this time, a new field capable of expressing a published time can be used when it is difficult to express the publish time in the content_version field.

The content_id field (16 bits) indicates an identifier that can uniquely identify the content (or file).

The content_available_start_time field (32 bits) and the content_available_end_time field (32 bits) indicate the start time and end time of the FLUTE session transmitting the content.

The content_length_in_seconds field (30 bits) indicates the actual playback time of the content in seconds when the content (or file) is an A / V file.

The content_size field (48 bits) indicates the size of the content (or file) in bytes.

The content_delivery_bit_rate field (32 bits) indicates a bit rate at which the content (or file) is transmitted, and indicates a target bit rate. That is, it indicates how much bandwidth the service provider or the broadcasting station should allocate when transmitting the content. Therefore, by using the content_size and the content_delivery_bit_rate in the receiver, the minimum time required to receive the content (or file) can be known. That is, the time required to receive the content can be estimated and the information can be provided to the user. The minimum reception time is obtained by calculating (conent_size * 8) / (content_delivery_bit_rate), and the unit is seconds.

The content_title_length field (8 bits) indicates the length of content_title_text () in bytes. With this field, the receiver can know how many bytes of data to read in order to obtain the content_title_text () information correctly.

The content_title_text () field displays the content title in a multiple string structure format (content title in the format of a multiple string structure).

That is, the receiver can obtain the NRT content / file configuration information using the NCT and provide the NRT content / file guide based on the acquired NRT content / file configuration information. From this guide, access information of a FLUTE session for transferring a selected content / file can be obtained from the NST, and the selected content can be received using the acquired FLUTE session access information.

Meanwhile, the present invention can transmit container information, encoding information, and decoding parameters of a media object, which are essential for rendering the content / files constituting the NRT service, in the NCT. Accordingly, the receiving system extracts container information, encoding information, and decoding parameters of a media object, which are indispensable for rendering the corresponding content for each content, and can use it for rendering the corresponding content.

FIG. 23 shows an embodiment of a receiving system capable of receiving, storing, and reproducing NRT content for a fixed NRT service.

23 includes an operation control unit 100, a baseband processing unit 110, a service demultiplexer 120, a stream component handler 130, a media handler 140, a file handler 150, a service manager 160 The PVR manager 170, the first storage unit 180, the SG handler 190, the EPG handler 200, the NRT service manager 210, the application manager 220, the middleware engine 230, A user interface (UI) manager 240, and a user interface (UI) manager 250.

The baseband processing unit 110 may include a tuner 111 and a demodulator 112. The service demultiplexer 120 includes an MPEG-2 TP handler 121, a PSI / PSIP handler 122, an MPEG-2 TP demultiplexer 123, a descrambler 124 and a second storage unit 125 .

The stream component handler 130 includes a Packetized Elementary Stream (PES) decoder 131, an ES (Elementary Stream) decoder 132, a PCR handler 133, an STC handler 134, a DSM-CC addressable section handler 135, an IP datagram handler 136, a descrambler 137, a UDP handler 138, a service signaling section handler 138-1, and a CAS (Conditional Access System 139).

The media handler 140 may include an A / V decoder 141. The file handler 150 includes an ALC / LCT stream handler 151, a file reconstruction buffer 152, an XML parser 153, an FDT handler 154, a decompressor 155, 156, and a file decoder 157.

23, the tuner 111 tunes a broadcast signal of a desired channel among broadcast signals received via a terrestrial wave, under the control of the service manager 160, and generates an intermediate frequency (IF) signal And outputs the down-converted signal to the demodulator 112. The tuner 111 may receive a real-time stream and a non-real-time stream. In the present invention, a non-real-time stream is referred to as an NRT stream.

The demodulator 112 performs automatic gain control, carrier recovery, and timing recovery on a digital IF signal of a passband inputted from the tuner 111, converts the digital IF signal into a baseband signal, and performs channel equalization. For example, if the broadcast signal is a VSB modulation signal, VSB demodulation is performed to perform automatic gain control, carrier recovery, and timing recovery. The demodulated and channel-equalized data in the demodulator 112 is output to the MPEG-2 TP handler 121 in the form of an MPEG-2 Transport Stream (TS) packet.

The MPEG-2 TP (Transport Stream Packet) handler 121 comprises an MPEG-2 TP buffer and an MPEG-2 TP parser. The MPEG-2 TP temporarily stores the output of the demodulator 112 and analyzes the TS header, PSIB handler 122 if the output of the PSI / PSIP table 112 is an A / V TS packet for real time or an NRT TS packet, and outputs it to the demultiplexer 123 if the output is a PSI / PSIP table TS packet.

The PSI / PSIP handler 122 is composed of a PSI / PSIP section buffer and a PSI / PSIP parser. The PSI / PSIP handler 122 temporarily stores a TS packet output from the MPEG-2 TP handler 121, And restores and parses the corresponding table from the PSI / PSIP section data included in the payload of the packet. At this time, whether a table is composed of one section or a plurality of sections can be known through a table_id field, a section_number field, a last_section_number field and the like in the corresponding section. And if you collect the sections with the same table identifier, you can complete the corresponding table. For example, collecting sections with table identifiers assigned to the VCT can complete the VCT. The information of each parsed table is collected by the service manager 160 and stored in the first storage unit 180. Table information such as VCT, PAT, PMT, and DST according to the present invention is stored in the first storage unit 180 through the above process. The service manager 160 stores the table information in the first storage unit 180 in the form of a service map and guide data.

If the inputted TS packet is an A / V TS packet, the demultiplexer 123 separates the inputted TS packet into an audio TS packet and a video TS packet and outputs the audio TS packet and the video TS packet to the PES decoder 131. If the input TS packet is an NRT TS packet, 135). The demultiplexer 123 outputs the TS packet to the PCR handler 133 if the TS packet includes a PCR (Program Clock Reference), and outputs the TS packet to the CAS 139 if the TS packet contains CA (Conditional Access) information. The NRT TS packet is divided into a TS packet including NRT service data and a TS packet including an NRT service signaling channel. A unique PID is assigned to the TS packet of the NRT service data to identify the NRT service, and the PID of the TS packet including the NRT service signaling channel is extracted using DST and PMT.

The demultiplexer 123 outputs the TS packet payload to the descrambler 124 if the payload of the TS packet is scrambled and the descrambler 124 extracts information necessary for descrambling from the CAS 139 And the like), and performs descrambling on the TS packet.

The demultiplexer 123 stores real-time A / V packets, which are input at one of the temporary recording, the scheduled recording, and the time shift, in the second storage unit 125. The second storage unit 125 is a mass storage medium, and may be an HDD or the like. The download (i.e., storage) and upload (i.e., playback) in the second storage unit 125 are performed under the control of the PVR manager 170.

The demultiplexer 123 separates audio TS packets and video TS packets from the A / V TS packets uploaded from the second storage unit 125 according to a reproduction request, and outputs the separated audio TS packets and video TS packets to the PES decoder 131.

The demultiplexer 123 is under the control of the service manager 160 and / or the personal video recorder (PVR) manager 170 for the above-described processing.

That is, when the service_type field value in the VCT indicates that the NRT service is transmitted, the service manager 160 extracts the NRT service descriptor () from the NRT service descriptor (NRT_service_descriptor ()) shown in FIG. 7 received in the virtual channel loop of the VCT And extracts the PID of the DST from the service location descriptor of the VCT (or the ES loop of the PMT) to receive the DST.

Then, the NRT service is identified from the received DST and the PID of the MPEG-2 TS packet including the NRT service signaling channel is extracted using DST and PMT to receive the identified NRT service. The extracted PID is output to the demultiplexer 123. The demultiplexer 123 outputs the MPEG-2 TS packets corresponding to the PID output from the service manager 160 to the addressable section handler 135.

The PCR is a time reference value used for time synchronization of the audio ES and the video ES in the A / V decoder 141. The PCR handler 133 restores the PCR included in the payload of the inputted TS packet and outputs it to the STC handler 134. The STC handler 134 restores the STC (System Time Clock) which is a reference clock of the system from the PCR and outputs the STC to the A / V decoder 141.

The PES decoder 131 is composed of a PES buffer and a PES handler. The PES decoder 131 temporarily stores audio TS packets and video TS packets, and then removes TS headers from each TS packet to restore audio PES and video PES. The restored audio PES and video PES are output to the ES decoder 132. The ES decoder 132 includes an ES buffer and an ES handler. The ES decoder 132 removes each PES header from the audio PES and the video PES, and restores the audio ES and the video ES, which are pure data. The restored audio ES and video ES are output to the A / V decoder 141.

The A / V decoder 141 decodes the audio ES and the video ES using respective decoding algorithms, restores the audio ES and the video ES to their pre-compression state, and outputs the decoded audio ES and the video ES to the presentation manager 240. At this time, time synchronization is performed when decoding the audio ES and the video ES according to the STC. 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 CAS 139 is composed of a CA stream buffer and a CA stream handler. The CAS 139 temporarily stores service protection data restored and output from a TS packet or UDP datagram handler 138 output from the MPEG-2 TP handler 121 (E.g., a control word used for scrambling) necessary for descrambling from the stored TS packet or service protection data. That is, an EMM (Entitlement Management Message), an ECM (Entitlement Control Message), and the like included in the payload of the TS packet are extracted, and the extracted EMM and ECM are analyzed to obtain information necessary for descrambling. The ECM may include a control word (CW) used for scrambling. At this time, the control word may be encrypted with an authentication key. The EMM may include the authentication key and the qualification information of the corresponding data. Information required for descrambling acquired by the CAS 139 is output to the descramblers 124 and 137.

The DSM-CC section handler 135 comprises a DSM-CC section buffer and a DSM-CC section parser. The DSM-CC section handler 135 temporarily stores a TS packet output from the demultiplexer 123, Restores the addressable section, removes the header of the addressable section and the CRC checksum, restores the IP datagram, and outputs the recovered IP datagram to the IP datagram handler 136. The IP datagram handler 136 comprises an IP datagram buffer and an IP datagram parser. The IP datagram handler 136 buffers the IP datagram received from the DSM-CC section handler 135, and then stores the header of the buffered IP datagram Extracts and analyzes the UDP datagram, restores the UDP datagram from the payload of the IP datagram, and outputs the UDP datagram to the UDP datagram handler 138.

If the IP datagram is scrambled, the scrambled UDP datagram is descrambled by the descrambler 137 and output to the UDP datagram handler 138. For example, the descrambler 137 receives information necessary for descrambling (e.g., a control word used for scrambling) from the CAS 139, descrambles the UDP datagram, And outputs it to the handler 138.

The UDP datagram handler 138 comprises a UDP datagram buffer and a UDP datagram parser. The UDP datagram handler 138 buffers a UDP datagram output from the IP datagram handler 136 or the descrambler 137, Extracts and analyzes the header of the datagram and restores the data contained in the payload of the UDP datagram. If the restored data is the service protection data, the restored data is output to the CAS 139. If the restored data is the NRT service signaling data, the service signaling section handler 138-1 outputs the restored data to the CAS 139. If the restored data is the NRT service data, .

That is, the connection information of the IP datagram transmitting the NRT service signaling channel is a well-known destination IP address and a well-known destination UDP port number.

Therefore, the IP datagram handler 136 and the UDP datagram handler 138 are connected to each other via an IP multicast address, which has a well-known destination IP multicast address and a well-known destination UDP port number, Extracts the cast stream, that is, the NRT service signaling data, and outputs it to the service signaling section handler 138-1.

The service signaling section handler 138-1 comprises a service signaling section buffer and a service signaling section parser. The service signaling section handler 138-1 restores and parses the NST as shown in FIG. 9, FIG. 14, and FIG. 15 from the NRT service signaling data, (160). When the NST is parsed, connection information of a FLUTE session for transmitting content / files constituting an NRT service and signaling information necessary for rendering the NRT service can be extracted. For example, it is possible to extract information necessary for rendering the content / files of the NRT service transmitted from the NST to each FLUTE session. The information necessary for rendering the content / files of the NRT service may be container information, encoding information, or a decoding parameter of the media object.

The information parsed from the NST is collected by the service manager 160 and stored in the first storage unit 180. The service manager 160 stores the information extracted from the NST in the first storage unit 180 in the form of a service map and guide data. In another embodiment, the role of the service manager 160 may be performed by the NRT service manager 210. That is, the information parsed from the NST may be collected by the NRT service manager 210 and stored in the first storage unit 180.

The ALC / LCT stream handler 151 comprises an ALC / LCT stream buffer and an ALC / LCT stream parser. The ALC / LCT stream handler 151 buffers data of the ALC / LCT structure output from the UDP datagram handler 138, And analyzes the header and header extension of the ALC / LCT session. If the data transmitted in the ALC / LCT session is an XML structure as a result of analyzing the header and the header extension of the ALC / LCT session, the XML parser 153 outputs the data to the XML parser 153. If the file structure is a file reconstruction buffer 152, And then outputs it to the file decoder 157 or stores it in the third storage unit 156. [ The ALC / LCT stream handler 151 is under the control of the NRT service manager 210 if the data transmitted in the ALC / LCT session is data for an NRT service. At this time, if the data transmitted in the ALC / LCT session is compressed, it is released from the decompressor 155 and then output to at least one of the XML parser 153, the file decoder 157, and the third storage unit 156.

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

The FDT handler 154 analyzes and processes a file description table of the FLUTE protocol through an ALC / LCT session. The FDT handler 154 is under the control of the NRT service manager 210 when the received file is a file for NRT service.

The SG handler 190 collects and analyzes data for a service guide transmitted in an XML structure, and outputs the data to the EPG manager 200.

The file decoder 157 decodes a file output from the file reconstruction buffer 152 or a file output from the decompressor 155 or a file uploaded from the third storage unit 156 using a predetermined algorithm, 230, or outputs it to the A / V decoder 141.

The middleware engine 230 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 240. The middleware engine 230 is a JAVA-based middleware engine.

The EPG manager 200 receives service guide data from the SG handler 190 according to an input from the user, converts the service guide data into a display format, and outputs the display format to the presentation manager 240. The application manager 220 performs overall management of processing of application data received in the form of a file or the like.

The service manager 160 collects and analyzes the PSI / PSIP table data or the NRT service signaling data transmitted through the NRT service signaling channel, creates a service map, and stores the service map in the first storage unit 125. The service manager 160 controls access information for a desired NRT service and controls the tuner 111, the demodulator 112, the IP datagram handler 136, and the like.

The operation controller 100 controls the operation of the service manager 160, the PVR manager 170, the EPG manager 200, the NRT service manager 210, the application manager 220, and the presentation manager 240 to perform functions according to the commands of the user.

The NRT service manager 210 performs overall management of an NRT service transmitted in a content / file format through a FLUTE session on an IP layer.

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

The presentation manager 240 transmits at least one of audio and video data output from the A / V decoder 141, file data output from the middleware engine 230, and service guide data output from the EPG manager 210, And / or a screen.

One of the service signaling section handler 138-1, the service manager 160 and the NRT service manager 210 may be a FLUTE session loop of the NST of FIG. 9 (or a component loop of the NST of FIG. 14, ) To obtain the IP connection information for the FLUTE session for transmitting the content / file constituting the NRT service. Also, when NRT_media_object_association_descriptor () is included in the FLUTE session loop (or the component loop of the NST in FIGS. 14 and 15), media object related information related to the FLUTE session is extracted from the NRT_media_object_association_descriptor (). The media object association information is provided in a text form of a MIME type. At this time, the media object related information is directly described in a text form in NRT_media_object_association_descriptor (), or in a form of text in a stream or a file. When the media object related information is transmitted in the form of a stream or a file, the NRT_media_object_association_descriptor () provides access information for receiving the stream or file. When the media object related information is transmitted in a file format, the NRT_media_object_association_descriptor () signals parameters necessary to receive a FLUTE session for transmitting the file. The media object association information includes container information, encoding information, decoding parameters of the media object, and the like, which are essential for rendering the content / files constituting the NRT service. Also, FLUTE level access information is obtained from the NRT_FLUTE_File_delivery_descriptor () included in the FLUTE session loop of the NST of FIG. Also, the FLUTE level access information is obtained from the component_descriptor () included in the component loop of the NST in FIGS. 14 and 15.

Then, the ALC / LCT stream handler 151 and the file decoder 157 access the FLUTE file delivery session using the obtained FLUTE level access information, and collect files belonging to the session. When the files are collected, one NRT service is configured. The NRT service may be stored in the third storage unit 156 or output to the middleware engine 230 or the A / V decoder 141 to be displayed on the display device.

The third storage unit 156 is a storage medium for storing a file such as NRT service data and may be shared with the second storage unit 125 or used separately.

Mobile NRT  service

Among the terms used in connection with the mobile NRT service according to the present invention, the main service data may include audio / video (A / V) data as data that can be received by the 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 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.

24 shows an example of a protocol stack for providing a mobile NRT service. FIG. 24 illustrates an adaptation layer between an IP layer and a physical layer so that an IP datagram of mobile service data and an IP datagram of signaling information can be transmitted without using the MPEG-2 TS format .

That is, the broadcasting station packetizes the NRT contents / files according to the file transfer protocol in FIG. 24, and packetizes the NRT contents / files according to the ALC / LCT (Asynchronous Layered Coding / Layered Coding Transport) method. The packetized ALC / LCT data is again packetized according to the UDP scheme, and the packetized ALC / LCT / UDP data is again packetized according to the IP scheme to become ALC / LCT / UDP / IP data. The packetized ALC / LCT / UDP / IP data is referred to as an IP datagram in the present invention for convenience of explanation. At this time, the OMA BCAST service guide information can also be configured as an IP datagram through the same process as the NRT content / file.

Also, the NRT service signaling information necessary for receiving the NRT contents / files is transmitted through a service signaling channel, which is packetized according to a UDP (User Datagram Protocol) scheme, and the packetized UDP data is re- Packetized into UDP / IP data according to the IP method. 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 in an IP datagram having a well-known IP des- nation address and a well-known des- pination UDP port number, and is multicasted.

The A / V streaming for the mobile service includes an RTP header, a UDP header, and an IP header sequentially to form one IP datagram.

The adaptation layer collects the IP datagrams of the NRT service, the NRT service signaling channel, and the mobile service data to generate an RS frame. An IP datagram of the OMA BCAST service guide may also be included in the RS frame.

The length of the column (i.e., the number of rows) in the RS frame is set to 187 bytes. The length of the row (i.e., the number of columns) is N bytes and the N is the signaling information ≪ / RTI >

The RS frame is modulated into a predetermined transmission scheme, for example, a VSB transmission scheme in the mobile physical layer, and is transmitted to the reception system.

Meanwhile, the data structure used in the mobile broadcasting technology according to the embodiment of the present invention includes a data group structure and an RS frame structure. This will be described in detail as follows.

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

25 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. 25, only the RS parity data is allocated to some of the five segments preceding the M / H block B1 and the five segments after the M / H block B10, and the data is excluded from the A region to the D region 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. At this time, each M / H block is included in one of the A region and 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.

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

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

The M / H block B2 and the M / H block B9 in the data group of Fig. 25 have more interference of the main service data than the B area, and can not insert a long known data sequence 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. 25 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 to be transmitted to the signaling information area can be divided into two kinds of signaling 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 a fast service acquisition at a receiver, 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. 25, 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.

26 illustrates a structure of an RS frame including a mobile NRT service 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. One RS frame includes IP streams of each mobile service data or signaling data, and all RS frames include IP datagrams in a service map table (SMT) section. The SMT section data may be in the form of an IP stream or in another form. The data of the RS frame may include an IP datagram such as NRT content / file for NRT service, OMA BCAST service guide data, and the like.

In one embodiment, the service signaling channel for transmitting the SMT or the SMT includes an IP datagram having a well-known IP desination address and a well-known des- ping UDP port number included in a corresponding RS frame and receiving the same. do.

The data of the RS frame is allocated to a corresponding area of a plurality of data groups and transmitted.

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

The M / H payload may include at least one IP datagram of mobile service data and NRT service data. The M / H payload may include an SMT datagram. The M / H frame may include an IP datagram of OMA BCAST service guide data.

26 shows an example in which an IP datagram for SMT (IP Datagram 1) and two types of NRT service IP datagrams (i.e., IP datagram 2 and IP datagram 3) are allocated.

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

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

Meanwhile, the mobile service 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 one embodiment, mobile service data in one RS frame is all allocated to an A / B / C / D area or allocated to only one of an A / B area and a C / D area. 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 mobile service 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 the mobile service data in one RS frame is allocated to the A / B area in the data group and the mobile service data in the other RS frame is allocated to the C / D area in the corresponding data group, RS frames.

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 2 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 2, two bits are allocated to indicate the RS frame mode. Referring to Table 2, 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, primary RS Frame and the secondary RS frame. That is, when the RS frame mode value is 01, the data of the primary RS frame for region A / B for the A / B region is allocated and transmitted to the A / B region of the data group, And the data of the secondary RS frame (region C / D) for the region is assigned to the C / D region of the corresponding data group and is transmitted.

As with the allocation of the data groups, it is also an embodiment that the parades are allocated as far apart as possible in the subframe. 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 is applicable to all subframes within one M / H frame, which may be different for each M / H frame. That is, the M / H frame structure can be changed in units of M / H frames, which enables flexible adjustment of the ensemble data rate.

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

28 is a diagram illustrating a data transmission structure in a physical layer according to an embodiment of the present invention, in which FIC data is included in each data group and is 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. 27, there are two ensembles (NoG = 4, NoG = 3). Also, a certain portion (e.g., 37 bytes / data group) of each data group is used to transmit FIC data to which encoding is applied separately from the RS frame data channel. The FIC area allocated to each data group constitutes one FIC segment, and these FIC segments are interleaved on a subframe basis. For example, RS encoding and serial concatenated convolutional code (SCCC) encoding are applied to the RS frame data, and RS encoding and parallel concatenated convolutional coding (PCCC) encoding are applied to the FIC data . On the other hand, RS encoding and parallel concatenated convolutional code (PCCC) encoding are applied to the TPC data as well as the FIC data. In this case, (187 + P, 187) -RS encoding is applied to the RS frame data, (51,37) -RS encoding is applied to the FIC data, and the TPC data is One embodiment is applied. Here, P is the number of parity bytes.

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

That is, FIG. 29 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 29, 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.

FIG. 30 shows an embodiment of a bitstream syntax structure of an SMT section for providing signaling information on NRT service data included in and transmitted in the RS frame of FIG.

Here, the syntax is written in the form of an MPEG-2 private section for the sake of understanding, but the format of the data may be any form.

The SMT describes the signaling information (or the signaling information of the NRT service) and the IP connection information of the mobile service in the Ensemble in which the SMT is transmitted. The SMT also provides the broadcast stream information of the corresponding service using Transport_Stream_ID, which is a recognizer of the broadcast stream to which each service belongs. The SMT according to the embodiment of the present invention includes description information of each mobile service (or NRT service) in one ensemble, and other additional information may be included in a descriptor area.

As described above with reference to FIG. 30, the SMT section may be included and transmitted in the form of an IP stream in the RS frame. In this case, the RS frame decoders of the receiver to be described later decode the input RS frame, and output the decoded RS frame to the corresponding RS frame handler. Each RS frame handler divides the inputted RS frame into rows and constructs an M / H TP to output to the M / H TP handler.

On the other hand, examples of fields that can be transmitted through the SMT are as follows.

The table_id field (8 bits) is a field for identifying the type of the table, and it is known that the table section is a table section in SMT (table_id: An 8-bit unsigned integer number indicates that the type of table section being defined in Service Map Table (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 the private section (private_indicator: This 1-bit field shall be set to '1').

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

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). Here, the table_id_extension field includes an SMT_protocol_version 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 MSB is set to '1' and the remaining 7 bits are used as the parade_id value of the corresponding parade (ensemble_id: This 8-bit unsigned integer field in the range 0x00 to 0x3F Ensemble ID associated with this Ensemble. The value of this field shall be derived from the parade_id carried from the baseband processor of the physical layer subsystem, by using the parade_id of the associated parade for the least significant 7 bits, and using '0' for the most significant bit when the ensemble is performed over the primary RS frame, and using '1' for the most significant bit when the ensemble is performed over the secondary RS frame.

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

The current_next_indicator field (1 bit) indicates whether the transmitted SMT table section is currently applicable (current_next_indicator: A one-bit indicator, which when set to '1' indicates that the Service Map Table is currently applicable. If the table is not set to '0', then the table is not yet available and will be the next table to be valid. be sent. An update to the currently applicable table shall be signaled by the incrementing the version_number field.

The section_number field (8 bits) indicates the number of the current SMT section (section_number: This 8-bit field shall give the section number of this NRT Service Signaling table section. 0x00. The section_number shall be incremented by 1 with each additional section in the NRT Service Signaling table.

The last_section_number field (8 bits) indicates the last section number constituting the SMT table (last_section_number: This 8-bit field shall give the number of the last section (ie, the section with the highest section_number) this section is a part).

The num_services field (8 bits) indicates the number of services in the SMT section. (num_services: This 8 bit field specifies the number of services in this SMT section.). The SMT may include at least one mobile service in an ensemble including the SMT, may include at least one NRT service only, or may include both a mobile service and an NRT service. If only the NRT services are transmitted in the ensemble including the SMT, the number of NRT services included in the SMT can be indicated

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

The service_id field (16 bits) indicates a value that uniquely identifies the service. (A 16-bit unsigned integer number shall identify this service within the scope of this SMT section.) The service_id field value of one service does not change while the service is maintained. In order to avoid confusion at this time, if a service is terminated, the value of the service_id field of the service may not be used until a predetermined time elapses (The service_id of a service may not change throughout the life of the service. , it is recommended that a service is terminated, then the service_id for the service should not be used for another service. Here, if the service is an NRT service, the service_id will identify the NRT service

The Multi_ensemble_service field (2 bits) identifies whether the service is transmitted via one or more ensembles. In addition, the field identifies whether the service is only represented as part of the service being transmitted over the ensemble. That is, if the service is an NRT service, the field identifies whether the NRT service is transmitted via one or more ensembles (multi_ensemble_service: A two-bit enumerated field, which identifies whether the service is carried across more than one Ensemble. , this field shall identify whether or not the Service can be rendered only with the portion of Service carried through this Ensemble.).

The service_status field (2 bits) identifies the status of the service. Here, the MSB indicates whether the corresponding service is active ('1') or inactive ('0'), and the LSB indicates whether the corresponding service is hidden ('1') or not ('0'). If the service is an NRT service, the MSB of the service_status field indicates whether the corresponding NRT service is active ('1') or inactive ('0'), (&Quot; 0 ").

The SP_indicator field (1 bit) indicates whether or not the service is 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 service (see (1-bit field indicates that, when set to 1, service protection It is possible to provide a meaningful presentation of this service.

The short_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_service_name field indicates the short name of the service (short_service_name: The short name of the service, each character of which will be encoded in UTF-8 [29]. byte of the last byte of the byte pair, and the short_service_name_length field shall indicate 0x00). For example, if the service is a mobile service, it indicates a short name of the mobile service. If the service is a NRT service, it indicates a short name of the NRT service.

The service_category field (6 bits) identifies the type category of the service, as defined in Table 3 below. If the value of the corresponding field is set to a value indicating "informative only ", the value of that field is treated as an informative description of the category of the service. And the receiver is required to check the component_level_descriptors () field of the SMT to identify the actual category of the received service. For services with video and / or audio components, they have an NTP timebase component.

service_category Meaning 0x00 The service category is not specified by the service_category field. Look in the component_level_descriptors () to identify the category of service. 0x01 Basic TV (Informative only) - Look in the component_level_descriptors () to identify the specific category of service. 0x02 Basic Radio (Informative only) - Look in the component_level_descriptors () to identify the specific category of service. 0x03 RI service - Rights Issuer service as defined in Part # 6 [34] of this standard. 0x04-ox07 Not specified by the current version of this standard. 0x08 Service Guide - Service Guide (Announcement) as defined in Part # 4 [x] of
this standard. 0x09-0x0C Not specified by the current version of this standard. 0x0E NRT Service 0x0F- 0Xff [Reserved for future ATSC use]

In particular, in the context of the present invention, when the value of the service_category field has a value of '0x0E', for example, it indicates that the service is an NRT service. In this case, it can be seen that the signaling information of the service currently described in the SMT section is the signaling information of the NRT service.

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

When the IP_version_flag field (1 bit) is set to '1', the source_IP_address field, the service_destination_IP_address field, and the component_destination_IP_address field indicate the IPv6 address, and when set to '0', the source_IP_address field, the service_destination_IP_address field, and the component_destination_IP_address field indicate IPv4 addresses (IP_version_flag: A 1-bit indicator, which when set to '0' indicates that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses. The value of '1' for this field is reserved for possible future indication that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are for IPv6. Use of IPv6 addressing is not currently defined).

When the source_IP_address_flag field (1 bit) is set, 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 service_destination_IP_address_flag field (1 bit) is set, it indicates that the corresponding IP stream component is transmitted through an IP datagram having a target IP address different from the service_destination_IP_address. Therefore, when this flag is set, the receiving system uses component_destination_IP_address as the destination_IP_address and ignores the service_destination_IP_address field in the num_channels loop to access the corresponding IP stream component (service_destination_IP_address_flag: A 1-bit Boolean flag indicating that when set to '1 ', that a service_destination_IP_address value is present, to serve as the default IP address for the components of the Service).

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 indicating the source of the virtual channel. If the IP_version_flag field is set to '1', this field indicates a 32-bit IPv6 address indicating the source of the virtual channel (source_IP_address: this field shall be present to source_IP_address_flag is set to '1' and shall not be present If the source_IP_address_flag is set to '0'. If present, this field will contain the source IP address of all the IP datagrams carrying the components of this service. Possible use of IPv6 in the future, although IPv6 is not currently defined).

If the service is an NRT service, the Source_IP_address field is a source IP address of the same server that transmits all channels of the FLUTE session.

The service_destination_IP_address field (32 or 128 bits) needs to be interpreted when the service_destination_IP_address_flag is set to '1', but not when the service_destination_IP_address_flag is set to '0'. When the 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 virtual channel. When the 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 virtual channel. If the corresponding 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 (service_destination_IP_address: this field shall be present if the service_destination_IP_address_flag is set to '1 If the service_destination_IP_address is not present, then the component_destination_IP_address field shall be present for each component in the num_components loop. The conditional use of the 128-bit long address version of This field is useful for IPv6 in the future, although IPv6 is not currently defined). If the service is an NRT service, the service_destination_IP_Address field is signaled if there is a destination IP address of the session level of this FLUTE session.

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 service. At this time, the following field information can be provided for each component. Here, one component corresponds to one FLUTE session.

The essential_component_indicator field (1 bit), if set to '1', indicates that the component is a required component for mobile services. Otherwise, it indicates that the component 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 set to '1' to indicate that the component_destination_IP_address field exists for the corresponding component (component_destination_IP_address_flag: A 1-bit Boolean flag indicates 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. For an RTP stream, the destination UDP port number is incremented by 2, starting from the destination_UDP_port_num field value, to include the RTCP stream associated with the RTP stream (port_num_count: this field indicates the number of destination UDP ports associated with this UDP / IP stream component. The values of the destination UDP port numbers shall start from the component_destination_UDP_port_num field and shall be incremented by one, except in the case of RTP streams, when the destination UDP port numbers shall start from the component_estination_UPD_port_num field and shall be incremented by two, to allow for the RTCP streams associated with the RTP streams).

The destination_UDP_port_num field (16 bits) indicates the destination UDP port number for the corresponding IP stream component. For RTP streams, the value of destination_UDP_port_num is an even number, and the next higher value represents the destination UDP port number of the associated RTCP stream (component_destination_UDP_port_num: A 16-bit unsigned integer field, which represents the destination UDP port number for this UDP / IP stream For RTP streams, the value of component_estination_UDP_port_num shall be even, and the next higher value shall represent the destination UDP port number of the associated RTCP stream.

The component_destination_IP_address field (32 or 128 bits) indicates that the IP_version_flag field is set to '0', this field indicates a 32-bit destination IPv4 address for the corresponding IP stream component. If the IP_version_flag field is set to '1', this field indicates a 128-bit Destination IPv6 address for the corresponding IP stream component (component_destination_IP_address: this field shall be present if component_destination_IP_address_flag is set to '1' and shall not be When this field is not present, the destination address of the IP datagrams carrying this component of the M / H Service shall match the address in this field. The IPv6 address is the address of the M / H_service_destination_IP_address field, which is the address of the IPv6 address. currently defined).

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

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

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

Service_level_descriptors () are included in the service loop by the number corresponding to the value of the num_service_level_descriptors field, thereby providing additional information on the service. If the service is a mobile service, it provides additional information on the mobile service. If the service is a NRT service, it provides additional information on the NRT 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.

In the SMT of FIG. 30, a component_descriptor () as shown in FIG. 16 may be provided as component_level_descriptors ().

The component component descriptor () is used as one of the SMT component level descriptors component_level_descriptors (), and describes additional signaling information of the component.

Accordingly, the signaling information necessary for receiving the corresponding FULTE session in the mobile NRT service can be provided using the component_descriptor () descriptor of FIG.

For example, if the component_type field value of the component_descriptor () in FIG. 16 is 38, the component_data (component_type) field provides data for FLUTE file delivery as shown in FIG. The description of each field in Fig. 16 and Fig. 17 has been described above, and therefore, will not be described here.

In addition, the SMT in Fig. 30 can also provide media object related information.

In one embodiment, if the media object related information exists, the NRT_media_object_association_descriptor () shown in FIG. 12 is provided to the component level descriptor. In this case, the receiver parses all the descriptors included in the component level descriptor, and identifies the NRT_media_object_association_descriptor () using the identifier of the descriptor. The description of each field of the NRT_media_object_association_descriptor () and the process of extracting the media object related information in text form from the NRT_media_object_association_descriptor () will be omitted because it will be described with reference to the NST description in FIG. At this time, a media_object_association_indicator field (1 bit) may be allocated to the SMT in FIG. 30 to identify whether the NRT_media_object_association_descriptor () exists in the component loop.

In another embodiment, the media object related information may be provided using the component_descriptor () shown in FIG. At this time, the component_type field value may use one of the values between 43 and 71. In the present invention, 43 is allocated to provide the media object association information as component data. The numerical values shown above are only examples, and the numerical values do not limit the scope of the present invention. That is, if the component_type field value is 43, the component_data (component_type) field provides the component data for media object association information as shown in FIG. The description of each field in Fig. 17 will be referred to Fig. 12, and thus will not be described here.

In another embodiment, when the media object related information is provided using the component_descriptor () shown in FIG. 16, the value of the component_type field may be assigned to any value within the dynamic range (i.e., 96-127). In this case, the media object related information can be provided using the component data as shown in FIG. FIG. 19 is a diagram for explaining a method of assigning 0x2 or 0x4 to 0xF as the general_media_type field value in the component data and providing the media object related information in text form using the media_type_text () field and the decoding_parameters_text () field It is possible. In FIG. 19, the media_type_text_length field (8 bits) indicates the byte length of the following media_type_text () character string: (This field shall specify the length (in bytes) of the media_type_text () character string. The media_type_text () field indicates the media type that identifies the encoding format. That is, the encoding format of the stream corresponding to the general media type is displayed in text form. The decoding_parameters_text_length field (8 bits) indicates the length of the next decoding_parameters_text () character string. (This field shall specify the length (in bytes) of the decoding_parameters_text () character string.) The decoding_parameters_text () field indicates the decoding parameters of the stream corresponding to the general media type in text form.

The media_type_text () field and the decoding_parameters_text () field provide an encoding format and a decoding parameter in a text format expressed by a Multipurpose Internet Mail Extensions (MIME) type.

That is, by signaling through the component data bytes, it is possible to provide all the necessary information for receiving the FULTE session, receive the FDT through the FLUTE session, and receive the FLUTE session It is possible to acquire information about all the files transmitted through the network. Thus, it becomes possible to receive NRT service data.

In this way, the container information, encoding information, and decoding parameters of the media object, which are essential for rendering the content / files constituting the NRT service according to the present invention, are signaled to the corresponding NST for each component.

Meanwhile, the present invention can transmit container information, encoding information, and decoding parameters of a media object, which are essential for rendering the content / files constituting the NRT service, to the OMA BCAST service guide (SG) information. Accordingly, the receiving system extracts container information, encoding information, and decoding parameters of a media object, which are indispensable for rendering the corresponding content for each content, and can use it for rendering the corresponding content.

31 is an embodiment of a receiving system capable of receiving, storing, and reproducing NRT content for a mobile NRT service. 31, a solid line arrow indicates a data path, and a dashed arrow indicates a control signal path.

The receiving system of FIG. 31 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)

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

In FIG. 31 constructed as described above, the operation controller 2119 controls the operation of each block of the baseband processor 2110.

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, And receives 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 may receive main service data and mobile service data, which are real time data, and may receive non-real time (NRT) service data.

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 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 And outputs a sequence of known known data to the demodulator 2112, the equalizer 2113, and the operation controller 2119. 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) Data and signaling 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 is performed do.

The signaling decoder 2118 performs decoding of 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 the reverse of the transmitting side and outputs it to the operation 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 segment group in units of M / H frames input from the signaling decoder 2118 and outputs the FIC segment group 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 buffers table sections of the service signaling channel transmitted from the UDP datagram handler 2143, for example, SMT sections Analyze and process. The SMT information processed by the service signaling handler 2123 is also output to the service manager 2122.

The SMT section or the service signaling channel for transmitting the SMT section is received in a corresponding RS frame in the form of a UDP / IP packet having a well-known IP desination address and a well-known des- pination UDP port number . Thus, the receiving system can parse the SMT section and the descriptors of each SMT section without requiring any additional information.

The SMT section also provides signaling information (including IP connection 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.

If the service is an NRT service, connection information of a FLUTE session for transmitting content / files constituting an NRT service from the SMT and signaling information necessary for rendering the NRT service can be extracted. For example, information necessary for rendering the content / files of the NRT service transmitted from the SMT to each FLUTE session can be extracted. The information necessary for rendering the content / files of the NRT service may be container information, encoding information, or a decoding parameter of the media object.

The information parsed from the SMT is collected by the service manager 2122 and stored in the first storage unit 2124. The service manager 2124 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. Referring to the service map and the created service guide, the operation controller 2119 is controlled to receive a mobile service desired by the user, and the program guide is displayed on at least a part of the screen according to the input of the user .

The first control unit 2124 stores a service map and a service guide created in the service manager 2122. The first control unit 2124 extracts necessary data according to a request from the service manager 2122 and the EPG manager 2171 and transfers the extracted data to the service manager 2122 and / or the EPG manager 2171.

Based on the known data position information and the TPC data, the offset 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, To the respective blocks of the band 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 the Reed Solomon (RS) encoded and / or CRC (Cyclic Redundancy Check) encoded mobile service data or NRT service data from the block decoder 2115 do. The primary RS frame decoder 2116 can receive RS (Reed Solomon) encoding and / or cyclic redundancy check (CRC) encoded SMT section data or OMA BCAST SG data from the block decoder 2115.

That is, the primary RS frame decoder 2116 receives at least one of data other than the main service data, for example, mobile service data, NRT service data, SMT section data, and OMA BCAST SG data. 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 receives the mobile service data or the NRT service data encoded by RS (Reed Solomon) encoding and / or cyclic redundancy check (CRC) from the block decoder 2115. The secondary RS frame decoder 2117 can receive RS (Reed Solomon) encoding and / or cyclic redundancy check (CRC) encoded SMT section data or OMA BCAST SG data from the block decoder 2115.

That is, the secondary RS frame decoder 2117 receives at least one of data other than the main service data, for example, mobile service data, NRT service data, SMT section data, and OMA BCAST SG data. 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 is composed of 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 132 and transmits the header of the buffered M / Extracts and analyzes the IP datagram 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 comprises an IP datagram buffer and an IP datagram parser. The IP datagram handler 2141 buffers IP datagrams received from the TP handler 2133, extracts and analyzes the header of the buffered IP datagrams 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 transmitted in 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 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 command of a user input 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.

At this time, any one of the service signaling section handler 2123 and the service manager 2122 obtains the IP connection information for the FLUTE session for transmitting the content / file constituting the NRT service from the SMT component loop of FIG. 30 do. If the NRT_media_object_association_descriptor () is included in the component loop, the media object related information related to the FLUTE session is extracted from the NRT_media_object_association_descriptor (). The media object association information is provided in a text form of a MIME type. At this time, the media object related information is directly described in a text form in NRT_media_object_association_descriptor (), or in a form of text in a stream or a file. When the media object related information is transmitted in the form of a stream or a file, the NRT_media_object_association_descriptor () provides access information for receiving the stream or file. When the media object related information is transmitted in a file format, the NRT_media_object_association_descriptor () signals parameters necessary to receive a FLUTE session for transmitting the file. The media object association information includes container information, encoding information, decoding parameters of the media object, and the like, which are essential for rendering the content / files constituting the NRT service. In another embodiment, media object related information may be extracted using component_descriptor () included in the component loop. The process of extracting the media object related information has been described above in detail, and will not be described here.

Also, FLUTE level access information can be obtained using the component_descriptor (). Then, the ALC / LCT stream handler 2148 and the file decoder 2162 access the FLUTE file delivery session using the obtained FLUTE level access information, and collect files belonging to the session. When the files are collected, one NRT service is configured. The NRT service is stored in the third storage unit 2163 or outputted to the middleware engine 2164 or the A / V decoder 2161 so as to be displayed on the display device.

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

1 is a diagram illustrating a concept of providing a real-time service RT and a non-real time service (NRT) according to the present invention;

2 is a diagram showing a relationship between an NRT service, content, and a file according to the present invention;

3 is a diagram showing an embodiment of a protocol stack for Fixed NRT service according to the present invention.

4 is a diagram showing an embodiment of a bitstream syntax structure of a virtual channel table according to the present invention.

5 is a diagram illustrating an embodiment of a service type field value and its meaning in the virtual channel table of FIG. 4;

6 is a view showing another embodiment of the meaning of the value assigned to the service type field in the virtual channel table of Fig. 4 and its value

FIG. 7 is a diagram showing an embodiment of a bitstream syntax structure for an NRT service descriptor included in a virtual channel loop of the virtual channel table of FIG. 4; FIG.

8 is a view illustrating an example of a process of acquiring access information of an IP stream for transmitting an NRT service signaling channel using the PSI / PSIP table according to the present invention

9 is a diagram showing an embodiment of a bitstream syntax structure of an NST according to the present invention.

10 is a diagram showing one embodiment of the values assigned to the FLUTE session type field of the NST of FIG. 9 and the meanings of the values thereof; FIG.

FIG. 11 is a diagram showing an embodiment of a bitstream syntax structure for an NRT FLUTE file delivery descriptor included in a FLUTE session loop of the NST of FIG. 9; FIG.

FIG. 12 is a diagram showing an embodiment of a bitstream syntax structure for an NRT media object association descriptor included in a FLUTE session loop of the NST of FIG. 9; FIG.

13 shows an example of a value assigned to the object_association_type field of the NRT media object association descriptor of FIG. 12 and the meaning of the value thereof; FIG.

14 and 15 are diagrams showing still another embodiment of a bitstream syntax structure of an NST section according to the present invention.

16 is a diagram showing an embodiment of a bit stream syntax structure of component_descriptor () according to the present invention;

FIG. 17 is a diagram showing an embodiment of a bitstream syntax structure of FLUTE file delivery data using the component_descriptor () in FIG. 16; FIG.

FIG. 18 is a diagram showing an embodiment of a bitstream syntax structure of media object related information data using the component_descriptor () in FIG. 16; FIG.

FIG. 19 is a diagram showing another embodiment of a bitstream syntax structure of media object related information data using the component_descriptor () in FIG. 16; FIG.

20 is a flowchart illustrating an exemplary process of receiving an IP stream for transmitting an NRT service signaling channel according to the present invention.

FIG. 21 is a flow chart showing an embodiment of a process of receiving an NRT service according to the present invention.

22 is a diagram showing an embodiment of a bitstream syntax structure of an NRT content table (NCT) according to the present invention;

23 is a block diagram showing an embodiment of a receiving system for a fixed NRT service according to the present invention

24 is a view showing an embodiment of a protocol stack for a mobile NRT service according to the present invention;

25 is a diagram illustrating a structure of a data group according to an embodiment of the present invention,

26 illustrates a structure of an RS frame including a mobile NRT service according to an embodiment of the present invention,

27 is a diagram showing an example of an M / H frame structure for transmitting / receiving mobile service data according to the present invention,

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

29 is a diagram illustrating a hierarchical signaling structure according to an embodiment of the present invention,

30 is a diagram showing an embodiment of a bitstream syntax structure of an SMT section according to the present invention;

31 is a block diagram showing an embodiment of a receiving system for a mobile NRT service according to the present invention

Claims (16)

Generating a non-real time (NRT) service, which is a broadcast service transmitted before use, and generating signaling data for signaling the NRT service; And Wherein the NRT service and the signaling data are transmitted on a broadcast channel, Here, the NRT service includes one or more contents, one content includes one or more files, Wherein the one or more files are transmitted by one or more delivery sessions, Wherein the signaling data comprises information relating to the one or more delivery sessions, Wherein the signaling data further includes service status information for identifying a status of the NRT service, Wherein the service status information indicates whether the NRT service is active or inactive. The method according to claim 1, Wherein the content is downloadable for storage in a broadcast signal receiving system, Wherein the signaling data further includes download time information specifying a time during which the content is downloaded. The method according to claim 1, Wherein the signaling data further includes content update information specifying whether an update is expected for the content. A generator for generating NRT (Non-real time) service, which is a broadcasting service transmitted before use, and generating signaling data for signaling the NRT service; And Wherein the NRT service and the signaling data comprise a transmitter for transmitting on a broadcast channel, Here, the NRT service includes one or more contents, one content includes one or more files, Wherein the one or more files are transmitted by one or more delivery sessions, Wherein the signaling data comprises information relating to the one or more delivery sessions, Wherein the signaling data further includes service status information for identifying a status of the NRT service, Wherein the service status information indicates whether the NRT service is active or inactive. 5. The method of claim 4, Wherein the content is downloadable for storage in a broadcast signal receiving system, Wherein the signaling data further includes download time information specifying a time during which the content is downloaded. 5. The method of claim 4, Wherein the signaling data further includes content update information specifying whether an update is expected for the content. delete delete delete delete delete delete delete delete delete delete

Images