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

Abstract

PURPOSE: A method for mapping signaling information on announcement information and a broadcast receiver are provided to accurately receive content selected from a service guide using signaling information. CONSTITUTION: An MPEG-2 TP buffer/parser(203) buffers and restores an MPEG-2 TP. A PSI/PSIP(Program Specific Information/Program and System Information Protocol) section/buffer(204) buffers and analyzes PSI/PSIP section data transmitted through the MPEG-2 TS. A descrambler(205) uses an encryption key to restore payload data.

Description

Method for mapping between signaling information and announcement information and broadcast receiver

The present invention receives a signaling method for a service type and detailed information about a service for a service transmitted in a non real time (NRT) method through a terrestrial broadcasting network, and receives the corresponding information. And more specifically, the receiver acquires additional information on the NRT service using such service-related signaling information, how to process and output the service to a user, and an associated application module. (operation module) operation can be determined. The present invention relates to a mapping method and a broadcast receiver between signaling information and announcement information for an NRT service.

One of the potential applications to be used in the DTV service is NRT service (Non Real Time service). NRT literally involves non-real-time transmission, storage, and viewing, not real-time streaming, and transmits file-type content through extra bandwidth through broadcast media such as terrestrial waves. Push VOD, targeted advertising It is a technology that is expected to implement a variety of service functions, such as.

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

Another object of the present invention is to define a method of transmitting the signaling data defined above.

Another object of the present invention is to receive and process signaling data for the transmitted NRT service in a receiver so that the NRT service can be accessed.

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 content in which a selected content is transmitted in a receiver.

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

One example of a method for providing a non-real time service according to the present invention may include 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; Acquiring first content identification information for the content selected from 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 the connected flute session; And receiving and storing at least one file constituting the corresponding content based on the obtained second content identification information.

In this case, the identification information may be extracted using at least a virtual channel table (VCT), a data service table (DST), and a program map table (PMT) of the PSI / PSIP table.

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.

In addition, the first signaling information may be NCT, and the second signaling information may be NST.

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

The method may further include constructing and displaying a service guide using the received first signaling information.

And acquiring first service identifier information associated with first content identifier information obtained 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 corresponding to the obtained first service identifier information from the received second signaling information.

An example of a broadcast receiver according to the present invention is to extract identification information of the first signaling information and the second signaling information using a PSI / PSIP table, and based on the extracted identification information, the first signaling information and the second signaling information. A baseband processor unit for receiving; 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 displayed 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 controlling to receive and store at least one or more files constituting a corresponding content item based on the obtained second content identifier; And a storage unit for storing the received files.

In this case, the identification information may be extracted using at least a virtual channel table (VCT), a data service table (DST), and a program map table (PMT) of the PSI / PSIP table.

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.

In addition, the first signaling information may be NCT, and the second signaling information may be NST.

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

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

Second service identifier information matching the acquired first service identifier information may be extracted from the received second signaling information.

According to the invention,

First, the transmitting end may include signaling data to properly recognize, receive, and process an NRT service provided by a receiver.

Secondly, the receiver can properly receive and process an NRT service received using the transmitted signaling data and provide the same to a user.

Third, the receiver can configure and provide a service guide to a user by using the transmitted signaling data.

Fourth, the receiver can effectively receive and process the content selected from the configured service guide using signaling information.

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

Definition of terms used in the present invention

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

NRT  Service conceptual diagram

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

The broadcasting station transmits a Real Time (RT) service according to the existing scheme. In this case, the broadcasting station may provide an NRT (Non Real Time) service by transmitting an RT service or using bandwidth remaining in the process. Here, the NRT service may include news clips, weather information, advertisements, content for Push Video On Demand (VOD), and the like.

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

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

Here, the RT service and the NRT service are transmitted through the same or different DTV channels, and are transmitted through MPEG-2 TP (Transport Packet) or IP datagram. Therefore, the receiver needs to distinguish between two services transmitted through the same channel. To this end, the present specification describes the definition and provision of signaling information so that a receiver can properly receive and process an NRT service. Here, the broadcasting station provides signaling information, and in particular, at least one unique PID for identifying the NRT service may be allocated.

Receiving system

2 is a block diagram of a receiving system configured according to an embodiment of the present invention.

FIG. 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 and an MPEG-2 service demultiplexer. Service Demux), stream component handler (Stream component handler, Media Handler), file handler (File Handler) and other parts.

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 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 symbols extracted by the tuner 201 to restore meaningful data.

Next, the MPEG-2 Service Demux includes an MPEG-2 Transport Packet Buffer / Parser, a PSI / PSIP section / buffer. (PSI / PSIP Section / Buffer) 204, Descrambler 205, MPEG-2 TP Demux 206, and PVR Storage 207 It is configured by.

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 a CA stream handler 216 for a packet payload to which scramble is applied among MPEG-2 TPs. Restore the payload data.

The MPEG-2 TP demultiplexer 206 filters a TP to be processed by a receiver among the MPEG-2 TPs or the MPEG-2 TPs stored in the PVR storage unit 207 transmitted through a VSB signal. Relay to 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 at the user's request. Here, the PVR storage unit 207 may be controlled by the PVR manager 235.

Next, the PES buffer / handler (PESPacketized Elementary Stream (PES) Buffer / Handler) 208, the ES buffer / handler (ES Buffer / Handler) 209, the PCR handler (Program Clock Reference (PCR)). Handler 210, STC unit 211, DSM-CC section Buffer / Handler 212, IP Datagram Buffer / Header Parser 213 , UDP Datagram Buffer / Handler 213, CA Stream Buffer / Handler 214, and Service Signaling Section Buffer / Handler 215 It is configured to include).

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

The ES buffer / handler 209 buffers and restores an elementary stream (ES) such as audio data and video data transmitted in the form of PES to the 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 values of the A / V decoders 218 by using a reference clock value received through the PCR handler 210 and performs time synchronization.

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

The IP datagram buffer / header parser 213 buffers and restores the IP datagram that is encapsulated through 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 payload data using an encryption key or the like received from the CA stream handler 216 for the payload when the scrambling is applied to the payload among the received IP datagrams.

UDP datagram buffer / handler 215 buffers and restores UDP datagrams transmitted over IP datagrams, and analyzes and processes UDP headers.

The CA stream buffer / handler 216 descrambles a credential management message (EMM), a credential control message (ECM), and the like, which are transmitted for a conditional access function transmitted through an MPEG-2 TS or an IP stream. Buffer and process data such as key values for. In this case, the CA stream buffer / handler outputs the output of the 216 to the descrambler 214 to perform decryption operation of an MPEG-2 TP or IP datagram that transmits AV data and file data. do.

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

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

The AV decoders 218 process the decoding of the audio data and the video data received through the ES handler 209 so that they can be presented to the user.

Next, the file handler part will be described.

The file handler unit is divided into ALC / LCT Buffer / Parser 219, FDT Handler 220, XML Parser 221, and File Reconstruction Buffer. 222 and decompressor 223.

The ALC / LCT buffer / parser 219 analyzes the header and header extension of the ALC / LCT by buffering and restoring ALC / LCT data transmitted in the UDP / IP stream. 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. The processed FDT may be transmitted 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 an appropriate module such as the FDT handler 220 and the SG handler 227.

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

The decompressor 223 performs a process of decompressing a file transmitted in an ALC / LCT and FLUTE session when it is compressed.

The file decoder 224 decodes the file restored from the file reconstruction buffer or the file extracted from the decompressor 223 or the file extracted from 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-described parts will be described.

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

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

The service manager 228 collects and analyzes PSI / PSIP data transmitted through the MPEG-2 TS and service signaling section data transmitted through the IP stream to produce a service map. Store this in the Service Map & Guide Database to control access to the services you want. Here, the service manager 228 is controlled by the operation controller 230, the tuner 201, MPEG-2 TP demultiplexer 206, IP datagram buffer / handler 213, NRT service manager (229) and the like.

The NRT service manager 229 performs overall management on the NRT service transmitted in the form of 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 and stored in the service map & guide database 236. In addition, the NRT service manager 229 controls to form the EPG data by transmitting the NCT information related to the service guide among the signaling information to the EPG manager 230. 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 the file storage unit 225 in a hierarchical structure. 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 to configure and display the EPG data.

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

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

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

The presentation manager 234 may include 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. Provide it to the user via the screen.

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

3 is a diagram illustrating a relationship between an NRT service, a content item, and a 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). In addition, the content item may correspond to a program or event in a real-time broadcast as one independently playable entity. Accordingly, the NRT service refers to a group that can be serviced by a combination of the above content items, and corresponds to a channel concept in real time.

In this regard, in order to properly process such an NRT service in a receiver, signaling for the corresponding NRT service is required. The present invention is intended to properly process the NRT service received at the receiver by defining and providing the signaling information. However, a more detailed description of the signaling information will be described later in the corresponding part.

Fixed NRT  Protocol for the service

NRT service is largely divided into fixed NRT service and Mobile NRT service. In the following specification, for convenience of description, a fixed NRT service is described as an example.

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

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

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

NRT content items / files are packetized according to the FLUTE scheme and packetized according to the Asynchronous Layered Coding / Layered Coding Transport (ALC / LCT) scheme. The ALC / LCT packet is wrapped in UDP datagram and transmitted. The ALC / LCT / UDP packet is packetized according to the IP datagram method and ALC / LCT / UDP / IP packetized to become an IP datagram. The IP datagram is included in the MPEG-2 TS through Digital Storage Media Command and Control (DSM-CC) Addressable Sections for transmission. Here, the ALC / LCT / UDP / IP packet also includes a FDT (File Description Table) as information on the FLUTE session.

A signaling information channel (NST) and a signaling information channel including an NRT content table (NCT) are packetized according to the UDP scheme, and the UDP packet is again packetized according to the IP scheme and thus UDP / IP packet data. The IP datagram. The IP datagram is also included in the MPEG-2 TS via DSMCC addressable sections for transmission.

The PSI / PSIP (Program Specific Information / Program and System Information Protocol) table is separately defined and included in the MPEG-2 TS.

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

NRT  Service method

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

1.When transmitted over a virtual channel containing 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, the NRT service may follow 0x04 indicating ATSC Data only service of FIG. 5 or included in another conventional service type.

2. If sent over a virtual channel containing only NRT services:

As shown in FIG. 6, a new service type value may be assigned to signal that the NRT application is 0x08.

TVCT  ( terrestrial virtual channel table )

7 illustrates a bitstream section of a TVCT table section configured according to an embodiment of the present invention.

Referring to FIG. 7, the TVCT table section has a table form similar to that of the MPEG-2 private section. However, the present invention is not limited thereto.

Therefore, the TVCT table section can be divided into header, body and trailer, the header part is from the table_id field to the protocol_version field, and the transport_stream_id field is a 16-bit field, which is defined by a PID value of 0 for multiplexing. (MPEG-2 transport stream ID) in a program association table. The body part is a num_channels_in_section field, which is an 8-bit field, detailing the number of virtual channels in the VCT section. Finally, the trailer part contains a CRC_32 field.

First, the header part is explained as follows.

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

A section_syntax_indicator field (1 bit) is set to 1, indicating that the section follows the general section syntax.

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

A 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 may not be greater than 1021.

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

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

If the current_next_indicator field (1 bit) is set to 1, it indicates that the corresponding table section is currently applicable.

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

A 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 structured parameters differently than defined in the current protocol.

Next, the body part will be described.

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

A short_name field (16 bits) represents the name of the virtual channel as a code value of 1 to 7 consecutive 16 bit codes.

A major_channel_number field (10 bits) represents a major channel number associated with a virtual channel.

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

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

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

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

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

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

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

The hidden field (1 bit), if set, indicates that the virtual channel is inaccessible to the user by direct entry of the virtual channel number.

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

A serviec_type field (6 bits) indicates the type of service carried on the virtual channel. NRT service may be identified through this field.

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

The descriptors_length field represents the total length of descriptors for the following virtual channels.

There is a descriptor field including an event descriptor according to the present invention in a 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 length of the entire list of the following VCT descriptor lists.

Finally, the trailer part, the CRC_32 field, is a 32-bit field that guarantees zero output from the registers of the decoder defined in the MPEG-2 system after processing the entire STT section. Contains a cyclic redundancy check (CRC) 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 may be received through the PID included in the service_location_descriptor, and the type of the application and detailed information of the data broadcast stream transmitted through the channel may be known through the DST.

Referring to FIG. 5, the DST may be used to identify the NRT service. The DST will be described below.

8 illustrates bitstream syntax of a DST table section for identifying an NRT application configured according to an embodiment of the present invention.

The semantics of the fields comprising the data_service_table_bytes structure are defined below.

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 includes a DSM-CC compatibility descriptor. The purpose is to signal the compatibility requirements of the application on the receiving platform to determine its ability to use that data service. (Compatibility_descriptor (): This structure shall contain a DSM-CC compatibility descriptor.Its purpose shall be to 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 of this field shall account for the length of both the app_id_description field and the app_id_byte fields that follow.The value 0x0000 shall indicate that no app_id_description field or app_id_byte fields follow.The value 0x0001 is forbidden).

An 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, as shown in Table 1 below, 0x0003 may be newly allocated and used to identify that the application is an NRT application. (App_id_description: This 16-bit field shall specify the format and semantics of the following application identification bytes.Table 1 specifies the values and associated formats).

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

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

A 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 protocol encapsulation 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 the 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 the 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 be used to indicate the nature of the data referred to by the Tap ()).

A resource_location field (1 bit) describes the location of an Association Tag field that matches an association_tag value listed in the next Tap structure. If this field is set to 0, a matching association_tag exists in the PMT of the current MPEG-2 program. In contrast, if it is set to 1, the association_tag that is matched exists in the DSM-CC Resource Descriptor in the Network Resources Table of the corresponding data service. the following Tap structure.This bit shall be set to 0 when the matching association_tag resides in the PMT of the current MPEG-2 program.This bit shall be set to 1 when the matching association_tag resides in a DSM-CC Resource Descriptor within the Network Resources Table of this Data Service).

The Tap () field is defined as 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 ranged by the value of app_id_byte fields related to Tap () in DST. The tap_id value is selected by the data service provider. Also, it is used in an application 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.It is used in the application as a handle to the data element). 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 association_tag: This 16-bit field shall uniquely identify either a data elementary stream listed in the Program Map Table or a DSM-CC Resource Descriptor listed in the Network Resource Table.In the former case, the value of this field shall match the association_tag value of an association_tag_descriptor in the PMT of the data service.In the latter case, the value of this field shall match the association_tag value in the commonDescriptorHeader structure of a DSM-CC Resource Descriptor in the Network Resource Table of the data service). The Selector () field describes the specific data element available in the communication channel or data elementary stream referenced by the association_tag field. In addition, the selector structure may indicate a 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).

A tap_info_length field (16 bits) describes the number of bytes of descriptors of a field after the corresponding 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 after 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 in bytes of the app_data_byte fields (app_data_length: This 16-bit field shall specify the length in bytes of the following app_data_byte fields).

app_data_byte (8-bit) represents 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 byte units of the following descriptors (service_info_length: This 8-bit field shall specify the number of bytes of the descriptors following 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 in bytes of the private fields to follow).

A service_private_data_byte field (8 bits) represents a private field in 1 byte (service_private_data_byte: This 8-bit field shall represent one byte of the private field).

After identifying the NRT application as described above, the IP stream including the well-known IP address through which the NRT service signaling data delivered through the IP layer is transmitted 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 the selector_bytes. To correctly interpret this selector_bytes value, multiprotocol_encaplsulation_descriptor is used to signal the number of valid bytes in the device_id value.

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

It checks that the well-known IP address carrying NRT service signaling data is loaded among the taps, and receives the IP packet first.

The NRT service can be started by extracting the NRT service signaling data from the IP packet and delivering it to an NRT application manager for processing.

As described above, the NRT service signaling channel is multicasted by accumulating on 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. 9.

9 illustrates a method of configuring 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. In this case, the signaling structure is shown in FIG. 9. That is, unlike all signaling at the PSIP stage, it can be seen that a separate NRT service signaling channel exists as an IP multicast stream.

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

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

Therefore, the receiver parses the service_type in the received TVCT to determine the type of service provided through the selected channel (S1003). For example, the type of the corresponding service provided through the selected channel may mean that the digital A / V / Data service type is 0x02, the data only service type is 0x04, and the NRT Only service type is 0x08. Can be.

If the corresponding service type is not the 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 (S1004).

In operation S1005, the DST is received using the extracted PID.

In operation S1006, it is determined whether the corresponding service provided through the channel selected from the received DST is an NRT service. Here, the determination of whether the NRT service can be found by checking app_id_description in the DST. For example, if the value of the app_id_description is 0x0003, it can be seen that the service is an NRT application.

As a result of the determination in step S1006, if the corresponding 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 a PMT is extracted (S1008).

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

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

In this regard, after identifying that an NRT application exists in a virtual channel in the above manner, 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 Protocol_encapsulation value is 0x04, asynchronous IP datagram is transmitted. If Selector_type is 0x0102, device_id value indicating destination address is transmitted through selector_bytes. To correctly interpret this selector_bytes value, multiprotocol_encaplsulation_descriptor is used to signal the number of valid bytes in the device_id value.

Eventually, the Tap information on the multicast address (or address range) of the IP datagram may indicate the PID of the transport stream carrying the corresponding data. It checks that the well-known IP address carrying NRT service signaling data is loaded among the taps, and receives the IP packet first.

In the next step, the NRT service signaling data is extracted from the IP packet and delivered to the NRT application manager to start the service.

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

Hereinafter, in order to provide information for signaling an NRT service, NST and NCT transmitted through a signaling information channel and descriptors accompanying them are 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 bitstream syntax of an NST constructed according to an embodiment of the present invention.

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

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

The table_id field (8 bits) is for identifying the type of the corresponding table section. This field indicates that the 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 NRT Service Table (NST).

A section_syntax_indicator field (1 bit) is an indicator defining a section format of an NST. The section format may be, for example, a short-form syntax (0) of MPEG (section_syntax_indicator: This 1-bit field shall be set to 0 to always indicate that this table is derived from the short form of the MPEG-2 private section table).

The private_indicator field (1 bit) indicates whether the section type follows the private section type (private_indicator: This 1-bit field shall be set to 1).

section_length: A 12-bit field.It specifies the number of remaining bytes this table section immediately following this field.The value in this field shall not exceed 4093 (0xFFD)).

table_id_extension: This is a 16-bit field and is table-dependent.It shall be considered to be logically dependent on the table. 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) tells the protocol version to inform the NRT NST that parameters whose structure differs from those defined in the current protocol are transmitted (NST_protocol_version: An 8-bit unsigned integer field whose function is to allow, in the future, this NRT Service Table to carry parameters that may be structured differently than those defined in the current protocol.At present, the value for the NST_protocol_version shall be zero.Non-zero values of NST_protocol_version may be used by a future version of this standard to indicate structurally different tables).

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

(current_next_indicator: A one-bit indicator, which when set to 1 shall indicate that the NRT Service Table sent is currently applicable.When the bit is set to 0, it shall indicate that the table sent is not yet applicable and will be the next table to become valid.This standard imposes no requirement that next tables (those with current_next_indicator set to 0) must be sent.An update to the currently applicable table shall be signaled by incrementing the version_number field).

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

(last_section_number: This 8-bit field shall give the number of the last section (ie, the section with the highest section_number) of the NRT Service table of which this section is a part).

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

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

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

A 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 about a plurality of fixed NRT services using a for loop. Hereinafter, the following field information may be provided for each fixed NRT service.

An 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). Here, if the mobile service is an NRT service, NRT_service_status: A 2-bit enumerated field that shall identify the status of this NRT Service.The most significant bit shall indicate whether this NRT Service is active (when set to 1) or inactive (when set to 0) and the least significant bit shall indicate whether this NRT Service is hidden (when set to 1) or not (when set to 0) .Hidden services are normally used for proprietary applications , and ordinary receiving devices should ignore them).

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

The CP_indicator field (16 bits) is used to indicate if content protection applied to at least one of the components required to provide a meaningful presentation of the mobile service is set (CP_indicator: A 1-bit field that shall indicate). , when set, that content protection is applied to at least one of the components needed to provide a meaningful presentation of this NRT Service).

An NRT_service_id field (16 bits) is an indicator for uniquely identifying the corresponding NRT service within the range of the corresponding NRT broadcast. The NRT_service_id does not change throughout the service. Here, if the service is terminated to avoid confusion, the NRT_service_id for the service will not be used for another service until the appropriate time has elapsed (NRT_service_id: A 16-bit unsigned integer number that shall uniquely identify this NRT Service within the scope of this NRT Broadcast.The NRT_service_id of a service shall not change throughout the life of the service.To avoid confusion, it is recommended that if a service is terminated, then the NRT_service_id for the service should not be used for another service until after a suitable interval of time has elapsed).

A short_NRT_service_name_length: A three-bit unsigned integer that shall indicate the number of byte pairs in the short_NRT_service_name field.This value is shown as m in the No. of Bits 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 represents a short name of an NRT service. (Short_NRT_service_name: The short name of the NRT Service.When there is no short name of this NRT Service, this field shall be filled with NULLs (0x00)).

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

A num_components field (5 bits) describes the number of IP stream components in the corresponding NRT service (num_components: This 5-bit field specifies the number of IP stream components in this NRT Service).

If 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 if it is set to 1, the source_IP_address field, the NRT_service_destination_IP_address field, and the component_destination_IP_address field are IPv6 address. 1-bit indicator, which when set to 0 shall indicate that source_IP_address, NRT_service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses.The value of 1 for this field is reserved for possible future indication that source_IP_address, NRT_service_destination_IP_address fields are for IPv6).

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

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

A source_IP_address field (128 bits) has a corresponding field when source_IP_address_flag is set to 1, but a corresponding field will not exist when source_IP_address_flag is set to 0. If this field is present, this field will contain the source IP address of all IP datagrams carrying components of the NRT service. The limited use of the 128-bit long address in this field is intended to enable future use of IPv6, although the use of IPv6 is currently undefined. Source_IP_address becomes the source IP address of the same server transmitting all channels of the FLUTE session (source_IP_address: This field shall be present if the source_IP_address_flag is set to 1 and shall not be present if the source_IP_address_flag is set to 0 If present, this field shall contain the source IP address of all the IP datagrams carrying the components of this NRT Service.The conditional use of the 128 bit-long address version of this field is to facilitate possible use of IPv6 in the future, although use of IPv6 is not currently defined).

The NRT_service_destination_IP_address field (128 bits) has a corresponding source_IP_address field when source_IP_address_flag is set to 1, but a corresponding source_IP_address field will not exist when source_IP_address_flag is set to 0. 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 use of IPv6 is not currently defined. NRT_service_destination_IP_Address is signaled if there is a destination IP address of the session level of this FLUTE session. this NRT_service_destination_IP_address is not present, then the component_destination_IP_address field shall be present for each component in the num_components loop.The conditional use of the 128 bit-long address version of this field is to facilitate possible use of IPv6 in the future, although use of IPv6 is not currently defined).

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

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

A port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component. The port_num_count: This field shall indicate the number of destination UDP ports associated with this UDP / IP stream component.The values of the destination UDP port numbers shall start from the component_destination_UDP_port_num field and shall be incremented by one).

component_destination_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set to 1, that the component_destination_IP_address is present for the component_destination_IP_address_flag field (1 bit) is set to 1 when the component_destination_IP_address field is present for the component. this component).

A component_destination_IP_address field (128 bits) has a corresponding field when component_destination_IP_address_flag is set to 1, but a corresponding field will not exist when component_destination_IP_address_flag is set to 0. If this field is present, this field will contain the source IP address of all IP datagrams carrying components of the NRT service. The limited use of the 128-bit long address in this field is intended to enable future use of IPv6, although the current use of IPv6 is undefined (component_destination_IP_address: This field shall be present if the component_destination_IP_address_flag is set to 1 and shall not be present if the component_destination_IP_address_flag is set to 0.When this field is present, the destination address of the IP datagrams carrying this component of the NRT Service shall match the address in this field.When this field is not present, the destination address of the IP datagrams carrying this component shall match the address in the NRT_service_destination_IP_address field.The conditional use of the 128 bit-long address version of this field is to facilitate possible use of IPv6 in the future, although use of IPv6 is not currently defined).

A component_destination_UDP_port_num field (16 bits) indicates a destination UDP port number for the corresponding UDP / IP stream component (component_destination_UDP_port_num: A 16-bit unsigned integer field, that 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, that represents the number of descriptors providing additional information for IP stream component, may be included).

The component_level_descriptors field identifies one or more descriptors that provide 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).

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

NRT_service_level_descriptor () identifies one or more descriptors that provide no additional information for the NRT service. Here, the specific service type for the NRT service may be informed. The specific service type may include, for example, a portal service for providing web content, a push VOD, an A / V download, and the like (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).

virtual_channel_level_descriptor () represents a zero or more descriptors providing additional information for the virtual channel which this NST describes, may be included.

The NRT service is transmitted through FLUTE, and access information on the NST table is connected with FLUTE session information as follows. Source_IP_address is a source IP address of the same server that transmits all 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.

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

By designating a plurality of ports, a plurality of channels may be configured for one destination IP address. Here, one component may designate a plurality of channels. In general, however, it is desirable to distinguish the channels by their destination IP addresses. Here, it can be seen that one channel is mapped to one component.

Content items / files for the NRT service are transmitted through FLUTE and signal corresponding FLUTE session information using the access information on the NST table. FIG. 13 illustrates a bit stream syntax of NRT_component_descriptor () configured 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 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 in use for that component of the NRT Service).

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

A descriptor_tag field (8 bits) identifies that the 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).

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

A component_type field (7 bits) identifies an encoding format of a component. The identification value may be one of values assigned for payload_type of the RTP / AVP stream. Or it may be one of the values shown in Table 3 to be described later assigned by this specification. Or dynamic value. The values in this field shall correspond to the values in payload_type in the RTP header of the IP stream carrying the component (component_type: This 7-bit field shall identify the encoding format of the component.The value may be any of the values assigned by IANA for the payload_type of an RTP / AVP stream [10], or it may be any of the values in [Table 3] assigned by this document, or it may be a dynamic value in the range 96-127.For components consisting of media carried 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 additionally signal the parameters to be described below required for the FLUTE session when transmitting an NRT service stream on a FLUTE basis, a component_type 38 defined by the ATSC for the FLUTE component may be used as shown in Table 3 and may not be assigned yet. A value of 43 may be newly defined and used as a component_type for NRT transmission.

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

A num_STKM_streams field (8 bits) identifies a number of STKM streams associated with this component. (num_STKM_streams: An 8-bit unsigned integer field that shall 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. Here, 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 shall 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 encoding parameters and / or other parameters necessary for representing the corresponding 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.The structure of the NRT_component_data is determined by the value of component_type field).

The File Delivery Table (FDT) of FLUTE sessions is used to deliver item lists of all content items and provides the size, data type and other information of the items related to obtaining the items (The File Delivery Table (FDT) of the FLUTE). sessions used to deliver the items lists all the content items and gives their sizes, data types, and other information relevant to the acquisition of the items).

Accordingly, the present invention obtains information for accessing a FLUTE session in which corresponding content is transmitted using NST to receive selected content from a service guide configured using NCT. And we want to map the information about the content item of the NCT with the information about the file transmitted through the corresponding FLUTE session. Here, identifying the service including the selected content item may be identified through the NRT_service_id of the above-described NST. However, as mentioned in FIG. 3, in order to know in more detail one or more content item (s) included in each NRT service and files belonging to the NRT service, information on a FLUTE session through which the corresponding content item (s) are transmitted, More specifically, mapping with content identifier in FDT information for FLUTE session is required.

The NRT service is transmitted through FLUTE, and access information on the NST table is connected with FLUTE session information as follows. Source_IP_address becomes the source IP address of the same server that transmits all 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 may be mapped to a channel in a FLUTE session and may signal a separate destination IP address (different from the IP address signaled on a session basis) through each component_destination_IP_address. In addition, the destination port number may be signaled through component_destination_UDP_port_num and the number of destination ports starting from component_destination_UDP_port_num may be additionally specified through port_num_count.

By specifying a plurality of ports, a plurality of channels may be configured for one destination IP address. In this case, one component may designate a plurality of channels. However, in general, it is recommended to distinguish the channel by the destination IP address. In this case, one channel is mapped to one component.

Component_attribute_byte may be used to signal an additional attribute of a component configuring a session. Additional parameters necessary for signaling a FLUTE session may be signaled through this.

In this regard, parameters are required to signal a FLUTE session, and these parameters include mandatory parameters that are absolutely necessary and parameters that are optionally required in connection with the FLUTE session. Firstly, the mandatory parameters include the source IP address, the number of channels in the session, the destination IP address and port number for each channel in the session. for each channel in the session, the Transport Session Identifier (TSI) of the session, and the start time and end time of the session parameters. Optionally related parameters include: FEC Object Transmission Information, Some information that tells receiver in the first place, that the session contains files that are of interest And Bandwidth specification parameters.

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

14 illustrates a bit stream syntax of an 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 depending 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).

Hereinafter, each field of the NRT_component_data_descriptor will be described in detail.

A TSI field (16 bits) indicates a TSI of a FLUTE session (TSI: A 16-bit unsigned integer field, which shall be the Transport Session Identifier (TSI) of the FLUTE session).

The session_start_time field indicates the time at which the FLUTE session starts. Session_start_time: The time at which the FLUTE session starts.If the value of this field is set to all zero, then it shall be interpreted to mean that the session has already started).

The session_end_time field indicates the time when the FLUTE session ends. Session_end_time: The time at which the FLUTE session ends.If the value of this field is set to all zero, then it shall be interpreted to mean that the session continues indefinitely).

A tias_bandwidth_indicator field (1 bit) indicates flags including transport independent application specific (TIAS) bandwidth information. If the TIAS Bandwidth field indicates that the bit is present, the bit shall be set to 1, and if the TIAS Bandwidth field indicates that the TIAS bandwidth field does not exist, the bit shall be set to 0 (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 flags including application specific (AS) bandwidth information. If the AS bandwidth field is present, the bit should be set to 1, and if the AS bandwidth field is not present, the bit should be set to 0 (as_bandwidth_indicator: A 1-bit field that flags the inclusion of bit bandwidth information.This bit 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).

An FEC_OTI_indicator field (1 bit) indicates whether FEC Object Transmission Information (OTI) information is provided (FEC_OTI_indicator: A 1-bit indicator that indicates whether FEC Object Transmission Information is provided).

The tias_bandwidth field indicates the TIAS maximum bandwidth (tias_bandwidth: This value shall be one one-thousandth of the Transport Independent Application Specific maximum bandwidth, rounded up to the next highest integer if necessary. (Note: this gives the TIAS bandwidth in kilobits per second)).

The as_bandwidth field will have an AS maximum bandwidth value (as_bandwidth: This value shall be the Application Specific maximum bandwidth (Note: this gives the AS bandwidth in kilobits per second)).

The FEC_encoding_id field indicates an 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 FLUTE component data bytes, all information necessary for receiving a FULTE session can be provided, and the FDT is received through this session to thereby provide a FLUTE session. A method of acquiring information about all files delivered and receiving these files may be used.

This FLUTE component descriptor may be delivered through a Component_level_descriptor loop of NST. When there are a plurality of FLUTE channels, TSI, session_start_time, session_end_Time, etc., which are session level parameters, need to be signaled only once, and thus, the FLUTE component descriptor may be transmitted through a Component_level_descriptor loop only in one component among multiple channel components.

Next, the NCT will be described.

15 illustrates bitstream syntax of an NCT section constructed according to an embodiment of the present invention.

Hereinafter, an NRT content table (NCT) related to signaling / announcement is described for NRT content transmitted for each NRT content delivery channel signaled through the aforementioned NST.

In FIG. 15, NCT is newly defined to signal NRT content. However, this may be considered in another embodiment as well. NRT content transmitted through a specific NRT content delivery channel may be signaled through NCT. Hereinafter, each field information constituting the NCT section will be described in detail.

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

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

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

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

The content_version field may know a version number for content (or file) having a specific content_id value. That is, when the receiver has a content_id of 0x0010 of a file previously received and stored, the same content, that is, a file with a content_id value of 0x0010 is transmitted, and if the content_version is different from the previously received and stored content, it is newly generated through NCT. The received content is updated to update or replace previously stored content. In the present embodiment, it means a serial number indicating a version of a release, but may actually represent a published (released) time directly. In this case, when the published time is difficult to be expressed as the content_version field, a new field that can express published (released) time may be used.

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 end time of a FLUTE session that can receive content.

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

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

The content_delivery_bit_rate field indicates a transmission bit rate for transmitting content (or file) and indicates a target bit rate. That is, it indicates how much bandwidth should be allocated when a service provider or a broadcasting station transmits the corresponding content. Using this information, the receiver can know the minimum time taken to receive the file using content_size and content_delivery_bit_rate. That is, the time required to receive the content can be estimated and the user can be provided with the corresponding information. The minimum reception time is obtained by calculating (conent_size * 8) / (content_delivery_bit_rate) and the unit is seconds. )to be.

The content_title_length field represents the length of content_title_text () in bytes. This tells the receiver how many bytes of data to read in order to correctly obtain content_title_text () information.

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

As a method of configuring the above-described NST, for example, one or more NRT channel (s) may be configured as one channel.

In the present specification, an NRT channel may be configured in an NRT service unit, and one or more FLUTE sessions may transmit one or more files.

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 announce the FLUTE session during this time.

In addition to the present, information about all NRT channels to be transmitted in the future can be organized into a table, which is divided into present (for a certain period from the present) and future (after a defined period), and within a certain time from the present ( For example, it may be possible to send each of them into a separate table by dividing it into three sections after 24 hours), within a predetermined time period (for example, 24 hours), and afterwards.

In addition, the table_id may be used to distinguish whether the guide information for the currently available content or the guide information for the content that can be received in the future. This is a method of separately transmitting an NRT service that can be received within a short time from now and a service that can be received after that time into separate tables.

When receiving guide information on 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 the guide information about the NRT service to the user.

However, each field constituting the table element will be the same even if the method of configuring the table is different from the above-described example.

How to provide NRT service

Using the aforementioned NRT service signaling data, the receiver may configure and display NRT guide information and provide the same to the user. Here, the method of configuring the NRT guide information, for example, there is a case of using the received NCT and the case of using the NST, an embodiment thereof will be described.

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

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

An NST is extracted from the accessed NRT signaling channel (S1503).

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

The extracted NST information is parsed to access an NRT service to receive and store NRT content transmitted through a FLUTE session and FDT information on the content in advance (S1505). Here, in the process of acquiring the PID information of the TP including the NCT section, the corresponding PID is pre-allocated or defined as well-known and is known to the receiver in advance.

Thereafter, the receiver receives the transmitted NCT (S1506).

Detailed information on content is obtained using each field of the received NCT (S1507). For example, the NRT guide information is configured and displayed using content_id, content_delivery_bit_rate, content_available_start_time, content_available_end_time, content_title_text (), etc. obtained in step S1507 (S1508).

When specific NRT content is selected from the user 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).

NRT service signaling architecture

The signaling structure of the aforementioned NRT service is illustrated in FIG. 17.

17 illustrates an NRT service signaling structure configured according to another embodiment of the present invention.

Referring to FIG. 17, each ATSC virtual channel includes at least one content delivery channel for delivering each NRT service in the form of an IP stream and an NRT service for signaling information about each content delivery channel in the form of an IP stream. It includes a signaling channel. Here, the NRT service signaling channel may transmit an NST, and the transmitted NST may signal a content delivery channel through which the corresponding NRT service is transmitted, including a table entry for the corresponding NRT service. For example, in FIG. 17, ATSC Virtual Channel 0 includes an NRT content delivery channel 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) to the NRT content delivery channel. That is, one virtual channel may transmit one or more NRT services, and the NRT service is transmitted through an NRT content delivery channel. The NST identifies an NRT content delivery channel through which each NRT service is transmitted. In addition, each NRT service is transmitted through an IP stream. In such NRT service signaling, a signaling flow according to a method of accessing an NRT content delivery channel may be used.

NRT content delivery channel

As a method of accessing an NRT content delivery channel through which NRT content is transmitted, the following method may be used.

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

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

As such, when NRT service information including an NRT content delivery channel is directly signaled in the NST table, the content delivery channel can be accessed with only the NST table without a separate signaling process.

In the NRT content delivery channel through which actual NRT content is transmitted, an NRT service type value may be identified as 0x0F.

NRT Content delivery channel details descriptor

In the above process, the following method may be used to signal the NRT content delivery channel through the NST. An NRT service carrying an NRT content delivery channel can be identified through a service category value of 0x0F, and additional information of the NRT content delivery channel can be delivered by inserting the NRT content delivery channel details descriptor illustrated in FIG. 18 into the descriptor loop of the NST. Can be.

18 illustrates bitstream syntax of an NRT Content Delivery Channel Details Descriptor configured according to an embodiment of the present invention.

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 in order to identify the corresponding descriptor as NRT_Content_delivery_channel_details_descriptor. That is, this field identifies NRT_Content_delivery_channel_details_descriptor (descriptor_tag: This 8-bit unsigned integer shall have the value 0xTBD, identifying this descriptor as NRT_Content_delivery_channel_details_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 storage_reservation field (32 bits) describes the minimum device storage unit (in bytes) required for the subscription of the channel (storage_reservation: This 32-bit unsigned integer shall specify minimum device storage (in bytes) required for subscription to this channel).

The Updated field (32 bits) represents the time when the channel metadata was last updated, in GPS seconds since 00:00:00 UTC, January 6, 1980 (Updated: This 32-bit unsigned integer shall represent time when the channel metadata 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 shall 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 by category, tag or relation, for example. 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 shall specify the length (in bytes) of the mime_types_text ()).

The mime_types_text () field provides a comma-separated list of MIME types for content items in the provided channel. (mime_types_text (): This field shall 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 ()).

charging_rules_text (): This field shall give Information that at least defines who is responsible for the chargeing method and who is responsible for channel charging based on the subscription or consumption. channel charging, charging method (based on subscription or consumption)).

A 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 shall specify the length (in bytes) of the purchase_option_id_text ()).

(purchase_option_id_text (): This field shall give a Identifier of the purchase option, that will be used to identify the selected option).

(cost_information_flag: A 1-bit Boolean flag that shall indicate, when set to 1, that the cost_information is present for this component) .

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

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

cost_information_text (): This field shall give a Identifier of the purchase option, that will be used to identify the selected option.

The amount field (32-bit) describes the monetary value of the price for the purchase option (Amount: This 32-bit float shall specify the monetary value of the price for this 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 defined 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 and content_id according to an embodiment of the present invention, and FIG. 20 illustrates an FDT schema for mapping a file and content_id according to another embodiment of the present invention. As illustrated, the FDT instant level entry file designation method is represented.

In the following, the FDT instance level means a level including a definition part of the common attributes of all files declared in the FDT, and the FDT file level includes definitions of individual attributes in each file. It is used to mean a level.

The receiver may know whether a service transmitted through a corresponding channel is an NRT service using an NST and an NCT, and what content items and files are included in the corresponding NRT service.

However, as described above in the mobile NRT service environment, it is possible to know what content items and files are included in one mobile NRT service, but there is no or insufficient information for mapping each content item and each file. That is, it is not possible to know what files are included in each content item included in the NRT service. Therefore, it is difficult for the receiver to properly process the received NRT service.

Accordingly, the present invention provides a mapping method related thereto so that a receiver can properly receive an NRT service. Various methods may exist, but in the following description, a method of mapping through, for example, FDT information in a FLUTE session for transmitting a corresponding mobile NRT service will be described as an embodiment. For the brief description of the mapping method, for example, each file constituting the content item is identified using the TOI and Content-Location fields specified in the FDT within the FLUTE session, and the respective TOI or Content-Location and content are identified. Linking of items may be achieved by mapping the Content-ID field in the FDT with the content_id field of the NCT.

Referring to FIGS. 19 to 19, the part indicated by 1 declares content_id at the FDT-Instance level, and the content_id declared here is assigned to all files declared in the FDT-Instance. Of course, this information may be overridden by newly assigning content_id at the file level. Alternatively, if a specific file belongs to a content item other than the content item defined at the FDT-Instance level, this may be notified by assigning a file level content_id to be described below. In this embodiment, content_id is expressed using 16 bits.

The part marked 2 indicates content_id at the file level. If a file included in the FDT instance belongs to a different content item, this method signals which content item each file belongs to.

Number 3 is a method for notifying whether each file is an entry file for each file. In other words, the file that corresponds to the root file that must be played first among the files that make up the content item or must be accessed first to access the content item is called an entry file. Indicates. The entry attribute can be omitted. If the default value is omitted, it means that the file is not an entry file.

By signaling each entry according to a group belonging to the file level, a specific file may act as an entry in a specific group and not in another group.

An example of an entry file is index.htm when the content item is configured in the form of a web page, and index.htm and several other related picture and text files exist. Becomes

The following two methods can be considered to indicate whether an entry file is provided when a Content-id is assigned at the FDT-instance level.

1) How to add additional file-level content-id to the file corresponding to the entry file and set its entry attribute to true: In this case, the content-id overlaps with the FDT-Instance level and the file level. It can have the most flexible structure.

2) As another embodiment of the FDT schema illustrated in FIG. 20, a method of directly referring to files that play the role of an entry file in the content-id definition of the FDT-instance level may be considered. 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 extended to include the content location of the entry file as indicated by number 2. It was.

In this method, a part of overlapping signaling of the content location may be a disadvantage, but an advantage may be obtained that the entry file configuration information may be directly obtained for each content item.

Another embodiment of a method of providing an NRT service

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

The receiver reads an NCT of signaling information (S2101) in order to signal the received one or more NRT services (S2101), and acquires information on content items constituting each NRT service (S2102). In this case, 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 the like.

A service guide including each NRT service is configured and displayed based on the obtained information about the content items (S2103).

If any one NRT service or a specific content item in the service is selected by the user or the like 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 an NST of signaling information to receive the selected NRT service or a specific content item (S2105), finds a service_id in the NST that matches the service_id obtained in step S2004, and configures the NRT service or content item. The transmitted FLUTE session is connected (S2106).

The receiver reads the FDT of the accessed FLUTE session and determines whether the content-ID attribute of the corresponding file matches the acquired content_id in the NCT (S2107).

As a result of the determination of step S2107, if the content identifier obtained by reading the FDT and the content_id in the NCT match, the receiver receives and stores the corresponding file object (S2108).

Here, the receiver can parse the FDT instances in the FLUTE session to know a list of files belonging to each content item, and can also determine which file serves as an entry. In addition, the FDT instance may be used to determine which content item each file belongs to, and if necessary, the receiver may organize and store a list of files belonging to each content item.

When starting to use a specific content item by the user's selection or the like, content consumption is started using the content item configuration information obtained in the above process and the entry information included therein.

Here, in constructing the service guide using the NCT, the receiver may parse the NST after parsing the NCT and parse the NST together to form the service guide using the NCT and the NST. For example, parse descriptors for NST and related NRT services, and read application type and other requirement information for each NRT service. In addition, the application (service category) information is displayed for each service on the NRT service guide output screen, and detailed information is displayed by using other fields of the NRT_service_info_descriptor. Display audio and video codec information, etc.).

In the case of the service method of FIG. 16 described above, for example, the NRT service is provided in a push method or the NRT service dedicated channel, and the NST service is parsed first to the FLUTE session in which the NRT service is provided. This is a flow of accessing, receiving and storing content items in a corresponding service, and then playing a content item desired by a user among the stored content items using NCT.

In contrast, in another embodiment of the service method of FIG. 21, when a NCT is first parsed to provide a service guide, and 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 the corresponding content is transmitted. It is a flow to receive, store and play afterwards.

The service method of FIG. 16 differs from the service method of FIG. 21. In the case of FIG. 16, the user's selection is expanded by receiving and storing all related content items, and the desired content is already stored. Although possible, there is a limit of storage space and the efficiency of the system may be reduced by receiving all content items in the service and receiving unnecessary content items. In addition, in the case of FIG. 21, the efficiency of the system can be improved by receiving only the desired content item, but if the user wants another content item, the time required for the playback may be longer because the user must provide the service guide again and receive the selected content item. have.

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

1 illustrates an example of a conceptual diagram for an NRT service,

2 is a block diagram of a receiving system configured according to an embodiment of the present invention.

3 is a diagram illustrating a relationship between an NRT service, a content item, and a file;

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

FIG. 5 illustrates an example of an ATSC service type in connection with the present invention.

6 illustrates another example of an ATSC service type in connection with the present invention.

7 illustrates a bitstream section of a TVCT table section configured according to an embodiment of the present invention.

8 illustrates a bitstream syntax of a DST table section for identifying an NRT application configured according to an embodiment of the present invention.

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

10 illustrates a flow chart for FIG. 9,

11 and 12 illustrate bitstream syntax of an NST extracted by a receiver from a received MPEG-2 TS configured according to an embodiment of the present invention.

13 illustrates a bit stream syntax of NRT_component_descriptor () configured according to an embodiment of the present invention.

14 illustrates a bit stream syntax of an NRT_component_data_descriptor for FLUTE file delivery configured according to an embodiment of the present invention.

FIG. 15 illustrates 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 configured according to another embodiment of the present invention.

18 illustrates bitstream syntax of an NRT Content delivery channel details descriptor configured according to an embodiment of the present invention.

19 illustrates an FDT schema for mapping a file and 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 content_id according to another embodiment of the present invention; and

21 is a flowchart illustrating a process of processing an NRT service in a receiver according to an embodiment of the present invention.

Claims (15)

Extracting identification information of the first signaling information and the second signaling information using the 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; Acquiring first content identification information for the content selected from 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 the connected flute session; And And receiving and storing at least one or more files constituting the corresponding content based on the obtained second content identification information. The method of claim 1, The identification information, Non-real time service providing method to extract using at least a virtual channel table (VCT), a data service table (DST) and a program map table (PMT) of the PSI / PSIP table. The method of claim 1, The files constituting the NRT service, the first signaling information and the second signaling information are received after IP packetization, addressable section packetization, and MPEG-2 TS packetization are sequentially performed. The method of claim 1, And the first signaling information is NCT and the second signaling information is NST. The method of claim 1, And extracting the second content identification information from a file description table (FDT) in the connected flute session. The method of claim 1, And constructing and displaying a service guide by using the received first signaling information. The method of claim 6, And obtaining first service identifier information associated with first content identifier information obtained from the first signaling information in relation to the selected specific content item in the displayed service guide. The method of claim 7, wherein And extracting second service identifier information corresponding to the obtained first service identifier information from the received second signaling information. A baseband processor for extracting identification information of the first signaling information and the second signaling information using the PSI / PSIP table and receiving the first signaling information and the second signaling information based on the extracted identification information; 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 displayed 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 controlling to receive and store at least one or more files constituting a corresponding content item based on the obtained second content identifier; And And a storage unit for storing the received files. The method of claim 9, The identification information, And a broadcast receiver extracted using at least a virtual channel table (VCT), a data service table (DST), and a program map table (PMT) of the PSI / PSIP table. The method of claim 9, The files constituting the NRT service, the first signaling information, and the second signaling information are received after IP packetization, addressable section packetization, and MPEG-2 TS packetization are sequentially performed. The method of claim 9, And the first signaling information is NCT and the second signaling information is NST. The method of claim 9, And the second content identification information is extracted from a file description table (FDT) in the connected flute session. The method of claim 13, And first service identifier information associated with first content identifier information obtained from the first signaling information in relation to the selected specific content item in the displayed service guide. The method of claim 14, And second service identifier information corresponding to the obtained first service identifier information is extracted from the received second signaling information.

Images