KR101759951B1 - Method for mapping between signaling information and announcement information and broadcast receiver - Google Patents

Abstract

An example of a non-real-time service providing method according to the present invention comprises: extracting identification information of first signaling information and second signaling information using a PSI / PSIP table; Receiving first signaling information and second signaling information based on the extracted identification information; Constructing and displaying a service guide using the first signaling information; Obtaining first content identification information for the selected content in the displayed service guide; Accessing a FLUTE session using the second signaling information and obtaining second content identification information matching the first content identification information from a connected FLUTE session; And receiving and storing at least one or more files constituting the content based on the acquired second content identification information.
According to the present invention, the transmission end may include signaling data for properly recognizing, receiving, and processing the NRT service provided by the receiver, and may properly process the received NRT service using the transmitted signaling data And provide the service guide to the user using the transmitted signaling data, and can accurately receive and process the content selected from the configured service guide using the signaling information.

Description

[0001] The present invention relates to a method and apparatus for mapping signaling information and announcement information,

The present invention relates to a method of signaling service type and detail information about a service transmitted through a non-real time (NRT) method over a terrestrial broadcasting network, And more particularly to a receiver that uses the service-related signaling information to acquire additional information about the corresponding NRT service, how to process the service and output it to a user, (application module). The present invention relates to a mapping method between signaling information and announcement information for NRT service and a broadcast receiver.

NRT service (Non Real Time service) is one of the potential applications to be utilized in the future DTV service. NRT is not literally real-time streaming, but transmits non-real-time transmission, storage and viewing operations, and transmits file-type content over extra bandwidth through terrestrial broadcast media. And the like.

It is an object of the present invention to define signaling data for an NRT service.

It is another object of the present invention to define a method for transmitting the defined signaling data.

It is still another object of the present invention to provide an NRT service access method for receiving signaling data for the NRT service transmitted from a receiver.

It is still another object of the present invention to provide a method for mapping a content identifier of the signaling data and an identifier of a content to which a selected content is transmitted in a receiver.

It is still another object of the present invention to provide a method of receiving a content selected from a service guide configured by using signaling data at a receiver and providing the received content to a user.

An example of a non-real-time service providing method according to the present invention comprises: extracting identification information of first signaling information and second signaling information using a PSI / PSIP table; Receiving first signaling information and second signaling information based on the extracted identification information; Constructing and displaying a service guide using the first signaling information; Obtaining first content identification information for the selected content in the displayed service guide; Accessing a FLUTE session using the second signaling information and obtaining second content identification information matching the first content identification information from a connected FLUTE session; And receiving and storing at least one or more files constituting the content based on the acquired second content identification information.

At this time, the identification information can be extracted using at least a virtual channel table (VCT), a data service table (DST), and a program map table (PMT) among the PSI / PSIP tables.

The files constituting the NRT service, the first signaling information and the second signaling information may be received after IP packetization, addressable section packetization, and MPEG-2 TS packetization are sequentially performed.

Also, the first signaling information may be an NCT, and the second signaling information may be an NST.

And the second content identification information may be extracted from the file description table (FDT) in the connected flute session.

And configuring and displaying a service guide using the received first signaling information.

And acquiring first service identifier information associated with first content identifier information acquired from the first signaling information with respect to the selected specific content item in the displayed service guide.

The method may further include extracting second service identifier information that matches the acquired first service identifier information from the received second signaling information.

An exemplary broadcast receiver according to the present invention extracts identification information of first signaling information and second signaling information using a PSI / PSIP table, and generates first signaling information and second signaling information based on the extracted identification information, A baseband processor for receiving the baseband signal; A first handler for constructing and displaying a service guide using the received first signaling information; A second handler for obtaining a first content identifier from the received first signaling information for the content selected in the indicated service guide; A third handler accessing a FLUTE session using the received second signaling information and obtaining a second content identifier matching the obtained first content identifier from the connected flute session; A control unit for receiving and storing at least one or more files constituting the content item based on the acquired second content identifier; And a storage unit for storing the received files.

At this time, the identification information can be extracted using at least a virtual channel table (VCT), a data service table (DST) and a program map table (PMT) among the PSI / PSIP tables.

The files constituting the NRT service, the first signaling information and the second signaling information may be received after IP packetization, addressable section packetization, and MPEG-2 TS packetization are sequentially performed.

Also, the first signaling information may be an NCT, and the second signaling information may be an NST.

And the second content identification information may be extracted from the file description table (FDT) in the connected flute session.

In addition, the first service identifier information associated with the first content identifier information acquired from the first signaling information with respect to the selected specific content item in the displayed service guide may be obtained.

And second service identifier information matching the acquired first service identifier information can be extracted from the received second signaling information.

According to the present invention,

First, the transmission terminal has an effect of including signaling data so as to appropriately recognize, receive, and process the NRT service provided by the receiver.

Second, the receiver has an effect of appropriately receiving and processing the received NRT service using the signaling data to be transmitted to the user.

Thirdly, the receiver has the effect of constructing and providing a service guide to the user by using the signaling data transmitted.

Fourth, the receiver has the effect of correctly receiving and processing the content selected from the configured service guide using the signaling information.

1 shows an example of a conceptual diagram for an NRT service,
2 is a block diagram of a receiving system constructed in accordance with an embodiment of the present invention,
FIG. 3 is a view for explaining a relationship between an NRT service, a content item and a file,
FIG. 4 illustrates a protocol stack for a fixed NRT service configured according to an embodiment of the present invention,
5 shows an example of an ATSC service type in relation to the present invention,
Figure 6 shows another example of an ATSC service type in relation to the present invention,
FIG. 7 illustrates a bitstream section of a TVCT table section configured according to an embodiment of the present invention,
FIG. 8 illustrates a bitstream syntax of a DST table section for identifying an NRT application configured according to an embodiment of the present invention,
9 is a diagram for explaining a signaling method when an NRT service is transmitted through an ATSC broadcasting system according to another embodiment of the present invention,
Figure 10 shows a flow chart for Figure 9,
11 and 12 illustrate a bitstream syntax of an NST extracted by a receiver from a received MPEG-2 TS constructed according to an embodiment of the present invention,
13 shows a bitstream syntax of an NRT_component_descriptor () constructed according to an embodiment of the present invention,
FIG. 14 illustrates a bitstream syntax of NRT_component_data_descriptor for FLUTE file delivery configured according to an embodiment of the present invention,
15 shows a bitstream syntax of an NCT section constructed according to an embodiment of the present invention,
16 is a flowchart illustrating a method of configuring NRT guide information and providing content according to another embodiment of the present invention,
17 illustrates an NRT service signaling structure constructed in accordance with another embodiment of the present invention,
FIG. 18 illustrates a bitstream syntax of an NRT content delivery channel details descriptor according to an embodiment of the present invention,
19 is a diagram for explaining an FDT scheme for mapping a file to a content_id according to an embodiment of the present invention,
20 is a diagram for explaining an FDT schema for mapping a file and a content_id according to another embodiment of the present invention, and FIG.
21 is a flowchart illustrating a process of processing an NRT service in a receiver according to an embodiment of the present invention.

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

Definitions of terms used in the present invention

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

NRT service concept map

1 shows an example of a conceptual diagram for an NRT service.

The broadcasting station transmits RT (Real Time) service according to the existing method. At this time, the broadcasting station can provide a non-real time (NRT) service by using the bandwidth to transmit the RT service or remaining in the process. Here, the NRT service may include news clips, weather information, advertisements, content for push VOD (Video On Demand), and the like.

However, in principle, the conventional DTV receiver, that is, the legacy device, is not affected by its operation by the NRT stream included in the channel. Therefore, the conventional DTV receiver has a problem in receiving and properly processing the NRT service provided by the broadcasting station.

On the other hand, the broadcast receiver according to the present invention, that is, the NRT device, can properly receive and process the NRT service combined with the RT service, thereby providing the viewer with various functions as compared with the conventional DTV receiver.

Here, the RT service and the NRT service are transmitted through the same or different DTV channels, and transmitted through MPEG-2 TP (Transport Packet) or IP datagram. Therefore, the receiver needs to distinguish between the two services transmitted over the same channel. For this purpose, the present invention describes defining and providing signaling information so that a receiver can receive an NRT service and properly process it. Here, the broadcasting station provides signaling information, and at least one unique PID may be assigned to distinguish the NRT service.

Receiving system

2 is a block diagram of a receiving system constructed in accordance with an embodiment of the present invention.

2 is a block diagram of a receiving system capable of receiving and processing an NRT service according to the present invention. The receiving system includes a baseband processor, an MPEG-2 service demultiplexer (MPEG-2) Service Demux, a stream component handler, a media handler, a file handler, and the like.

Hereinafter, each part of the receiving system of FIG. 2 will be described.

First, the baseband processor unit includes a tuner 201 and a VSB demodulator 202. The tuner 201 detects a VSB RF signal transmitted in the air (Over the air) and extracts a symbol. At this time, the tuner 201 is controlled by a service manager 228. The VSB demodulator 202 demodulates the VSB symbol extracted from the tuner 201 to recover meaningful data.

The MPEG-2 Service Demultiplexer (MPEG-2 Service Demux) includes an MPEG-2 Transport Packet (TP) Buffer / Parser 203, a PSI / (PSI / PSIP Section / Buffer) 204, a descrambler 205, an MPEG-2 TP demultiplexer 206 and a PVR storage 207 .

The MPEG-2 TP buffer / parser 203 buffers and restores the MPEG-2 TP transmitted through the VSB signal, and detects and processes the TP header.

The PSI / PSIP section / buffer 204 buffers and analyzes the PSI / PSIP section data transmitted through the MPEG-2 TS. Here, the analyzed PSI / PSIP data is collected by the service manager 226 and stored in a database (DB) in the form of a service map and guide data.

The descrambler 205 uses an encryption key or the like received from the CA stream handler 216 with respect to a packet payload to which a scramble is applied in the MPEG-2 TP , And restores the data of the payload.

The MPEG-2 TP demultiplexer 206 filters the TP to be processed by the receiver out of the MPEG-2 TP transmitted through the VSB signal or the MPEG-2 TP stored in the PVR storage 207, . Here, the MPEG-2 TP demultiplexer 206 may be controlled by the service manager 228 and the PVR manager 235.

The PVR storage unit 207 stores the received MPEG-2 TP using the VSB signal according to the user's request, and outputs the MPEG-2 TP according to the user's request. Here, the PVR storage unit 207 may be controlled by the PVR manager 235.

Next, the stream component handler unit includes a PES buffered / handler (PES) buffer / handler 208, an ES buffer / handler 209, a PCR handler (PCR) Handler 210, an STC 211, a DSM-CC section Buffer / Handler 212, an IP Datagram Buffer / Header Parser 213, A UDP Datagram Buffer / Handler 213, a CA Stream Buffer / Handler 214 and a Service Signaling Section Buffer / Handler 215 ).

The PES Buffer / Handler 208 buffers and restores the PES transmitted via the MPEG-2 TS.

The ES buffer / handler 209 buffers and restores an ES (Elementary Stream) such as audio data and video data transmitted in a PES format, and transfers the ES (Elementary Stream) to an appropriate A / V decoder 218.

The PCR handler 210 processes PCR data used for time synchronization of an audio stream and a video stream.

The STC unit 211 corrects the clock value of the A / V decoders 218 using the reference clock value transmitted through the PCR handler 210 so that time synchronization is performed.

The DSM-CC section buffer / handler 212 buffers and processes the DSM-CC section data for file transmission and IP datagram encapsulation transmitted through the MPEG-2 TP.

The IP datagram buffer / header parser 213 buffers and decompresses IP datagrams that are encapsulated via the DSM-CC addressable section and transmitted over the MPEG-2 TP. The IP datagram buffer / header parser 213 analyzes the header of each datagram through the restoration. Here, the IP datagram buffer / header parser 213 is controlled by the service manager 228.

The descrambler 214 restores the data of the payload using the encryption key or the like received from the CA stream handler 216 with respect to the payload when scrap bling is applied to the payload among the received IP datagrams.

The UDP datagram buffer / handler 215 buffers and restores the UDP datagrams transmitted through the IP datagram, and analyzes and processes the UDP header.

The CA stream buffer / handler 216 includes descrambling (e. G., An entitlement management message (EMM), entitlement control message (ECM), etc.) transmitted for a conditional access function transmitted via an MPEG- And the like. The output of the CA stream buffer / handler 216 is transmitted to the descrambler 214 to perform an encryption process of the MPEG-2 TP or IP datagram transmitting the AV data and the file data (File Data) do.

The service signaling section buffer / parser 217 processes the NST, NCT and its associated descriptors for signaling NRT services in connection with the present invention. The processed signaling information is transmitted to the NRT service manager 229.

The media handler section will be described as follows. Here, the media handler unit includes A / V decoders 218.

The AV decoders 218 decode the audio data and the video data transmitted through the ES handler 209 and process them so that they can be displayed to the user.

Next, the file handler section will be described as follows.

The file handler unit includes an ALC / LCT Buffer / Parser 219, an FDT Handler 220, an XML Parser 221, a File Reconstruction Buffer 221, (222) and a decompressor (223).

The ALC / LCT buffer / parser 219 buffers and restores the ALC / LCT data transmitted in the UDP / IP stream to analyze the header and header extension of the ALC / LCT. Here, the ALC / LCT buffer / parser 219 may be controlled by the NRT service manager 229.

The FDT handler 220 analyzes and processes the file description table (FDT) of the FLUTE protocol transmitted through the ALC / LCT session. And transmit the processed FDT to the NRT service manager 229. Here, the FDT handler 220 may be controlled by the NRT service manager 229.

The XML parser 221 analyzes the XML document transmitted through the ALC / LCT session and delivers the analyzed data to the appropriate modules such as the FDT handler 220 and the SG handler 227.

The file reconstruction buffer 222 restores the file transmitted in the ALC / LCT and FLUTE sessions.

The decompressor 223 performs a process of decompressing a file transmitted in the ALC / LCT and the FLUTE session, if the file is compressed.

The file decoder 224 decodes the file restored in the file reconstruction buffer or the decompressed file in the decompressor 223 or the file extracted in the file storage unit 225. [

The file storage unit 225 stores and extracts the received file. Here, the received file may include NRT content.

Finally, other parts except for the above-mentioned parts will be described as follows.

The middleware (M / W) engine 226 processes data such as a file, not an AV stream transmitted through a DSMCC section, an IP datagram, or the like, and transfers the processed data to the presentation manager 234.

The SG handler 227 collects and analyzes the service guide data transmitted in XML document form, and transmits the collected service guide data to the EPG manager 230.

The service manager 228 collects and analyzes the PSI / PSIP data transmitted through the MPEG-2 TS and the service signaling section data transmitted through the IP stream to create a service map, And stores it in a service map and a guide database (Service Map & Guide Database) to control access to a desired service by a user. The service manager 228 is controlled by an operation controller 230 and includes a tuner 201, an MPEG-2 TP demultiplexer 206, an IP datagram buffer / handler 213, an NRT service manager (229) and so on.

The NRT service manager 229 performs overall management of an NRT service transmitted in the form of an object / file through a FLUTE session on the IP layer. The NRT service manager 229 parses the signaling information transmitted from the service signaling section buffer / parser 217. The parsed signaling information may be transmitted to the service map & guide database 236 and stored. Also, the NRT service manager 229 transmits the NCT information related to the service guide in the signaling information to the EPG manager 230 to control the EPG data to be formed. Here, the NRT service manager 229 controls the FDT handler 220, the file storage unit 225, and the like. Accordingly, the NRT service manager 229 receives the FDT received from the FDT handler 220, parses the received FDT, and stores the received NRT content in a hierarchical structure hierarchically in the file storage 225 do. The NRT service manager 229 controls to extract the corresponding NRT content from the file storage unit 225 when the user selects the NRT service.

The EPG manager 230 receives the service guide data from the SG handler 227 and controls the EPG data to constitute and display EPG data.

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

The UI manager 232 transfers the user's input to the operation controller 233 through the user interface and starts the operation of the process for the service requested by the user.

The operation controller 233 processes a command of the user received via the UI manager 232 and manages the corresponding module manager to perform the corresponding action.

The presentation manager 234 outputs at least one of audio and video data output from the A / V decoder 218, file data output from the middleware engine 226, and EPG data output from the EPG manager 230, / Or provide it to the user via the screen.

Describe the relationship between NRT services, content items, and files

FIG. 3 is a view for explaining the relationship between the NRT service, the content item and the file.

Referring to FIG. 3, an NRT service may include at least one or more content items, and each content item may be composed of at least one or more file (s). Also, the content item may correspond to a program or an event in a real-time broadcast as an independently reproducible entity. Therefore, the NRT service refers to a group that can be served by a combination of the above-described content items, and corresponds to a channel concept in real time.

In this regard, in order to properly process the NRT service at the receiver, signaling for the corresponding NRT service is required. The present invention is intended to enable the NRT service received at the receiver to be properly processed by defining and providing the signaling information. However, the signaling information will be described later in more detail.

Protocol for Fixed NRT Service

The NRT service is divided into a fixed NRT service (Fixed NRT service) and a mobile NRT service (Mobile NRT service). Hereinafter, the fixed NRT service will be described as an example for convenience of explanation.

FIG. 4 illustrates a protocol stack for a fixed NRT service constructed according to an embodiment of the present invention.

4, a protocol stack for providing a fixed NRT service includes an IP datagram (IP datagram) including a signaling channel that provides NRT content items / files and NST and NCT using MPEG-2 TS format ) And PSI / PSIP data.

In FIG. 4, the fixed NRT service is packetized according to a UDP (User Datagram Protocol) scheme in the IP layer, and the UDP packet is packetized according to the IP scheme to become UDP / IP packet data. The packetized UDP / IP packet data is referred to as an IP datagram in this specification for convenience of explanation.

NRT content items / files are packetized according to the FLUTE scheme and packetized according to the ALC / LCT (Asynchronous Layered Coding / Layered Coding Transport) scheme. The ALC / LCT packet is wrapped in a UDP datagram and transmitted. The ALC / LCT / UDP packets are packetized according to the IP datagram format, and packetized into ALC / LCT / UDP / IP packets to become IP datagrams. The IP datagram is included in the MPEG-2 TS via DSMCC addressable sections (DSM-CC addressable sections) for transmission. Here, the ALC / LCT / UDP / IP packet also includes a FDT (File Description Table) as information on a FLUTE session.

A signaling information channel including an NRT Service Table (NST) and an NRT Content Table (NCT) is packetized according to the UDP scheme, and the UDP packet is packetized again according to the IP scheme to generate UDP / IP packet data , And becomes an IP datagram. The IP datagram is also included in the MPEG-2 TS via DSMCC addressable sections for transmission.

The PSI / PSIP table is separately defined and included in the MPEG-2 TS.

The MPEG-2 TS including the NRT content items / files, the signaling information channel and the PSI / PSIP data is modulated and transmitted according to a predetermined transmission scheme, for example, a VSB (vestigial side band) transmission scheme.

NRT service method

In connection with the present invention, the fixed NRT service utilizes the conventional ATSC terrestrial broadcast environment. That is, a fixed NRT service based on the method of transmitting an IP datagram through the DSM-CC addressable section can be provided, for example, in the following manner.

1. When transmitted over a Virtual Channel that contains audio and / or video:

In this case, the service type of the corresponding virtual channel may follow FIG. 5 as defined in the conventional ATSC standard. That is, it may follow the 0x04 indicating the ATSC Data only service of FIG. 5 or may be included in the conventional service type to identify the NRT service.

2. When transmitted over a virtual channel containing only NRT services:

As shown in FIG. 6, a new service type value may be allocated to signal the NRT application (0x08).

A terrestrial virtual channel table (TVCT)

FIG. 7 illustrates a bitstream section of a TVCT table section constructed in accordance with an embodiment of the present invention.

Referring to FIG. 7, the TVCT table section has a table format similar to the MPEG-2 private section, but the present invention is not limited thereto.

Therefore, the TVCT table section can be divided into a header, a body, and a trailer. The header portion extends from the table_id field to the protocol_version field. The transport_stream_id field is a 16-bit field. PAT 2 transport stream ID in the program association table. The num_channels_in_section field of the body part is an 8-bit field and specifies the number of virtual channels in the VCT section. Finally, the trailer part contains a CRC_32 field.

First, the header part will be described as follows.

The table_id field (8 bits) is set to 0xCD to identify that the table section is a table section constituting the TVCT.

If the section_syntax_indicator field (1 bit) is set to 1, it indicates that the section conforms to the general section syntax.

The private_indicator field (1 bit) is set to 1.

The section_length field (12 bits) specifies the number of bytes remaining in this section from immediately after the section_length field to the end of the section. The value of the section_length field can not be greater than 1021.

The table_id_extension field (16 bits) is set to 0x000.

The version_number field (5 bits) may have a value of zero.

The current_next_indicator field (1 bit), if set to 1, indicates that the table section is currently applicable.

The section_number field (8 bits) indicates the number of the corresponding table section in the TVCT sections.

The last_section_number field (8 bits) indicates the last table section of the TVCT sections.

The protocol_version field (8 bits) is an allowable function of this table type that carries parameters that are structured differently than those defined in the current protocol.

Next, the body part is explained.

This adds field information of a loop structure described later to each virtual channel defined in the num_channels_in_section field.

The short_name field (16 bits) represents the name of the virtual channel with a code value of 16 bits consecutively from 1 to 7.

The major_channel_number field (10 bits) represents the major channel number associated with the virtual channel.

The minor_channel_number field (10 bits) represents a minor or sub-channel number.

The modulation_mode field (8 bits) indicates the modulation mode for the transmitted carrier associated with the virtual channel.

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

The channel_TSID field (16 bits) represents the MPEG-2 transport stream ID associated with the transport stream carrying the MPEG-2 program referred to by the virtual channel.

The program_number field (16 bits) identifies the program number associated with the virtual channel defined in the MPEG-2 program association table (PAT) and the program map table (TS PMT).

The ETM_location field (2 bits) describes the presence and location of an extended text message (ETM).

The access_controlled field (1 bit), when set, indicates that the events associated with the virtual channel are controlled accesses. If the flag is set to 0, the event access is not restricted.

When the hidden field (1 bit) is set, the virtual channel indicates that the user can not access by the direct entry of the virtual channel number.

If the hidden_guide field is set to 0 for a hidden channel, it indicates that the virtual channel and its events disappear from the EPG display.

The serviec_type field (6 bits) indicates the type of service carried in the virtual channel. The NRT service may be identified through the corresponding field.

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

The descriptors_length field indicates the total length of the descriptor for the following virtual channel.

There is a descriptor field in which the event descriptor according to the present invention is included in the loop structure according to the length of the descriptors_length field.

As a body part in addition to the loop structure of the num_channels_in_section field, the additional_descriptors_length field indicates the total length of the following VCT descriptor list.

Finally, the trailer portion, the CRC_32 field, is a 32-bit field that, after processing the entire STT section, ensures zero output from the registers of the decoder defined in the MPEG-2 system And a CRC (cyclic redundancy check) value.

NRT content is transmitted through an IP mechanism and ATSC has established ATSC A / 90 and A / 92 standards to transmit IP datagrams through digital broadcast streams.

The DST can be received through the PID included in the service_location_descriptor, and the type of the application and the detailed information of the data broadcast stream transmitted through the channel can be known through the DST.

Referring to FIG. 5, the DST can be used to identify the NRT service, and the DST will be described as follows.

FIG. 8 illustrates a bitstream syntax of a DST table section to identify an NRT application constructed in accordance with an embodiment of the present invention.

Hereinafter, the semantics of the fields including the data_service_table_bytes structure are defined as follows. (The semantics of the fields comprise the data_service_table_bytes structure are defined below).

The sdf_protocol_version field (8 bits) describes the version of the Service Description Framework protocol (sdf_protocol_version: This 8-bit field shall be used to specify the version of the Service Description Framework protocol. The value of this field shall be set to 0x01. The value 0x00 and the values in the range 0x02 to 0xFF shall be ATSC reserved).

The application_count_in_section field (8 bits) describes the number of applications listed in the DST table section (application_count_in_section: This 8-bit field shall specify the number of applications listed in the Data Service Table section).

The compatibility_descriptor () field indicates that the structure contains a DSM-CC compatibility descriptor. Its purpose is to signal the application's compatibility requirements at the receiving platform to determine its ability to use the data service (compatibility_descriptor (): This structure shall contain a DSM-CC compatibility descriptor. signal compatibility requirements of the application so the receiving platform can determine its ability to use this data service.

The app_id_byte_length field (16 bits) describes the number of bytes used to identify the application (app_id_byte_length: This 16-bit field shall specify the number of bytes used to identify the application. The value 0x001 is forbidden. The value 0x001 is forbidden. The value 0x0001 is forbidden.

The app_id_description field (16 bits) describes the format and semantics of the next application identification bytes. For the NRT application according to the present invention, for example, 0x0003 may be newly allocated as shown in Table 1 below to identify the application as an NRT application (app_id_description: This 16-bit field shall specify the format and semantics of the Table 1 describes the values and associated formats.

Value Application Identifier Format 0x0000 DASE application 0x0001 ATSC reserved 0x0002 ATSCA / 92 Application 0x0003 NRT Application 0x0004-0x7FFF ATSC reserved 0x8000-0xFFFF User private

The app_id_byte field (8 bits) represents the byte of the application identifier (app_id_byte: This 8-bit field shall represent a byte of the application identifier).

The tap_count field (8 bits) describes the number of Tap () structures used by the application (tap_count: This 8-bit field shall specify the number of Tap () structures used by this application).

The protocol_encapsulation field (8 bits) describes the type of encapsulation that is used to transmit the specific data element referenced by the Tap () field (protocol_encapsulation: This 8-bit field shall specify the type of protocol encapsulation used to transmit the particular data element referred to by the Tap ()).

Value Encapsulated Protocol 0x00 Not in a MPEG-2 Transport Stream 0x01 Asynchronous non-flow controlled scenario of DSM-CC Download protocol encapsulated in DSM-CC sections 0x02 Non-streaming Synchronized Download protocol encapsulated in DSM-CC sections 0x03 Asynchronous multiprotocol datagrams in Addressable Sections using LLC / SNAP header 0x04 Asynchronous IP datagrams in Addressable Sections 0x05 Synchronized streaming data encapsulated in PES 0x06 Synchronous streaming data encapsulated in PES 0x07 Synchronized streaming multiprotocol datagrams in PES using LLC / SNAP header 0x08 Synchronous streaming multiprotocol datagrams in PES using LLC / SNAP header 0x09 Synchronized streaming IP datagrams in PES 0x0A Synchronous streaming IP datagrams in PES 0x0B Proprietary Data Piping 0x0C SCTE DVS 051 asynchronous protocol [19] 0x0D Asynchronous carousel scenario of DSM-CC Download protocol encapsulated in DSM-CC sections 0x0E Reserved for harmonization with another standard body 0x0F-0x7F ATSC reserved 0x80-0Xff User defined

The action_type field (7 bits) indicates the nature of the data referenced by the Tap () field. (action_type: This 7-bit field shall indicate the nature of the data referred to by the Tap).

The resource_location field (1 bit) describes the location of the Association Tag field that matches the association_tag value listed in the following Tap structure. If the corresponding field is set to 0, the matching association_tag exists in the PMT of the current MPEG-2 program. Otherwise, the matching association_tag exists in the DSM-CC Resource Descriptor in the Network Resources Table of the corresponding data service (resource_location: This 1-bit field shall specify the location of the Association Tag field matching the association_tag value listed in The following is an example of a DSM-CC Resource Descriptor within the Network (DSM-CC). This is the DSM-CC Resource Descriptor within the Network Resources Table of this Data Service).

The Tap () field is defined by a specific structure including, for example, the following fields. The tap_id field (16 bits) is used by the application to identify data elements. The value of tap_id is scoped by the value of app_id_byte fields associated with Tap () in DST. The tap_id value is selected by the data service provider. It is also used in applications to handle data elements (tap_id: This 16-bit field shall be used by the application to identify the data elements. The value of tap_id is scoped by the value of the app_id_byte fields associated with the Tap ) in the Data Service Table. The tap_id field is unique within an application. The tap_id value is selected by the data service provider at authoring time. The use field (16 bits) is used to specify the communication channel referred to by association_tag (use: This 16-bit field is used to characterize the communication channel referenced by the association_tag. Use of use values other than 0x0000 is beyond The scope of this standard. The use value 0x0000 indicates that this field is unknown10). The association_tag field (16 bits) uniquely identifies either the DSM-CC resource descriptor listed in the Network Resource Table or the data elementary stream listed in the PMT. The value of the corresponding field shall match the association_tag value of the association_tag_descriptor in the PMT of the data service (association_tag: This 16-bit field shall be uniquely identified either by a data elementary stream listed in the DSM-CC Resource Descriptor list In the latter case, the value of this field shall match the association_tag value in the commonDescriptorHeader structure of the association_tag value of an association_tag_descriptor. a DSM-CC Resource Descriptor in the Network Resource Table of the data service). The Selector () field describes the particular data element available in the communication channel or data elementary stream referenced by the association_tag field. In addition, the selector structure may indicate the protocol required for the corresponding data element (selector (): This structure shall specify a particular data element available in a data elementary stream or a communication channel referenced by the association_tag field. In addition , the selector structure may indicate the protocol required for acquiring this data element).

The tap_info_length field (16 bits) describes the number of bytes of descriptors of the field following the field (tap_info_length: This 16-bit field shall specify the number of bytes of the descriptors following the tap_info_length field).

The descriptor () field follows the descriptor format (descriptor (): This structure shall follow the descriptor format).

The app_info_length field (8 bits) describes the number of bytes of descriptors following the corresponding field (app_info_length: This 8-bit field shall specify the number of bytes of the descriptors following the app_info_length field).

The descriptor () field follows the descriptor format (descriptor (): This structure shall follow the descriptor format).

The app_data_length field (16 bits) describes the length of the app_data_byte fields in bytes (app_data_length: This 16-bit field shall specify the length in bytes of the following app_data_byte fields).

app_data_byte (8 bits) represents 1 byte of private data fields other than the input parameters related to the application (app_data_byte: This 8-bit field shall represent one byte of the input parameters and other private data fields associated with the application) .

The service_info_length field (8 bits) describes the number of bytes of the following descriptors (service_info_length: This 8-bit field shall specify the number of bytes of the descriptors in the service_info_length field).

The descriptor () field follows the descriptor format (descriptor (): This structure shall follow the descriptor format).

The service_private_data_length field (16 bits) describes the length in bytes of the private fields (service_private_data_length: This 16-bit field shall specify the length of the private fields to follow).

The service_private_data_byte field (8 bits) represents the private field as one byte (service_private_data_byte: This 8-bit field shall represent one byte of the private field).

After identifying the NRT application by the above-described method, an IP stream containing a well-known IP address carrying NRT service signaling data transmitted through an IP layer is searched through Tap information.

If the protocol_encapsulation value is 0x04, the asynchronous IP datagram is transmitted. If the selector_type is 0x0102, the device_id value indicating the destination address is transmitted through selector_bytes. The multiprotocol_encaplsulation_descriptor is used to correctly interpret the selector_bytes value, signaling the number of valid bytes in the device_id value.

As a result, the multicast address (or address range) of the IP datagram transmitted through the corresponding PID can be known through the Tap information.

It is confirmed that a well-known IP address carrying NRT service signaling data is loaded in the Tap, receives it first, and receives an IP packet.

The NRT service signaling data is extracted from the IP packet and transmitted to the NRT application manager (NRT Application Manager) to process the NRT service signaling data.

As described above, the NRT service signaling channel is multicasted in an IP datagram through a well-known IP address.

FIG. 9 illustrates a signaling method for transmitting an NRT service through an ATSC broadcasting system according to another embodiment of the present invention, and FIG. 10 illustrates a flowchart of FIG.

FIG. 9 shows a method of constructing a separate NRT service signaling channel through an IP terminal. In this case, the NRT service signaling channel is multicast wrapped in an IP datagram through a well-known IP address. The signaling structure in this case is as shown in Fig. That is, it can be seen that there is a separate NRT service signaling channel as an IP multicast stream, as opposed to all signaling in the PSIP stage.

Referring to FIG. 10, when the receiver is powered on and a default channel or a channel by a user is selected (S1001), the receiver receives a Terrestrial Virtual Channel Table (TVCT) or a Program Map Table (S1002).

In this regard, the information on the stream constituting each virtual channel is signaled to the Service_location_descriptor of the TVCT or the ES_loop of the PMT.

Accordingly, the receiver parses the service_type in the received TVCT to determine the type of service provided on the selected channel (S1003). For example, if the value of the service_type is 0x02, it indicates that the service is a digital A / V / Data service type, if the service_type is 0x04, it is a data only service type, and if it is 0x08, .

If it is determined in step S1003 that the corresponding service type is not a general A / V service, the service_location_descriptor is parsed in the channel loop of the TVCT to extract the PID (0x61) of the DST (Data Service Table) (S1004).

Then, the DST is received using the extracted PID (S1005).

It is determined whether the corresponding service provided through the selected channel from the received DST is an NRT service (S1006). Here, the determination of whether or not the NRT service is available can be determined by checking the app_id_description in the DST. For example, if the value of app_id_description is 0x0003, it can be known that the corresponding service is an NRT application.

If it is determined in step S1006 that the service is an NRT service, a Tap including an NRT service signaling channel is extracted (S1007), and a stream_PID including an association_tag of the Tap on the PMT is extracted (S1008).

The stream of the PID is received and the DSM-CC addressable section is processed (S1009).

Then, an IP packet is received from a well-known IP address of the NRT service signaling channel (S1010), and the NRT service signaling data in the received IP packet is processed to provide an NRT service (S1011).

After identifying the existence of the NRT application in the virtual channel, the IP stream containing the well-known IP address carrying the NRT service signaling data transmitted through the IP layer is searched through the Tap information .

If the Protocol_encapsulation value is 0x04, the asynchronous IP datagram is transmitted. If the Selector_type is 0x0102, the device_id value indicating the destination address is transmitted through selector_bytes. The multiprotocol_encaplsulation_descriptor is used to correctly interpret this selector_bytes value, signaling the number of valid bytes in the device_id value.

As a result, the PID of the transport stream carrying the corresponding data can be known through the Tap information for the multicast address (or address range) of the IP datagram. It is confirmed that a well-known IP address carrying NRT service signaling data is loaded in the Tap, receives it first, and receives an IP packet.

In the next step, the NRT service signaling data is extracted from the IP packet and transmitted to the NRT application manager (Application Manager) to start the service.

NST (NRT Service Table) & NCT (NRT Content Table)

Hereinafter, the NST, the NCT and the accompanying descriptors transmitted through the signaling information channel in order to provide information for signaling an NRT service will be sequentially described.

As described above with reference to FIG. 3, the NST / NCT table section may be included and transmitted in the form of an IP stream in a virtual channel.

Examples of fields to be transmitted through the NST are as follows. 11 and 12 illustrate a bitstream syntax of an NST constructed according to an embodiment of 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.

The NST / NCT describes service information and IP connection information in a virtual channel through which the NST / NCT is transmitted, and uses the Transport_Stream_ID, which is a recognizer of a broadcast stream to which each service belongs, It also provides stream information. The NST according to this embodiment includes description information of each fixed NRT service in one virtual channel, and other additional information may be included in the descriptor area.

The table_id field (8 bits) is a field for identifying the type of the corresponding table section. Through this field, it can be known that the corresponding table section is a table section constituting the NST (table_id: An 8-bit unsigned integer number that indicates the type of table section 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 a range of remaining fields (table_id_extension: This is a 16-bit field and is table-dependent. 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 the protocol version for informing the NRT NST to which parameters with different structures from those defined in the current protocol are transmitted (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. If the NST_protocol_version is not present, the NST_protocol_version may be used. standard to 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 table section is currently applicable (current_next_indicator: A one-bit indicator, which when set to 1 indicates that the NRT Service Table sent is currently applicable. An update to the currently available table is currently set to 0, which will not indicate that the table has not yet been applied to the table. applicable table shall be signaled by incrementing the version_number field).

The section_number field (8 bits) represents the section number of the section in which the table section constitutes the NST table (section_number: This 8-bit field shall give the section number of this NRT Service table section. The section_number of the first section The NRT Service table shall be 0x00. The section_number shall be incremented by 1 with each additional section in the NRT Service table.

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) this section is a part).

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

The channel_TSID field (16 bits) represents the MPEG-2 transport stream ID associated with the transport stream carrying the MPEG-2 program referred to by the virtual channel.

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

Meanwhile, the NST according to the present embodiment provides information on a plurality of fixed NRT services using a for loop. Hereinafter, the following field information can be provided for each fixed NRT service.

The NRT_service_status field (2 bits) identifies the status of the mobile service. Here, the MSB indicates whether the corresponding mobile service is active (1) or inactive (0), and the LSB indicates whether the corresponding mobile service is hidden (1) or not (0). If the mobile service is an NRT service, it will identify the state of the corresponding NRT service (NRT_service_status: A 2-bit enumerated field that will identify the status of this NRT service. (when set to 1) or inactive (when set to 0) and the least significant bit is known to be NRT Service is hidden (when set to 1). , and ordinary receiving devices should ignore them.

The SP_indicator field (1 bit) indicates if a service protection applied to at least one of the components necessary for providing a meaningful presentation of the mobile service is set (SP_indicator: , when set, that service is applied to at least one of the components needed to provide a meaningful presentation of this NRT Service).

The CP_indicator field (16 bits) indicates if the content protection applied to at least one of the components necessary for providing a meaningful presentation of the mobile service is set (CP_indicator: A 1-bit field) , when set, that content 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) is an indicator for uniquely identifying a corresponding NRT service within the range of the NRT broadcast. The NRT_service_id does not change throughout the corresponding service. Here, if the service is terminated to avoid confusion, the NRT_service_id for the service will not be used for other services until a suitable time has elapsed (NRT_service_id: A 16-bit unsigned integer number that will uniquely identify the NRT Service within The NRT_service_id is a service that will not be used for another service until the end of the service. after a suitable interval of time has elapsed).

The short_NRT_service_name_length field (3 bits) indicates the number of byte pairs in the short_NRT_service_name field (short_NRT_service_name_length: A three-bit unsigned integer indicating that the number of byte pairs in the short_NRT_service_name field. The BIT column for the short_NRT_service_name field. When there is no short name of this NRT service, the value of this field shall be 0).

The short_NRT_service_name field indicates the short name of the NRT service. If there is no short name for the NRT service, the corresponding field will be filled with nulls (short_NRT_service_name: The short name of the NRT Service.) When there is no short name of this NRT Service, this field will be filled with NULLs (0x00).

The NRT_service_category field (6 bits) identifies the type of service to be transmitted in the IP service. The IP service may include an NRT service (NRT_service_category: A 6-bit enumerated type field that will identify the type of service carried in this IP service).

The num_components field (5 bits) describes the number of IP stream components 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 (IP_version_flag: A 1-bit indicator, which when set to 0 indicates that source_IP_address, NRT_service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses. The value of this field is reserved for possible future indication that source_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).

The NRT_service_destination_IP_address_flag field (1 bit) has an NRT_service_destination_IP_address field to provide a default IP address for the components of the NRT service if the flag is set to 1 (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).

If source_IP_address_flag is set to 1, the source_IP_address field (128 bits) is present, but if source_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 transmitting 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 present the source_IP_address_flag is set to 0 If the IP address of the IP datagram is the same as the IP address of the IP datagram, although IPv6 is not currently defined).

When the source_IP_address_flag is set to 1, the source_IP_address field is present, but if the source_IP_address_flag is set to 0, the NRT_service_destination_IP_address field (128 bits) will not have the source_IP_address field. If the corresponding source_IP_address field does not exist, 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. The 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 if 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 address is not currently defined).

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

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 when set to 1, indicates that 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 destination UDP port numbers are 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. 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 it is set to 1 (component_destination_IP_address_flag: A 1-bit Boolean flag that indicates when the component_destination_IP_address is present 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 component_destination_IP_address field (128 bits) will not exist. If the corresponding field is present, the corresponding field will contain the source IP address of all IP datagrams transmitting 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 not defined (component_destination_IP_address: this field shall be present if component_destination_IP_address_flag is set to 1 and shall not If this field is present, the destination address of the IP datagrams is the address of this field. If the field is not present, The IP datagrams carrying this component shall match the address in the NRT_service_destination_IP_address field. The conditional use of the 128 bit-long address is supported by IPv6.

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) provides the number of descriptors that provide additional information for the IP stream component (num_component_level_descriptors: A 16-bit unsigned integer field, which represents the number of descriptors providing additional information for the IP stream component, may be included).

The component_level_descriptors field identifies one or more descriptors providing additional information for the corresponding IP stream component (component_level_descriptors: one or more descriptors providing additional information for this IP stream component, may be included).

The num_NRT_service_level_descriptors field (4 bits) describes the number of NRT service level descriptors for the service (num_NRT_service_level_descriptors: This 4 bits field specifies the number of NRT service level descriptors for this service).

The NRT_service_level_descriptor () identifies one or more descriptors that provide additional information for that NRT service. Here, the concrete service type for the NRT service can be informed. The specific service type may include, for example, a portal service for providing web contents, a push VOD, an A / V download, etc. (NRT_service_level_descriptor (): Zero or more descriptors providing additional information for this NRT Service, may be included ).

The num_virtual_channel_level_descriptors field (4 bits) describes the number of virtual channel level descriptors for the virtual channel (num_virtual_channel_level_descriptors: This 4 bit field specifies the number of virtual channel level descriptors for this virtual channel).

The virtual_channel_level_descriptor () indicates a descriptor providing additional information about the virtual channel described by the NST (virtual_channel_level_descriptor (): Zero or more descriptors providing additional information for the virtual channel which NST describes may be included).

The NRT service is transmitted through the FLUTE, and the connection information on the NST table is linked to the FLUTE session information as follows. Source_IP_address is the source IP address of the same server that is sending all the channels of the FLUTE session. NRT_service_destination_IP_Address is signaled when there is a destination IP address of the session level of this FLUTE session.

A Component can be mapped to a channel in a FLUTE session, and a separate destination IP address for each channel (different from the signaled IP address) can be signaled via component_destination_IP_address. In addition, the destination port number can be signaled through the component_destination_UDP_port_num and the number of destination ports starting from the component_destination_UDP_port_num through the port_num_count can be additionally specified.

By specifying a plurality of ports, a plurality of channels can be configured for one destination IP address. Here, one component can designate a plurality of channels. In general, however, it is desirable to distinguish channels through a destination IP address. Here, one channel can be considered to be mapped to one component.

The content items / files for the NRT service are transmitted via FLUTE and signal the corresponding FLUTE session information using the access information on the NST table. FIG. 13 shows a bitstream syntax of an NRT_component_descriptor () constructed according to an embodiment of the present invention.

NRT_component_descriptor () will appear in the component descriptor loop of each component of each NRT service in the NST. And all parameters in the descriptor correspond to the parameters used for the components of the NRT service (An NRT_component_descriptor () shall appear in the component descriptor loop of each component of each NRT service in the NST and all parameters in the descriptor shall correspond to the parameters of the NRT Service.

Hereinafter, each field information transmitted through the NRT_component_descriptor of FIG. 13 will be described.

The descriptor_tag field (8 bits) identifies that the corresponding descriptor (0x8D) is an NRT_component_descriptor (descriptor_tag: This 8-bit unsigned integer shall have the value, identifying this descriptor as the NRT_component_descriptor).

The descriptor_length field (8 bits) describes the length (in bytes) from the field immediately following the field to the end of the descriptor (descriptor_length: This 8-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor).

The component_type field (7 bits) 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 one of the values shown in Table 3 below, which is assigned by this specification. Or a dynamic value. For the components that make up the media being transmitted via RTP, the values in this field will match the values in the payload_type in the RTP header of the IP stream that is transmitting the component (component_type: This 7-bit field shall identify the encoding format of the The value may be any of the values assigned by IANA for the payload_type of an RTP / AVP stream [10], or it may be any of the values in [3] value in the range 96-127. For components of media carrying via RTP, the value of this field shall match the value in 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. In order to further signal the parameters to be described below for the FLUTE session when transmitting the NRT service stream on the FLUTE basis, the component_type 38 defined for the FLUTE component in the ATSC may be used as shown in Table 3, The value 43, which is newly defined as a component_type for NRT transmission, may be used.

component_type Meaning 0-34 Assigned or reserved by IANA, except that 20-4, 27, and 29-30 are unassigned 35 H.264 / AVC video stream component (assigned by ATSC use) 36 SVC enhancement layer stream component (assigned by ATSC use) 37 HE AAC v2 audio stream component (assigned by ATSC use) 38 FLUTE file delivery session (assigned by ATSC use) 39 STKM stream component (assigned by ATSC use) 40 LTKM stream component (assigned by ATSC use) 41 OMA-RME DIMS stream component (assigned by ATSC use) 42 NTP timebase stream component (assigned by ATSC use) 43-71 [Unassigned by IANA and reserved by ATSC use] 72-76 Reserved by IANA 77-95 Unassigned by IANA 96-127 Designated by IANA for dynamic use

The num_STKM_streams field (8 bits) identifies the number of STKM streams associated with the component (num_STKM_streams: An 8-bit unsigned integer field that will identify the number of STKM streams associated with this component).

The STKM_stream_id field (8 bits) identifies the STKM stream with the keys to decrypt the corresponding protected component obtained. Herein, the STKM_stream_id field is referred to in the component descriptor for the STKM stream (STKM_stream_id: An 8-bit unsigned integer field that will identify an STKM stream where keys to decrypt this protected component can be obtained by reference to the STKM_stream_id in the component descriptor for the STKM stream).

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

The File Delivery Table (FDT) of the FLUTE sessions is used to convey the item lists of all the content items and provides the size, data type and other information of the items related to acquiring the items (the FDT of the FLUTE sessions, and other information relevant to the acquisition of the items).

Accordingly, the present invention acquires information for connecting a FLUTE session through which the corresponding content is transmitted using the NST to receive the content selected from the service guide configured using the NCT. Then, we want to map the information about the NCT content item to the information about the file transmitted through the corresponding FLUTE session. Here, the identification of the service including the selected content item can be identified through the NRT_service_id of the NST described above. 3, in order to know more specifically one or more content item (s) included in each NRT service and files belonging thereto, information about a FLUTE session in which the corresponding content item (s) is transmitted, More specifically, a mapping with the content identifier in the FDT information for the FLUTE session is required.

The NRT service is transmitted through the FLUTE, and the connection information on the NST table is linked to the FLUTE session information as follows. Source_IP_address is the source IP address of the same server that is transmitting all the channels of the FLUTE session. NRT_service_destination_IP_Address is signaled when there is a destination IP address of the session level of this FLUTE session.

A Component can be mapped to a channel in a FLUTE session and can signal a separate destination IP address for each channel (different from the IP address signaled on a per-session basis) via component_destination_IP_address. In addition, the destination port number can be signaled through the component_destination_UDP_port_num and the number of destination ports starting from the component_destination_UDP_port_num through the port_num_count can be additionally specified.

By specifying a plurality of ports, a plurality of channels can be configured for one destination IP address. In this case, one component specifies a plurality of channels. However, in general, it is recommended to distinguish channels through Destination IP address. In this case, one channel is mapped to one component.

You can use component_attribute_byte to signal additional attributes of the components that make up the session. Additional parameters needed to signal the FLUTE session can be signaled through it.

In this regard, in order to signal a FLUTE session, parameters are required, and these parameters have mandatory parameters that are essential and optional parameters that are relevant to the FLUTE session. First, the required parameters include a source IP address, a number of channels in the session, a destination IP address and port number for each channel in the session, (TSI) of the session, and the start time and end time of the session parameters, and the corresponding session Optionally relevant parameters in relation to the FEC include: FEC Object Transmission Information, the first received information of the session including the files of interest (some information that tells the receiver that the interest is in the first place, And a Bandwidth specification parameter.

Of these, the number of channels of the session may be explicitly provided, or may be obtained by summing the number of streams constituting the session. The start time and the end time of the session can be signaled through the NST proposed in the present invention among the parameters, and the source IP address, the destination IP address and the port number for each session in the session, the number of channels in the session can be signaled.

14 shows a bitstream syntax of NRT_component_data_descriptor for FLUTE file delivery configured according to an embodiment of the present invention.

One NRT service may be included in multiple FLUTE sessions. Each session may be signaled using one or more FLUTE component descriptors that depend on the IP addresses and ports used for the session (A single NRT service may contain multiple FLUTE sessions. Each session may be signaled using one or more FLUTE component descriptors, depending on the IP addresses and ports used for the sessions.

Each field of the NRT_component_data_descriptor will be described in detail as follows.

The TSI field (16 bits) indicates the TSI of the FLUTE session (TSI: A 16-bit unsigned integer field, which will be the TSI of the FLUTE session).

The session_start_time field indicates the time at which the FLUTE session starts. If the value of the field is all 0, the 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 will be interpreted to mean that the session has already started).

The session_end_time field indicates the time at which the FLUTE session ends. If the value of the field is all 0, the 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 will be interpreted to mean that the session continues indefinitely.

The tias_bandwidth_indicator field (1 bit) indicates flags that contain 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 (tias_bandwidth_indicator: A 1-bit field that flags 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) is a flag including AS (Application Specific) bandwidth information. 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 (as_bandwidth_indicator: A 1-bit field that flags the inclusion This field shall be set to 1 to indicate the AS bandwidth field is present, and 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) information is provided (FEC_OTI_indicator: A 1-bit indicator indicating whether FEC Object Transmission Information is provided).

The tias_bandwidth field indicates the maximum TIAS bandwidth. (tias_bandwidth: This value will be used for the next one-thousandth of the Transport Independent Application Specific maximum bandwidth, second)).

The as_bandwidth field will have the value of the AS maximum bandwidth (as_bandwidth: This value will be the application specific maximum bandwidth).

The FEC_encoding_id field indicates the FEC encoding ID used in the corresponding FLUTE session (FEC_encoding_id: FEC encoding ID used in this FLUTE session).

The FEC_instance_id field indicates the FEC instance ID used in the corresponding FLUTE session (FEC_instance_id: FEC instance ID used in this FLUTE session).

By signaling the above parameters through the FLUTE component data bytes, it is possible to provide all the necessary information for receiving the FULTE session. Through this session, the FDT is received and the FLUTE session data A method of acquiring information on all files transferred and receiving these files can be used.

This FLUTE component descriptor can be passed through the Component_level_descriptor loop of the NST. In the case of a plurality of FLUTE channels, TSI, session_start_time, session_end_time, etc., which are session level parameters, must be signaled only once. Therefore, FLUTE component descriptors may be transmitted through a Component_level_descriptor loop only in one component of several channels.

Next, the NCT will be described as follows.

15 shows a bitstream syntax of an NCT section constructed in accordance with an embodiment of the present invention.

Hereinafter, an NRT content transmitted per NRT content delivery channel signaled through the NST will be described with respect to an NRT Content Table (NCT) related to signaling / announcement.

In Fig. 15, an NCT is newly defined to signal NRT contents. However, this is an embodiment and other schemes can be considered. The NRT content transmitted through a specific NRT content delivery channel can be signaled through the NCT. Hereinafter, each field information constituting the NCT section will be described in more detail.

The table_id field (8 bits) identifies that the corresponding table section is a table section constituting the NCT.

The NRT_service_id field describes the service_id of the NRT content delivery channel that delivers the content described by the NCT.

The version_number field represents the version number for the NCT. Therefore, the receiver can know whether the NCT contents have changed by using version_number.

The num_contents_in_section field is the number of content described by the NCT. indicates the number of contents (or files) to be transmitted through the virtual channel described by source_id.

The content_version field can know the version number of the content (or file) having a specific content_id value. That is, when the content_id of the file received and stored by the receiver is 0x0010, if the same content, that is, a file whose content_id value is 0x0010 is transmitted and the content_version is different from the previously received and stored content, To replace or replace the previously stored content. In the present embodiment, the serial number indicating the version of the release is referred to, but the published (released) time can be directly expressed. At this time, it is possible to use a new field that can express a published time when the publish time is difficult to express in the content_version field.

The content_id field is an ID value that can uniquely identify the content (or file) to be received and stored.

The content_available_start_time field and the content_available_end_time field inform the start time and the end time of the FLUTE session in which the content can be received.

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

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

The content_delivery_bit_rate field indicates a transmission bit rate at which the content (or file) is transmitted and means a target bit rate. That is, it indicates how much bandwidth the service provider or the broadcasting station should allocate when transmitting the content. With this information, the receiver can know the minimum time required to receive the file using the content_size and content_delivery_bit_rate. That is, the time required to receive the content can be estimated and the corresponding information can be provided to the user. The minimum required time is obtained by calculating (conent_size * 8) / (content_delivery_bit_rate) )to be.

The content_title_length field indicates the length of content_title_text () in bytes. This allows the receiver to know how many bytes of data to read in order to get the content_title_text () information correctly.

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

For example, one or more NRT channel (s) may be configured as a single channel in a method of constructing the NST described above.

In the present specification, an NRT channel can be configured as an NRT service unit and one or more FLUTE sessions for transferring files to a FLUTE.

In general, a FLUTE session can be uniquely identified / referenced using parameters such as TSI, IP, and port address, and is bound to session_start_time and session_end_time in time.

When configuring the table, use session_start_time and session_end_time to annunce the FLUTE session during this time.

Information on all NRT channels to be transmitted as well as the current NRT channel can be configured into a single table. It can be divided into a method of dividing the current NRT channel into a current period (from a current period) and a future period (a period defined after the current period) (For example, 24 hours), then within a predetermined time (for example, 24 hours) thereafter, and then into three sections, each of which can be configured as a separate table.

Also, it is possible to distinguish whether the guide information about the currently receivable content or the guide information about the content that can be received in the future by using the table_id. This is a method for separating the NRT service that can be received within a short time range from the present time and the services that can be received after that time into separate tables.

Upon receiving the guide information on the content that can be received in the future, the receiver performs temporal alignment using available_start_time and available_end_time information of each content, and then outputs guide information for the NRT service to the user.

However, in addition to the above-described example, each field constituting the table element will be the same even if the method of constructing the table is different.

How to provide NRT service

Using the NRT service signaling data, the receiver can construct and display NRT guide information to provide to the user. Herein, a method of constructing the NRT guide information includes, for example, the case of using the received NCT and the case of using the NST.

16 is a flowchart illustrating a method of providing an NRT service according to an embodiment of the present invention.

The receiver confirms the NRT service transmitted through the virtual channel (S1501), and accesses the NRT signaling channel transmitted through the IP layer (S1502).

The NST is extracted from the connected NRT signaling channel (S1503).

Specific information on the NRT content delivery channel for each NRT service is obtained from the extracted NST (S1504). Here, the NRT content delivery channel may be, for example, a channel through which content is transmitted, except for a channel through which signaling information is transmitted.

The extracted NST information is parsed and connected to the NRT service, and the NRT content transmitted through the FLUTE session and the FDT information about the content are received and stored in advance (S1505). Here, in the process of acquiring the PID information of the TP including the NCT section, the corresponding PID is defined in advance or well-known and is known by the receiver in advance.

The receiver then receives the transmitted NCT (S1506).

Specific information on the content is obtained using each field of the received NCT (S1507). The NRT guide information is configured and displayed using the concrete information acquired in step S1507, for example, content_id, content_delivery_bit_rate, content_available_start_time, content_available_end_time, content_title_text () (S1508).

If a specific NRT content is selected from the user or the like through the displayed NRT guide information (S1509), the content_id in the FDT stored in advance in step S1505 is compared with the content_id of the selected content to reproduce the corresponding NRT content previously stored in the receiver S1510).

The NRT service signaling architecture (NRT)

The signaling structure of the above NRT service is shown in Fig.

17 illustrates an NRT service signaling structure constructed in accordance with another embodiment of the present invention.

Referring to FIG. 17, each ATSC Virtual Channel includes at least one content delivery channel for transmitting each NRT service in the form of an IP stream, and an NRT service in which signaling information for each content delivery channel is transmitted in the form of an IP stream Signaling channel. Here, the NST is transmitted to the NRT service signaling channel, and the transmitted NST may include a table entry for the corresponding NRT service, thereby signaling a content delivery channel through which the corresponding NRT service is transmitted. For example, in FIG. 17, ATSC Virtual Channel 0 includes an NRT content delivery channel for transmitting three NRT services (NRT services 0, 1 and 2), and ATSC Virtual Channel 1 also includes three NRT services (NRT service 3, 4, 5). ≪ / RTI > That is, one virtual channel can transmit one or more NRT services, and the NRT service is transmitted through an NRT content delivery channel. The NST identifies the NRT content delivery channel through which the NRT service is transmitted. Also, each NRT service is transmitted via an IP stream. In such NRT service signaling, a signaling flow according to a method of accessing an NRT content delivery channel can be used.

The NRT content delivery channel (NRT content delivery channel)

The following method can be used as a method of accessing the NRT content delivery channel through which the NRT content is transmitted.

The method of directly signaling the NRT content delivery channel information through the NST table is a method of directly transmitting basic information and access information about the NRT service through the NST. When the NRT service metadata transmission is performed in the NST table unit, the following advantages exist.

In this case, the service metadata can be received at an early point by signaling directly from the NST without an additional process of receiving and processing the separate service guide information. As a result, the service access speed can be increased. In addition, update signaling for changes to the channel in the broadcast environment can be performed more quickly in real time.

If the NRT service information bearing the NRT content delivery channel is directly signaled in the NST table, the content delivery channel connection is possible only with the NST table without any signaling process.

The NRT content delivery channel in which the actual NRT content is transmitted may be identified as the NRT service type value 0x0F.

NRT Content delivery channel details descriptor

In the above process, the following method can be used for signaling the NRT content delivery channel through the NST. The NRT service containing the NRT content delivery channel can be identified by the service category value being 0x0F. Further information of the NRT content delivery channel is transmitted by transmitting the NRT content delivery channel details descriptor shown in FIG. 18 in the descriptor loop of the NST .

FIG. 18 illustrates a bitstream syntax of an NRT content delivery channel details descriptor according to an embodiment of the present invention. Referring to FIG.

Hereinafter, the fields of the NRT Content Delivery Channel Details Descriptor will be described in detail.

The descriptor_tag field (8 bits) may have a value of 0xTBD so that the corresponding descriptor is identified by the NRT_Content_delivery_channel_details_descriptor. That is, it identifies that this field is NRT_Content_delivery_channel_details_descriptor (descriptor_tag: This 8-bit unsigned integer should have the value 0xTBD, identifying this descriptor as NRT_Content_delivery_channel_details_descriptor).

The descriptor_length field (8 bits) describes the length in bytes from the immediately following field to the end of the field (descriptor_length: This 8-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor).

The storage_reservation field (32-bit) describes the minimum device storage unit (in bytes) required for subscription to that channel (storage_reservation: This 32-bit unsigned integer will require minimum device storage this channel).

The Updated field (32 bits) represents the last time the channel metadata was updated, expressed as the number of GPS seconds since 00:00:00 UTC, January 6, 1980 (Updated: This 32-bit unsigned integer was last updated as the number of GPS seconds since 00:00:00 UTC, January 6, 1980).

The content_types_length field describes the length in bytes of content_types_text () (content_types_length: This field should specify the length (in bytes) of the content_types_text ()).

The content_types_text () field provides a comma-separated list of strings describing the type of channel content, for example, by category, tag or relation (content_types_text (): this field shall give a comma-separated list of strings that describe the type of channel content eg by category, tag or relation).

The mime_types_length field describes the length in bytes of the mime_types_text () field. (mime_types_length: This field should specify the length (in bytes) of the mime_types_text ()).

The mime_types_text () field provides a comma-separated list of MIME types for the content items in the provided channel (mime_types_text (): This field should give a comma-separated list of MIME types for content items in the offered channel).

The charging_rules_length field describes the length in bytes of the charging_rules_text () field (charging_rules_length: This field shall specify the length (in bytes) of the charging_rules_text ()).

The charging_rules_text () field provides information on the charging method and who is responsible for the channel billing based on the subscription or consumption (charging_rules_text (): channel charging, charging method (based on subscription or consumption).

The num_purchase_options field (8 bits) describes the number of purchase options in the corresponding NRT Content delivery channel descriptor (num_purchase_options: This 8 bit field shall specify the number of purchase options in this NRT Content delivery channel descriptor).

The purchase_option_id_length field describes the length in bytes of the purchase_option_id_text () field (purchase_option_id_length: This field should specify the length (in bytes) of the purchase_option_id_text ()).

The purchase_option_id_text () field provides an identifier of the purchase option used to identify the selected option (purchase_option_id_text (): This field shall give an identifier of the purchase option, which will be used to identify the selected option).

The cost_information_flag field (1 bit) indicates that there is a cost_information for the corresponding component if it is set to 1 (cost_information_flag: A 1-bit Boolean flag that indicates when set to 1, that the cost_information is present for this component) .

The value_information_flag field (1 bit), when set to 1, indicates that there is an amount and currency field for the component (price_information_flag: A 1-bit Boolean flag that indicates that when set to 1, that the amount and currency is present for this component).

The cost_information_length field describes the length of the cost_information_text () field in bytes (cost_information_length: This field shall specify the length (in bytes) of the cost_information_text ()).

The cost_information_text () field provides an identifier of the purchase option used to identify the selected option (cost_information_text (): This field shall give an Identifier of the purchase option, which will be used to identify the selected option).

The amount field (32 bits) describes the monetary value of the price for the purchase option (Amount: This 32-bit float shall specify the monetary value of the purchase option).

The currency field describes the currency currency code defined in the international currency code (Currency: This 16-bit unsigned integer shall specify the monetary currency codes in ISO 4217 international currency codes).

The descriptor may be included in the service_level_descriptor position in the NST or in the content_level_descriptor position in the NCT.

FDT schema

FIG. 19 illustrates an FDT schema for mapping a file to a content_id according to an embodiment of the present invention. FIG. 20 illustrates an FDT schema for mapping a file and a content_id according to another embodiment of the present invention. And represents the FDT instant level entry file designation method.

Hereinafter, the FDT instance level refers to a level that includes a definition portion thereof when it is necessary to define common attributes of all files declared in the FDT, and the FDT file level includes definitions of individual attributes in each file Is used to refer to the level of

The receiver can know which content items are included in the NRT service and which files are included in the NRT service, by using the NST and the NCT.

However, as described above in the mobile NRT service environment, it is possible to know which content items and files are included in one mobile NRT service, but there is no or sufficient information to map each content item and each file. That is, it is impossible to know which files each content item included in the NRT service contains. Therefore, there is a problem that it is difficult for the receiver to properly process the received NRT service.

Accordingly, in the present invention, by providing a mapping method therefor, it is desired that a receiver can receive an NRT service and appropriately process the NRT service. Various methods may exist. Hereinafter, a description will be given of a method of mapping through a FDT information, for example, in a FLUTE session for transmitting the mobile NRT service. For example, each file constituting the content item is identified using the TOI and Content-Location fields specified in the FDT in the FLUTE session, and each TOI or Content-Location and content Item linkage can be achieved by mapping the Content-ID field in the FDT to the content_id field in the NCT.

Referring to FIGS. 19 to 19, the part denoted by 1 denotes a content_id in the FDT-Instance level, and the content_id declared here is given to all files declared in the corresponding FDT-Instance. Of course, you can override this information by adding a new content_id at the file level. Alternatively, if a particular file belongs to a content item other than the content item defined at the FDT-Instance level, it may also be indicated by giving the file level content_id described below. In the present embodiment, the content_id is expressed using 16 bits.

If the file contained in the FDT Instance belongs to a different content item, this method is used to signal which content item each file belongs to.

3 is a method for informing each file whether or not the corresponding file is an entry file. That is, a file corresponding to a root file, which must be executed first to reproduce the content item first or to access the content item, among the plurality of files constituting the content item, is called an entry file, and a method for informing such information . The entry attribute can be omitted, and if the default value is omitted, it indicates that the file is not an entry file.

By signaling whether each entry belongs to a group belonging at the file level, a particular file may serve as an entry in a particular group and not in another group.

As an example of an entry file, when a content item is configured in the form of a web page, and index.htm and several other associated pictures and text files exist, index.htm is directly associated with the entry file .

The following two methods can be considered as a method of indicating whether or not an entry file is to be given when Content-id is given at the FDT-instance level.

1) Adding a File-level content-id to the file corresponding to the entry file and setting its entry attribute to true: In this case, there is a disadvantage that the content-id overlaps with the FDT-Instance level and the file level It can have the most flexible structure.

2) It is possible to consider a method of directly referring to files that serve as an entry file in the content-id definition of the FDT-instance level as in another embodiment of the FDT schema shown in FIG. To this end, in the embodiment of FIG. 19, the FDT-Content-ID-Type is separately defined for the FDT-instance level content-id and is expanded to include the content location of the entry file as indicated by No. 2 Respectively.

In this method, it may be a drawback that the signaling of the content location is duplicated, but it is advantageous that the entry file configuration information can be acquired directly for each content item.

Another embodiment of the NRT service providing method

21 is a flowchart illustrating a method of providing an NRT service according to another embodiment of the present invention.

In step S2102, the receiver reads the NCT in the signaling information to signal the received NRT services (S2101), and obtains information on the content items constituting each NRT service (S2102). Here, the information on the content items is configured and displayed by using, for example, content_id, content_delivery_bit_rate, content_available_start_time, content_available_end_time, content_title_text ()

And forms and displays a service guide including the NRT services based on the acquired information on the content items (S2103).

If a certain NRT service or a specific content item in the service is selected by the user from the displayed service guide, a content_id related to the selected NRT service or a specific content item and a service_id associated with the content_id are obtained from the NCT (S2104) .

The receiver reads the NST in the signaling information to receive the selected NRT service or a specific content item (S2105), finds the service_id in the NST that matches the service_id acquired in step S2004, (Step S2106).

The receiver reads the FDT of the connected FLUTE session and determines whether the content ID of the corresponding file matches the content_id in the obtained NCT (S2107).

If it is determined in step S2107 that the content ID obtained by reading the FDT matches the content_id in the NCT, the receiver receives and stores the corresponding file object (S2108).

Here, the receiver parses the FDT instances in the FLUTE session to know the list of files belonging to each content item, and can recognize which file plays the role of an entry. Also, it is possible to know which content item each file belongs to by using the FDT instance, and the receiver can separately organize and store a list of files belonging to the content item on a per-content-item basis.

When the user starts to use a specific content item by selection or the like, the content consumption is started using the content item configuration information and the entry information included in the process.

Here, in constructing the service guide using the NCT, the receiver may construct the service guide using the NCT and NST by parsing the NCT instead of parsing the NST after parsing the NCT. For example, it parses descriptors for NST and related NRT services, and reads application type and other requirement information for each NRT service unit. In addition, application (service category) information is displayed for each service on the NRT service guide output screen, and detailed information is displayed using other fields of the NRT_service_info_descriptor (storage indication of the service, audio_codec_type, video_codec_type field using the storage_requirement field) To display audio and video codec information).

In an embodiment of the service method of FIG. 16 described above, for example, an NRT service is provided in a push mode or a case of a channel dedicated to an NRT service. By parsing an NST first, a FLUTE session Receives and stores the content items in the corresponding service, and then plays back the content item desired by the user or the like among the stored content items using the NCT.

21, the NCT is first parsed to provide a service guide, and when a user or the like selects a specific content item, the NST is parsed to access a FLUTE session in which the selected content item is transmitted, And then plays back.

The service method of FIG. 16 and the service method of FIG. 21 have the above-described difference. In the case of FIG. 16, since all related content items are received and stored, the user's choice is widened and desired content is already stored. However, there is a limit to the storage space, and receiving all the content items in the service and receiving unnecessary content items may reduce the efficiency of the system. In the case of FIG. 21, although efficiency of the system can be improved by receiving only the desired content item, if the user desires another content item, the service guide is provided again and the selected content item must be received. have.

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

Claims (3)

Generating data for non-real time (NRT) services transmitted before use;
Generating signaling data for signaling services including the NRT service; And
Transmitting the broadcast signal including the generated data and the generated signaling data,
Wherein the generated signaling data includes signaling information and NRT signaling information,
Wherein the NRT signaling information provides information for obtaining the generated data,
The NRT signaling information is transmitted based on a UDP / IP (User Datagram Protocol / Internet Protocol)
The generated data is delivered through a file transfer session based on the LCT protocol on the UDP / IP protocol in the broadcast signal,
Wherein the signaling information includes service category information identifying the NRT service, hidden information indicating an NRT service set not to be selected by the receiving device, and signaling channel information for transmitting the NRT signaling information;
A method for transmitting non-real-time services. The method according to claim 1,
Wherein the generated data comprises at least one content item,
Wherein the NRT signaling information comprises identification information for the at least one content item. The method according to claim 1,
Wherein the NRT signaling information includes transmission session identification information, a start time, an end time, and a bandwidth information for a transmission session.

Images