CA2726835A1 - Service providing method and broadcast receiver - Google Patents

Abstract

A method for mapping signaling information to announcement information and a broadcast receiver are disclosed herein. A method of providing a Non-Real-Time (NRT) service, the method comprises extracting identification information of first signaling information and second signaling information based upon a program specific information/program and system information protocol (PSI/PSIP) table, receiving the first signaling information and second signaling information based upon the extracted identification information, constructing and displaying a service guide using the received first signaling information, acquiring first content identification information as a content selected from the displayed service guide, accessing a File Delivery over Unidirectional Transport (FLUTE) session using the received second signaling information, acquiring second content identification information matched with the acquired first content identification information from the accessed FLUTE session and receiving and storing one or more file constructing corresponding content based upon the acquired second content identification information.

Description

SERVICE PROVIDING METHOD AND BROADCAST RECEIVER

[0001] This application claims the benefit of U.S.
Provisional Application No. 61/059,811, filed on June 9, 2008, which is hereby incorporated by reference. Also, this application claims the benefit of U.S. Provisional Application No. 61/079,121, filed on July 8, 2008, which is hereby incorporated by reference. This application also claims the benefit of U.S. Provisional Application No.
61/115,888, filed on November 18, 2008, which is hereby incorporated by reference. This application also claims the benefit of U.S. Provisional Application No. 61/121,178, filed on December 9, 2008, which is hereby incorporated by reference. This application also claims the benefit of U.S.
Provisional Application No. 61/138,494, filed on December 17, 2008, which is hereby incorporated by reference. This application also claims the benefit of U.S. Provisional Application No. 61/153,973, filed on February 20, 2009, which is hereby incorporated by reference. This application also claims the benefit of U.S. Provisional Application No.
61/153,985, filed on February 20, 2009, which is hereby incorporated by reference. This application also claims the benefit of U.S. Provisional Application No. 61/169,711, filed on April 15, 2009, which is hereby incorporated by reference.
This application also claims the benefit of U.S. Provisional Application No. 61/179,005, filed on May 17, 2009, which is hereby incorporated by reference. And this application claims 5,.

the priority benefit of Korean Application No. 10-2009-0051208, filed on June 9, 2009, which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION
Field of the Invention [0002] The present invention relates to a signaling method for a service type of a service transmitted by non-real time (hereinafter abbreviated NRT) and detailed information on the service through a terrestrial broadcast network and an operation of an NRT receiver for receiving to process the corresponding information, and more particularly, to a broadcast receiver and a method of mapping signaling information for an NRT service to announcement information therein. Although the present invention is suitable for a wide scope of applications, it is particularly suitable for the receiver to obtain additional information on the corresponding NRT service using the service relevant signaling information, determine how to process and output the corresponding service to a user and determine an operation of an associated application module.

Discussion of the Related Art [0003] Generally, a Non-Real Time (NRT) service is one of powerful applications that will be utilized for future DTV

services. The NRT is accompanied by non-real time transmission (not real-time streaming), storage and viewing operations and transmits a content of a file type on a surplus bandwidth via a broadcast medium such as terrestrial and the like. And, it is expected that the NRT will be implemented various kinds of service functions including push VOD, targeted advertising and the like.

SUMMARY OF THE INVENTION

[0004] Accordingly, the present invention is directed to a broadcast receiver and a method of mapping signaling information to announcement information therein that substantially obviate one or more problems due to limitations and disadvantages of the related art.

[0005] An object of the present invention is to provide a broadcast receiver and a method of mapping signaling information to announcement information, wherein the signaling data for a non-real time (NRT) service can be defined.

[0006] Another object of the present invention is to provide a broadcast receiver and a method of mapping signaling information to announcement information, wherein a scheme for transmitting the above-defined signaling data can be defined.

[0007] Another object of the present invention is to provide a broadcast receiver and a method of mapping signaling information to announcement information, wherein an NRT service is accessible in a manner that the receiver receives and process signaling data for the transmitted NRT
service.

[00081 Another object of the present invention is to provide a method of mapping a content identifier of the signaling data to an identifier of a selected and transmitted content in a receiver.

[0009] A further object of the present invention is to provide a method of receiving and processing a content selected from a service guide configured by using the signaling data in the receiver, which can provide the processed content to a user.

[0010] Additional advantages, objects, and features of the invention will be set forth in part in the description which follows and in part will become apparent to those having ordinary skill in the art upon examination of the following or may be learned from practice of the invention. The objectives and other advantages of the invention may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

[0011] To achieve these objects and other advantages and in accordance with the purpose of the invention, as embodied and broadly described herein, a method of providing a non-real-time (NRT) service may include extracting identification information of first signaling information and second signaling information based upon a program specific information/program and system information protocol (PSI/PSIP) table, receiving the first signaling information and the second signaling information based upon the extracted identification information, constructing and displaying a service guide using the received first signaling information, acquiring first content identification information of a content selected from the displayed service guide, accessing a File Delivery over Unidirectional Transport (FLUTE) session using the received second signaling information, acquiring second content identification information matched with the acquired first content identification information and receiving and storing one or more file constructing corresponding content based upon the acquired second content identification information.

[0012] And, the identification information is extracted using at least one of a virtual channel table (VCT), a data service table (DST) and a program map table (PMT) in the PSI/PSIP table.

[0013] Also, the one or more file, the first signaling information and the second signaling information is received after a sequentially packetizing of an internet protocol (IP), an addressable section and an MPEG-2 transport stream.

[0014] And, the first signaling information is an NRT
content table (NCT) and the second signaling information is an NRT service table (NST).

[0015] Also, the second content identification information is extracted from a file description table (FDT) in the accessed FLUTE session.

[0016] Herein, the method may further include constructing and displaying a service guide using the received first signaling information.

[0017] Herein, the method may further include acquiring first service identification information in connection with the acquired first content identification information from the first signaling information associated with the selected content item in the displayed service guide.

[0018] Herein, the method may further include extracting second service identification information matched with the acquired first service identification information from the received second signaling information.

[0019] In another aspect of the present invention, a broadcasting receiver may include a baseband processor, a first handler, a second handler, a third handler, a controller and a storage unit. Herein, the baseband processor may extract identification information of first signaling information and second signaling information using a program specific information/program and system information protocol (PSI/PSIP) table and receiving the first signaling information and the second signaling information based upon the extracted identification information. A first handler for constructing and displaying a service guide using the received first signaling information. The second handler may acquire a first content identifier from the received first signaling information of a content selected from the displayed service guide. The third handler may access a File Delivery over Unidirectional Transport (FLUTE) session using the received second signaling information and acquiring a second content identifier matched with the acquired first content identifier. The controller may control to receive and store one or more files constructing corresponding content item based upon the acquired second content identifier. And, the storage unit may store the received files.

[0020] The controller may control to extract identification information using at least one of a virtual channel table (VCT), a data service table (DST) and a program map table (PMT) in the PSI/PSIP table.

[0021] The controller may control to receive the one or more file, the first signaling information and the second signaling information is received after a sequentially packetizing of an IP, an addressable section and an MPEG-2 transport stream.

[0022] The controller controls to receive the first signaling information and the second signaling information, and wherein the first signaling information is an NRT content table (NCT) and the second signaling information is an NRT
service table (NST).

[0023] The controller controls to receive the second content identification information from the extracted a file description table (FDT) in the accessed FLUTE session.

[0024] The controller controls to acquire the first service identification information in connection with the acquired with the first content identification information from the first signaling information associated with a content item selected from the displayed service guide.

[0025] The controller controls to extract the second identification information matched with the acquired first service identification information from the received second signaling information.

[0026] Accordingly, the present invention provides the following effects and/or advantages.

[0027] First of all, a transmitting side is able to include signaling data to enable an NRT service, which is a provided by a receiver, to be properly recognized, received and processed.

[0028] Secondly, the receiver is able to receive, process and provide the NRT service to a user using the transmitted signaling data.

[00291 Thirdly, the receiver is able to configure and provide a service guide to a user using the transmitted signaling data.

[0030] Fourthly, the receiver is able to receive and process content selected from the above-configured service guide accurately using signaling information.

[0031] It is to be understood that both the foregoing general description and the following detailed description of the present invention are exemplary and explanatory and are intended to provide further explanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the invention and together with the description serve to explain the principle of the invention. In the drawings:

[0033] FIG. 1 is an exemplary conceptional diagram of an NRT service;

[0034] FIG. 2 is a block diagram of a receiving system according to an embodiment of the present invention;

[0035] FIG. 3 is an exemplary diagram explaining relations between an NRT service, content items and files;

[0036] FIG. 4 is a diagram for a protocol stack of a fixed NRT service configured according to an embodiment of the present invention;

[0037] FIG. 5 is an exemplary diagram of an ATSC service type according to the present invention;

[0038] FIG. 6 is another exemplary diagram of an ATSC
service type according to the present invention;

[0039] FIG. 7 is a diagram for a bit-stream section of a TVCT section configured according to an embodiment of the present invention;

[0040] FIG. 8 is a diagram for a bit-stream syntax of a DST section to identity an NRT application configured according to an embodiment of the present invention;

[0041] FIG. 9 is a diagram for a signaling method in case of transmitting an NRT service through an ATSC broadcasting system according to another embodiment of the present invention;

[0042] FIG. 10 is a flowchart for FIG. 9;

[0043] FIGs. 11 and 12 are a diagram for a bit-stream syntax of NST extracted by a receiver from a received MPEG-2 TS configured according to an embodiment of the present invention;

[0044] FIG. 13 is a diagram for a bit-stream syntax of NRT_component_descriptor() configured according to an embodiment of the present invention;

[0045] FIG. 14 is a diagram for a bit-stream syntax of NRT_component_data_descriptor for FLUTE file delivery configured according to an embodiment of the present invention;

[0046] FIG. 15 is a diagram for a bit-stream syntax of an NCT section configured according to an embodiment of the present invention;

[0047] FIG. 16 is a flowchart for a method of configuring NRT guide information and providing contents according to another embodiment of the present invention;

[0048] FIG. 17 is a diagram for an NRT service signaling structure configured according to another embodiment of the present invention;

[0049] FIG. 18 is a diagram for a bit-stream syntax of an NRT content delivery channel details descriptor configured according to an embodiment of the present invention;

[0050] FIG. 19 is a diagram to explain a FDT schema for mapping a file to content id according to an embodiment of the present invention;

[0051] FIG. 20 is a diagram to explain a FDT schema for mapping a file to content-id according to another embodiment of the present invention; and [0052] FIG. 21 is a flowchart to explain a process for processing an NRT service in a receiver according to an embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

[0053] Reference will now be made in detail to the preferred embodiments of the present invention, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Definitions of Terminologies Used for the Invention [0054] Terminologies used for the present invention are selected from general terminologies, which are currently and widely used, in consideration of functions in the present invention but may vary according to intentions of a person having an ordinary knowledge in the technical field, practices or the advent of new technology, etc. In specific case, a terminology may be arbitrarily chosen by the applicant(s). In this case, its detailed meaning shall be described in Detailed Description of Invention. Therefore, the terminology used for the present invention needs to be defined based on the intrinsic meaning of the terminology and the contents across the present invention instead of a simple name of the terminology.

A conceptional diagram of an Non-Real Time (NRT) service [0055] FIG. 1 is an exemplary conceptional diagram for the NRT service.

[0056] First of all, a broadcasting station transmits an RT (real-time) service according to a conventional method. In doing so, the broadcasting station transmits the RT service or the NRT service using a bandwidth left in the due course.
In this case, the NRT service can contain a news clip, weather information, advertisements, contents for Push video on demand (VOD) and the like.

[0057] Yet, a related art DTV receiver, i.e., a legacy device has the principle that the operation is not affected by an NRT stream included within a channel. However, the related art DTV receiver has a problem in receiving and processing the NRT service provided by a broadcasting station properly because of not having a means for processing unit for the NRT service.

[0058] On the contrary, a broadcast receiver according to the present invention, i.e., an NRT device is able to properly receive and process an NRT service combined with an RT service, thereby providing a viewer with more various functions than those of the related art DTV.

[0059] In this case, the RT service and the NRT service are transmitted on the same DTV channel or different DTV
channels and are transmitted through an MPEG-2 transport packet (TP) or an internet protocol (IP) datagram. Hence, a receiver needs to identify the two kinds of services transmitted on the same or different channel. For this, this specification discloses a method of defining and providing signaling information to enable a receiver to receive and process an NRT service properly. In this case, a broadcasting station provides signaling information. Specifically, at least one unique packet identifier (PID) for identifying an NRT service can be allocated.

A Receiving System [0060] FIG. 2 is a block diagram of a receiving system according to an embodiment of the present invention.

[0061] Referring to FIG. 2, the receiving system mainly includes a part of a baseband processor, a part of an MPEG-2 service demultiplexer (demux) , a part of a stream component handler, a part of a media handler, a part of a file handler and other parts. The units of the receiving system shown in FIG. 2 are explained as follows.

[0062] First of all, the part of the baseband processor includes a tuner 201 and a vestigial side band (VSB) demodulator 202. The tuner 201 detects VSB radio frequency (RF) signal transmitted over the air and then extracts a symbol from the detected VSB RF signal. In this case, the tuner 201 is controlled by a service manager 228. The VSB
demodulator 202 reconstructs meaningful data by demodulating the VSB symbol extracted by the tuner 201.

[0063] The part of the MPEG-2 service demultiplexer includes an MPEG-2 TP buffer/parser 203, a program specific information/program and system information protocol (PSI/PSIP) section/buffer 204, a descrambler 205, an MPEG-2 TP demultiplexer (demux) 206 and a personal video recorder (PVR) storage 207.

[0064] The MPEG-2 TP buffer/parser 203 buffers and reconstructs an MPEG-2 TP carried on a VSB signal and then detects and processes a TP header.

[0065] The PSI/PSIP section/buffer 204 buffers and parses PSI/PSIP section data carried on an MPEG-2 TS. In this case, the parsed PSI/PSIP data is collected by the service manager 228 and is then stored as a service map and guide data in a database.

[0066] The descrambler 205 reconstructs data of a payload for a scrambled packet payload in the MPEG-2 TP using an encryption key or the like delivered from a conditional access (CA) stream handler 216.

[0067] The MPEG-2 TP demultiplexer 206 filters off an MPEG-2 TP varied on a VSB signal or a TP, which is attempted to be processed by the receiver, among the MPEG-2 TP stored in the PVR storage 207 and then relays the filtered TP to a proper processing module. In this case, the MPEG-2 TP
demultiplexer 206 can be controlled by the service manager 228 and the PVR manager 235.

[0068] The PVR storage 207 stores the received MPEG-2 TP
using the VSB signal according to a request made by a user and then outputs the MPEG-2 TP according to a request made by a user. In this case, the PVR storage 207 can be controlled by the PVR manager 235.

[0069] The part of the stream component handler includes a packetized elementary stream (PES) buffer/handler 208, an elementary stream (ES) buffer/handler 209, a program clock reference (PCR) handler 210, a system time clock (STC) unit 211, a digital storage media command and control (DSM-CC) section buffer/handler 212, an IP datagram buffer/header parser 213, a user datagram protocol (UDP) datagram buffer/handler 213, a CA stream buffer/handler 214 and a service signaling section buffer/handler 215.

[0070] The PES buffer/handler 208 buffers and reconstructs a PES carried on an MPEG-2 TS.

[0071] The ES buffer/handler 208 buffers and reconstructs an ES such as audio data, video data or the like, which is transmitted as a PES, and then delivers the reconstructed ES
to a proper A/V decoder 218.

[0072] The PCR handler 210 handles PCR data used for time synchronization of audio and video streams or the like.

[0073] The STC unit 211 corrects a clock value of the A/V
decoder 218 using a reference clock value delivered via the PCR handler 210 to enable time synchronization.

[0074] The DSM-CC section buffer/handler 212 buffers and handles DSM-CC section data for a file transmission via the MPEG-2 TP, an IP datagram encapsulation or the like.

[0075] The IP datagram buffer/header parser 213 buffers and reconstructs an IP datagram, which is encapsulated via DSM-CC addressable section and is then carried on an MPEG-2 TP. The IP datagram buffer/header parser 213 parses a header of each IP datagram through the reconstruction. In this case, the IP datagram buffer/header parser 213 is controlled by the service manager 228.

[0076] If scrambling is applied to a payload in the received IP datagram, the descrambler 214 reconstructs data of the payload using an encryption key for the payload or the like delivered from the CA stream handler 216.

[0077] The UDP datagram buffer/handler 215 buffers and reconstructs a UDP datagram carried on an IP datagram and also parses and processes a UDP header.

[0078] The CA stream buffer/handler 216 buffers and handles such data as a key value for descrambling, e.g., an entitlement management message (EMM) transmitted for a conditional access function carried on an MPEG-2 TS or an IP
stream, an entitlement control message (ECM) and the like.
In this case, an output of the CA stream buffer/handler 216 is delivered to the descrambler 214 to perform a decryption operation of an MPEG-2 TP or an IP datagram that carries AV
data, file data and the like.

[0079] The service signaling section buffer/parser 217 processes an NRT Service Table (NST), an NRT Content Table (NCT) and descriptors related to the NST or the NCT for signaling an NRT service of the present invention, which will be explained later. The processed signaling information is transferred to the NRT service manager 229.

[0080] The part of the media handler is explained as follows. First of all, the part of the media handler includes A/V decoders 218.

[0081] The AV decoders 218 decode compressions of audio and vide data delivered via the ES handler 209 and then processes the decoded data, which are to be presented to a user.

[0082] The part of the file handler is explained as follows. First of all, the part of the file handler mainly includes an Asynchronous Layered Coding/Layered Coding Transport (ALC/CLT) buffer/parser 219, a file description table (FDT) handler 220, an extensible markup language (XML) parser 221, a file reconstruction buffer 222 and a decompressor 223.

[0083] The ALC/LCT buffer/parser 219 buffers and reconstructs ALC/LCT data carried on UDP/IP stream and then parses a header of ALC/LCT and a header extension thereof.
In this case, the ALC/LCT buffer/parser 219 can be controlled by the NRT service manager 229.

[0084] The FDT handler 220 parses and processes a FDT of a File Delivery over Unidirectional Transport (FLUTE) protocol transmitted via an ALC/LCT session. It is able to transfer the processed FDT to the NRT service manager 229. In this case, the FDT handler 220 can be controlled by the NRT
service manager 229.

[0085] The XML parser 221 parses an XML document transmitted via the ALC/LCT session and then delivers the parsed data to such a proper module as the FDT handler 220, the SG handler 227 and the like.

[0086] The file reconstruction buffer 222 reconstructs a file transferred to the ALC/LCT and FLUTE session.

[0087] If the file transferred to the ALC/LCT and FLUTE
session is compressed, the decompressor 223 performs a process for decompressing the compression.

[0088] The file decoder 224 decodes a file reconstructed by the file reconstruction buffer, a file decompressed by the decompressor 223 or a file extracted from the file storage 225.

[0089] The file storage 225 stores and extracts the received file. In this case, the received file may contain NRT content.

[0090] Finally, the remaining parts except for the above-described units are explained as follows.

[0091] First of all, a middleware (M/W) engine 226 processes data of a file that is not an AV stream transferred via a DSM-CC section, an IP diagram and the like and then delivers the processed data to the presentation manager 234.

[0092] The SG handler 227 collects and parses service guide data transferred in an XML document format and then delivers the parsed data to the EPG manager 230.

[0093] The service manager 228 produces a service map by collecting and parsing PSI/PSIP data carried on MPEG-2 TS and service signaling section data carried on an IP stream and then controls an access to a service specified by a user by storing the service map in a service map & guide database.
In this case, the service manager 228 is controlled by an operation controller 230 and then controls the tuner 201, the MPEG-2 TP demultiplexer 206, the IP datagram buffer/handler 213, the NRT service manager 229 and the like.

[0094] The NRT service manager 229 performs overall managements on the NRT service transferred in an object/file format via FLUTE session on an IP layer. The NRT service manager 229 parses the signaling information transferred from the service signaling section buffer/parser 217. And, the parsed signaling information is transferred to the service map & guide database 236 to be stored therein. Moreover, the NRT service manager 229 controls NCT information, which correspond to contents related to a service guide in the signaling information, to be transferred to the EPG manager 230, thereby forming EPG data. In this case, the NRT service manager 229 controls the FDT handler 220, the file storage 225 and the like. Therefore, the NRT service manager 229 receives the FDT from the FDT handler 220, parses the received FDT and then controls received NRT contents to be stored as a hierarchical structure in the file storage 225.
And, the NRT service manager 229 controls the corresponding NRT contents to be extracted from the file storage 225 in case that a user makes a selection for the NRT service.

[0095] The EPG manager 230 receives the service guide data from the SG handler 227, configures EPG data, and then controls the EPG data to be displayed.

[0096] The application manager 231 performs overall managements on processing of application data transferred in such a format as an object, a file and the like.

[0097] The user interface (UI) manager 232 delivers an input of a user via a UI to the operation controller 233 and enables an operation of a process for a user-requested service to be initiated.

[0098] The operation controller 233 processes a user's command delivered via the UI manager 232 and then enables a manager of a necessary module to perform a corresponding action.

[0099] And, the presentation manager 234 provides at least one of A/V data outputted from the A/V decoder 218, file data outputted the middleware (M/W) engine 226 and EPG data outputted from the EPG manager 230 to user via speaker and/or screen.

A description for relations among NRT service, content item and file [00100] FIG. 3 is an exemplary diagram explaining relations between an NRT service, content items and files.

[00101] Referring to FIG. 3, an NRT service can include one or more content items. And, each of the content items can include one or more files. And, each of the content items is an independently playable entity and may correspond to a program or an event in a real time broadcast. Therefore, the NRT service means a group that is serviceable with a combination of the above content items. And, the NRT service corresponds to a channel concept in real time.

[00102] In order for a receiver to properly process the above NRT service, signaling for the corresponding NRT
service is required. The present invention intends to properly process an NRT service received by a receiver by defining and providing the signaling information. Besides, details of the signaling information shall be described in the description of the corresponding part.

A protocol for a fixed NRT Service [00103] First of all, NRT services can be mainly categorized into a fixed NRT service and a mobile NRT service.
In the following description, the fixed NRT service is taken as an example for clarity and convenience of explanation.

[00104] FIG. 4 is a diagram for a protocol stack of a fixed NRT service configured according to an embodiment of the present invention.

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

[00106] In FIG. 4, the fixed NRT service is packetized according to UDP in an IP layer. The UDP packet becomes UDP/IP packet data by being packetized again according to an IP scheme. In this disclosure, the packetized UDP/IP packet data is referred to as an IP datagram for simplicity.

[00107] The NRT content items/files are packetized according to FLUTE scheme or ALC/LCT scheme. The ALC/LCT
packet is transported by being encapsulated in a UDP datagram.
The ALC/LCT/UDP packet is packetized into ALC/LCT/UDP/IP
packet according to IP datagram scheme to become an IP
datagram. This IP datagram is contained in MPEG-2 TS through DSM-CC addressable sections for transport. In this case, the ALC/LCT/UDP/IP packet is the information on FLUTE session and includes a FDT as well.

[00108] A signaling information channel including an NST
and an NCT is packetized according to a UDP scheme. This UDP
packet is packetized according to an IP scheme again to become UDP/IP packet data, i.e., IP datagram. This IP
datagram is also contained in the MPEG-2 TS through the DSM-CC addressable sections for transport.

[00109] And, a PSI/PSIP table is separately defined and contained in the MPEG-2 TS.

[00110] The MPEG-2 TS containing the above described NRT
content items/files, signaling information channel and PSI/PSIP data therein are transferred by being modulated by a predetermined transmission scheme such as VSB transmission scheme.

NRT Service Method [00111] According to the present invention, a fixed NRT
service uses a conventional ATSC terrestrial broadcasting environment. In particular, a fixed NRT service, which is based on a scheme of transporting an IP datagram via DSM-CC
addressable section, can be provided by the following method for example.

[00112] 1. Case of transmission on virtual channel including audio and/or video:

In this case, a service type of a corresponding virtual channel can follow FIG. 5 as stipulated in the conventional ATSC specification. In particular, the service type follows `0x04' indicating ATSC data only service shown in FIG. 5.
Alternatively, the service type can identify an NRT service by being included in another service type of the related art.

[00113] 2. Case of transmission on virtual channel including NRT service only:

Referring to FIG. 6, signaling can be performed to indicate an NRT application (`0x08') by allocating a new service type value.

A terrestrial virtual channel table (TVCT) [00114] FIG. 7 is a diagram for a bit-stream section of a TVCT section configured according to an embodiment of the present invention.

[00115] Referring to FIG. 7, a TVCT section is described as having a table format similar to that of an MPEG-2 private section. However, this is merely exemplary, and the present invention will not be limited to the example given herein.

[00116] The TVCT can be divided into a header, a body and a trailer. The header part ranges from table-id field to protocol version field. And, transport-stream-id field is a 16-bit field and indicates an MPEG-2 TSID within a program association table (PAT) defined by a PID value of 10' for multiplexing. In the body part, num_channels_in_section field is an 8-bit field and indicates the number of virtual channels within a VCT section. Finally, the trailer part includes CRC 32 field.

[00117] First of all, the header part is explained as follows.

[00118] A table id field is an 8-bit unsigned integer number that indicates the type of table section being defined herein. For the terrestrial-virtual-channel-table-sect ion(), the table id shall be `OxC8'.

[00119] A section-syntax-indicator is a one-bit field which shall be set to `1' for the terrestrial virtual channel table section().

[00120] A private-indicator field (1-bit) shall be set to `1' .

[00121] A section length is a twelve bit field, the first two bits of which shall be `00'. This field specifies the number of bytes of the section, starting immediately following the section-length field, and including the CRC.
The value in this field shall not exceed 1021.

[00122] A table-id-extension field is set to `0x000'.
[00123] A version number field (5-bit) represents the version number of the VCT.

[00124] A current-next-indicator is a one-bit indicator, which when set to `1' indicates that the VCT sent is currently applicable.

[00125] A section number field (8 bit) gives the number of this section. The section number of the first section in the TVCT shall be `0x00'.

[00126] A last-section-number field (8 bit) specifies the number of the last section (that is, the section with the highest section-number) of the complete TVCT.

[00127] A protocol-version is an 8-bit unsigned integer field whose function is to allow, in the future, this table type to carry parameters that may be structured differently than those defined in the current protocol. At present, the only valid value for protocol-version is zero. Non-zero values of protocol version may be used by a future version of this standard to indicate structurally different tables.
[00128] The body part is explained as follows.

[00129] A num channels in section field (8-bit) specifies the number of virtual channels in this VCT section. The number is limited by the section length.

[00130] A short name field represents the name of the virtual channel, represented as a sequence of one to seven 16-bit code values.

[00131] A major_channel_number field is a 10-bit number that represents the "major" channel number associated with the virtual channel being defined in this iteration of the "for" loop. Each virtual channel shall be associated with a major and a minor channel number. The major channel number, along with the minor channel number, act as the user's reference number for the virtual channel.

[00132] A minor-channel-number field is a 10-bit number in the range `0' to `999' that represents the "minor" or "sub"-channel number. This field, together with major_channel_number, performs as a two-part channel number, where minor-channel-number represents the second or right-hand part of the number. When the service-type is analog television, minor-channel-number shall be set to `0'.
Services whose service-type is either ATSC_digital_television or ATSC audio only shall use minor numbers between `1' and 199'. The value of minor-channel-number shall be set such that in no case is a major-channel-number/minor-channel-number pair duplicated within the TVCT.

[00133] A modulation mode field is an 8-bit unsigned integer number that indicates the modulation mode for the transmitted carrier associated with this virtual channel.

[00134] A carrier frequency field includes the recommended value for these 32 bits is zero. Use of this field to identify carrier frequency is allowed, but is deprecated.

[00135] A channel TSID is a 16-bit unsigned integer field in the range 10x0000' to `OxFFFF' that represents the MPEG-2 TSID associated with the TS carrying the MPEG-2 program referenced by this virtual channel.

[00136] A program number field is a 16-bit unsigned integer number that associates the virtual channel being defined here with the MPEG-2 PROGRAM ASSOCIATION and TS PROGRAM MAP tables.
For virtual channels representing analog services, a value of `OxFFFF' shall be specified for program-number.

[00137] An ETM location is 2-bit field specifies the existence and the location of an Extended Text Message (ETM).
[00138] An access controlled is a 1-bit Boolean flag that indicates, when set, that the events associated with this virtual channel may be access controlled. When the flag is set to `0', event access is not restricted.

[00139] A hidden is a 1-bit Boolean flag that indicates, when set, that the virtual channel is not accessed by the user by direct entry of the virtual channel number. Hidden virtual channels are skipped when the user is channel surfing, and appear as if undefined, if accessed by direct channel entry. Typical applications for hidden channels are test signals and NVOD services. Whether a hidden channel and its events may appear in EPG displays depends on the state of the hide guide bit.

[00140] A hide guide is a Boolean flag that indicates, when set to 10' for a hidden channel that the virtual channel and its events may appear in EPG displays. This bit shall be ignored for channels which do not have the hidden bit set, so that non-hidden channels and their events may always be included in EPG displays regardless of the state of the hide guide bit. Typical applications for hidden channels with the hide guide bit set to `1' are test signals and services accessible through application-level pointers.

[00141] A service type is a 6-bit enumerated type field that shall identify the type of service carried in this virtual channel.

[00142] A source id field (16-bit) represents a programming source associated with a virtual channel.

[00143] A descriptors length field is total length (in bytes) of the descriptors for this virtual channel that follows.

[00144] A descriptor() field includes zero or more descriptors, as appropriate, may be included.

[00145] An additional descriptors length field is total length (in bytes) of the VCT descriptor list that follows.
[00146] The trailor part is explained as follows. CRC-32 is a 32-bit field that contains the cyclic redundancy check (CRC) value that ensures a zero output from the registers in the decoder.

[00147] NRT content is transferred through IP mechanism. In order to transfer IP datagram through a digital broadcast stream, ATSC has regulated ATSC A/90 and A/92 specifications.

[00148] In the above description, the data service table (DST) may be received through a PID included in service-location-descriptor. And, it is able to know a type of application and detailed information of a data broadcast stream carried on this channel through the DST.

[00149] According to FIG. 5, it is able to use a DST to identify an NRT service. The DST is explained as follows.
[00150] FIG. 8 is a diagram for a bit-stream syntax of a DST section to identity an NRT application configured according to an embodiment of the present invention.

[00151] The semantics of the fields comprising the data-service-table-bytes structure are defined below.

[00152] An sdf protocol version field (8-bit) shall be used to specify the version of the Service Description Framework (SDF) protocol. The value of this field shall be set to `OxOl'. The value `OxOO' and the values in the range `0x02' to `OxFF' shall be ATSC reserved.

[00153] An application-count-in-section field (8-bit) shall specify the number of applications listed in the DST section.
[00154] A compatibility descriptor() field shall contain a DSM-CC compatibility descriptor. Its purpose shall be to signal compatibility requirements of the application so that the receiving platform can determine its ability to use this data service.

[00155] An app_id_byte_length field (16-bit) 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 `Ox0000' shall indicate that no app id description field or app_id_byte fields follow. The value `0x0001' is forbidden.

[00156] An app_id_description field (16-bit) shall specify the format and semantics of the following application identification bytes.

[00157] Table 1 specifies the values and associated formats.
[Table 1) Value Application Identifier Format Ox0000 DASE application Ox0001 ATSC reserved 0x0002 ATSC A/92 Application 0x0003 NRT Application 0x0004-Ox7FFF ATSC reserved 0x8000-OxFFFF User private [00158] An app id byte field (8-bit) shall represent a byte of the application identifier.

[00159] A tap count field (8-bit) shall specify the number of Tap() structures used by this application.

[00160] A protocol-encapsulation field (8-bit) shall specify the type of protocol encapsulation used to transmit the particular data element referred to by the Tap().

[Table 2]
Value Encapsulated Protocol Ox00 Not in a MPEG-2 Transport Stream Asynchronous non-flow controlled scenario of the Ox01 DSM-CC Download protocol encapsulated in DSM-CC
sections 0x02 Non-streaming Synchronized Download protocol encapsulated in DSM-CC sections 0x03 synchronous 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 Synchronous streaming multiprotocol datagrams in 0x08 PES using LLC/SNAP header 0x09 Synchronized streaming IP datagrams in PES
OxOA Synchronous streaming IP datagrams in PES
OxOB Proprietary Data Piping OxOC SCTE DVS 051 asynchronous protocol [19]
Asynchronous carousel scenario of the DSM-CC
OxOD Download protocol encapsulated in DSM-CC sections Reserved for harmonization with another standard OxOE
body OxOF-Ox7F ATSC reserved 0x80-OXff User defined [00161] An action type field (7-bit) shall be used to indicate the nature of the data referred to by the Tap().
[00162] A resource location field (1-bit) shall specify the location of the Association Tag field matched with the association tag value listed in 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 11' when the matching association tag resides in a DSM-CC Resource Descriptor within the Network Resources Table of this Data Service.

[00163] A tap id field (16-bit) 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 DST. 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.

[00164] A use field (16-bit) 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 unknown.

[00165] An association tag field (16-bit) shall uniquely identify either a data elementary stream listed in the PMT or a DSM-CC Resource Descriptor listed in the Network Resource Table. In the former case, the value of this field shall be matched with 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.

[00166] A selector() field 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.

[00167] A tap_info_length field (16-bit) shall specify the number of bytes of the descriptors following the tap info length field.

[00168] A descriptor() field shall follow the descriptor format.

[00169] An app info length field (8-bit) shall specify the number of bytes of the descriptors following the app info length field.

[00170] Another descriptor() field shall follow the descriptor format.

[00171] An app_data_length field (16-bit) shall specify the length in bytes of the following app-data-byte fields.

[00172] An app data byte field (8-bit) shall represent one byte of the input parameters and other private data fields associated with the application.

[00173] A service-info-length (8-bit) shall specify the number of bytes of the descriptors following the service-info-length field.

[00174] Another descriptor() field shall follow the descriptor format.

[00175] A service_private_data_length field (16-bit) shall specify the length in bytes of the private fields to follow.
[00176] A service_private_data_byte field (8-bit) shall represent one byte of the private field.

[00177] After the NRT application has been identified, an IP stream, on which a well-known IP address for delivering NRT service signaling data delivered via an IP layer, is searched for using tap information.

[00178] If a value of protocol-encapsulation is set to `0x04', an asynchronous IP datagram is transferred. If selector type is set to `0x0102', a value of device-id, which indicates a destination address, is delivered through selector bytes. In order to accurately interpret a value of the selector bytes, multiprotocol_encapsulation_descriptor is used. And, the number of valid bytes in the device-id value is signaled.

[00179] Therefore, it is able to know a multicast address (or, an address range) of an IP datagram carried on the corresponding PID via the tap information.

[00180] It is checked whether a well-known IP address, to which NRT service signaling data will be delivered, is loaded on the tap. This is received in the first place. An IP packet is then received.

[00181] The NRT service signaling data is extracted from the IP packet. The extracted NRT service signaling data is delivered to and processed by an NRT application manager. An NRT service can be then initiated.

[00182] As mentioned in the above description, an NRT
service signaling channel is multicasted by being encapsulated in an IP datagram via a well-known IP address.

[00183] FIG. 9 is an exemplary diagram for a signaling method in case of transmitting an NRT service through an ATSC
broadcasting system according to another embodiment of the present invention, and FIG. 10 is an exemplary flowchart for FIG. 9.

[00184] FIG. 9 shows a method of configuring a separate NRT
service signaling channel via an IP side. In this case, the NRT service signaling channel is multicasted by being encapsulated in an IP datagram via a well-known IP address. A
signaling structure for this case is shown in FIG. 9. In particular, it can be observed that a separate NRT service signaling channel exists as an IP multicast stream, whereas every signaling is performed by a PSIP side.

[00185] Referring to FIG. 10, after a power of a receiver has been turned on, if a default channel or a channel by a user is selected [S1001], the receiver receives a TVCT or a PMT [S1002].

[00186] Regarding this, information on a stream configuring each virtual channel is signaled to service-location-descriptor or the TVCT or the ES_loop of the PMT.

[00187] Therefore, the receiver determines a type of a service provided on a selected channel by parsing service type within the received TVCT [S1003]. For instance, if a value of the service type is set to `0x02', a type of a corresponding service provided on the selected channel may mean a digital A/V/Data service type. If a value of the service type is set to `0x04', a type of a corresponding service provided on the selected channel may mean a data only service type. If a value of the service_type is set to `0x08', a type of a corresponding service provided on the selected channel may mean an NRT only service type.

[00188] As a result of the determining step S1003, if the corresponding service type is not a general A/V service, PID
(`0x61') of a data service table (DST) is extracted by parsing service-location-descriptor in the channel loop of the TVCT [S10041.

[00189] Subsequently, the DST is received using the extracted PID [S10051.

[00190] It is then determined whether the corresponding service provided on the selected channel is an NRT service from the received DST [S1006]. In doing so, the determination of a presence or absence of the NRT service can be performed by checking app_id_description within the DST. For instance, if a value of the app_id_description is set to `0x0003', it means that the corresponding service is the NRT application.

[00191] As a result of the determining step S1006, if the corresponding service is the NRT service, a tap including an NRT service signaling channel is extracted [S10071 And, stream PID including association_tag of the tap on the PMT is extracted [S1008].

[00192] After a stream of the PID has been received, a DSM-CC addressable section is processed [S1009].

[00193] Subsequently, after an IP packet has been received from a well-known IP address of the NRT service signaling channel [S1010], an NRT service is provided by processing the NRT service signaling data within the received IP packet [S10111.

[00194] Regarding this, after whether the NRT application exists on the virtual channel has been checked by the above method, an IP stream carrying the well-known IP address, to which the NRT service signaling data carried via an IP layer is delivered, is searched for using tap information.

[00195] If a value of protocol encapsulation is set to `0x04', an asynchronous IP datagram is transferred. If selector type is set to `0x0102', a value of device-id indicating a destination address is delivered via selector bytes.

[00196] Therefore, it is able to know a PID of a transport stream, on which the corresponding data is carried, through the tap information on a multicast address (or, an address range) of an IP diagram. It is checked whether a well-known IP address, to which NRT service signaling data will be delivered, is loaded on the tap. This is received in the first place. An IP packet is then received.

[00197] Subsequently, NRT service signaling data is extracted from the IP packet. The extracted NRT service signaling data is delivered to an NRT application manager. A
corresponding service is then initiated.

NST & NCT

[00198] In the following description, NST and NCT carried on a signaling information channel and accompanied descriptors thereof for providing information for signaling an NRT service are explained in order.

[00199] As mentioned in the foregoing description of Fig. 3, an NST/NCT table section can be transferred by being included as an IP stream within a virtual channel.

[00200] Examples for fields carried on NST are described as follows. FIGs. 11 and 12 are an exemplary diagram for a bit-stream syntax of NST configured according to an embodiment of the present invention.

[00201] In this case, although a corresponding syntax is written as an MPEG-2 private section to help the understanding, a format of corresponding data can have any type. For instance, SDP () is used to perform signaling via a SAP (session announcement protocol).

[00202] NST/NCT describes service information and IP access information within a virtual channel carrying the NST/NCT.
The NST/NCT also provides broadcast stream information of a corresponding service using TSID that is an identifier of a broadcast stream to which each service belongs. And, NST
according to the present embodiment includes description information of each fixed NRT service within one virtual channel. And, other side information can be included in a descriptor region.

[00203] A table id field is an 8-bit unsigned integer number that indicates the type of table section being defined in NST.
[00204] A section syntax indicator field (1-bit) shall be set to 10' to always indicate that this table is derived from the short form of the MPEG-2 private section table.

[00205] A private indicator field (1-bit) shall be set to `1'.

[00206] A section length field (12-bit) specifies the number of remaining bytes this table section immediately following this field. The value in this field shall not exceed 4093 (`OxFFD').

[00207] A table-id-extension field (16-bit) is table-dependent. It shall be considered to be logically part of the table id field providing the scope for the remaining fields.
Herein, the table-id-extension field includes an NST_protocol_version field.

[00208] The NST_protocol_version is 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.

[00209] A version number field (5-bit) represents a version number of the NST.

[00210] A current-next-indicator is 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 10') must be sent. An update to the currently applicable table shall be signaled by incrementing the version-number field.

[00211] A section number field (8-bit) 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.

[00212] A last-section-number field (8-bit) shall give the number of the last section (i.e., the section with the highest section number) of the NRT Service table of which this section is a part.

[00213] A carrier frequency field (32-bit) indicates transport frequency corresponding to a channel.

[00214] A channel TSID field (16-bit) represents a transport stream including an MPEG-2 program referenced to a virtual channel and an MPEG-2 TSID associated with the transport stream.

[00215] A source id field (16-bit) represents a programming source associated with a virtual channel.

[00216] A num NRT services field (8-bit) specifies the number of NRT services in this NST section.

[00217] According to an embodiment of the present invention, an NST provides information for a plurality of fixed NRT
services using a `for' loop. Field information which is included in each fixed NRT service is explained as follows.

[00218] An NRT service status is 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 11') 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.

[00219] A SP indicator is a 1-bit field that shall indicate, when set, that service protection is applied to at least one of the components needed to provide a meaningful presentation of this NRT Service.

[00220] A CP indicator is 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.

[00221] An NRT service id is 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.

[00222] A short NRT service name length is 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 10'.

[00223] A short NRT service name field is a short name of the NRT Service. When there is no short name of this NRT
Service, this field shall be filled with NULLs (`0x00').

[00224] An NRT service category is a 6-bit enumerated type field that shall identify the type of service carried in this IP Service.

[00225] A num components field (5-bit) specifies the number of IP stream components in this NRT Service.

[00226] An IP version flag is a 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, and component_destination_IP_address fields are for IPv6.

[00227] A source IP address flag is 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.

[00228] An NRT service destination IP address flag is a 1-bit Boolean flag that indicates, when set to 11', that an NRT service destination IP address value is present, to serve as the default IP address for the components of this NRT
Service).

[00229] A source IP address 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 10'. 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.

[00230] An NRT service destination IP address field shall be present if the NRT_service_destination_IP_address_flag is set to All and shall not be present if the NRT service destination IP address flag is set to `0'. If this NRT service destination IP address is not present, then the component_destination_IP_address field shall be present for each component in the num_components loop. The conditional use of the 128 bit-long address version of this field is to facilitate possible use of IPv6 in the future, although use of IPv6 is not currently defined.

[00231] According to an embodiment of the present invention, the NST provides information for a plurality of components using a `for' loop.

[00232] An essential-component-indicator is 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.

[00233] A port_num_count 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.

[00234] A component_destination_IP_address_flag is a 1-bit Boolean flag that shall indicate, when set to `1', that the component_destination_IP_address is present for this component.

[00235] A component_destination_IP_address field shall be present if the component_destination_IP_address_flag is set to `l' and shall not be present if the component_destination_IP_address_flag is set to 10'. 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.

[00236] A component_destination_UDP_port_num is a 16-bit unsigned integer field that represents the destination UDP
port number for this UDP/IP stream component.

[00237] A num_component_level_descriptors is a 16-bit unsigned integer field, that represents the number of descriptors providing additional information for IP stream component, may be included.

[00238] A component_level_descriptors field includes one or more descriptors providing additional information for this IP
stream component, may be included.

[00239] A num NRT service level descriptors field (4 bit) specifies the number of NRT service level descriptors for this service.

[00240] An NRT service level descriptor() field includes zero or more descriptors providing additional information for this NRT Service, may be included. This detailed service type can include a portal service for providing web contents, Push VOD, A/V download or the like.

[00241] A num virtual channel level descriptors field (4-bit) specifies the number of virtual channel level descriptors for this virtual channel.

[00242] A virtual channel level descriptor() includes zero or more descriptors providing additional information for the virtual channel which this NST describes, may be included.

[00243] An NRT service is transferred via FLUTE and access information in an NST table is connected to FLUTE session information as follows. A Source IP address becomes a source IP address of a same server that transmits all channels of FLUTE session. NRT service destination IP Address is signaled if there exists a destination IP address at a session level of this FLUTE session.

[00244] A component can be mapped to a channel within a FLUTE session and can signal a separate destination IP
address per channel (this is different from an IP address signaled by a session unit) through component_destination_IP_address. Moreover, a destination port number is signaled through component_destination_UDP_port_num. And, it is able to additionally designate the number of destination ports starting from component_destination_UDP_port_num through port_num_count.

[00245] By designating ports to a plural number, it is able to construct a plurality of channels for one destination IP

address. In this case, one component is able to designate a plurality of channels. Yet, it is preferable that a channel is identified via a destination IP address in general. In this case, one channel can be regarded as mapped to one component.

[00246] Content items/files for an NRT service are transferred through FLUTE and corresponding FLUTE session information is signaled using access information in an NST
table. FIG. 13 is an exemplary diagram for a bit-stream syntax of NRT_component_descriptor() configured according to an embodiment of the present invention.

[00247] 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.

[00248] In the following description, each field information carried on NRT component descriptor shown in FIG.
13 is described.

[00249] A descriptor tag is 8-bit unsigned integer. It shall have the value, identifying this descriptor as the NRT component descriptor.

[00250] A descriptor length is 8-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor).

[00251] A component_type field (7-bit) 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"
within the range of 96 to127. 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.

[00252] Note that additional values of the component_type field within the range of 43 to 71 can be defined in future versions of this standard. The NRT service stream transmitted through FLUTE protocol further requires parameters further to signal a FLUTE session as a Table 3. In the Table 3, 138' of component-type being defined for FLUTE component in the ATSC
or 143' of component type newly being defined for transmission NRT may be used.

[Table 3]

component_type Meaning 0-34 Assigned or reserved by IANA, except that 20-24, 27, and 29-30 are unassigned 35 H.264/AVC video stream component (assigned by TSC use) 36 SVC enhancement layer stream component (assigned by ATSC use) 37 HE AAC v2 audio stream component (assigned by TSC use) 38 FLUTE file delivery session (assigned by ATSC
se) 39 STKM stream component (assigned by ATSC use) 40 LTKM stream component (assigned by ATSC use) 41 OMA-RME DIMS stream component (assigned by TSC use) 42 TP timebase stream component (assigned by TSC use) 43 - 71 [Unassigned by IANA and reserved by ATSC use]
72-76 Reserved by IANA
77-95 nassigned by IANA
96-127 Designated by IANA for dynamic use [00253] A num STKM streams is an 8-bit unsigned integer field that shall identify the number of STKM streams associated with this component.

[00254] A STKM stream id is 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.

[00255] An NRT_component_data (component_type) is explained as follow. 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.

[00256] The FDT of the FLUTE sessions which is 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.

[00257] Therefore, the present invention obtains information for accessing a FLUTE session carrying a corresponding content using NST to receive a content selected from a service guide constructed using NCT. And, the present invention intends to map information on a content item of NCT
to information on a file transferred via a corresponding FLUTE session. In this case, identification of a service including the selected content item can be done via the NRT service id of the aforesaid NET. Yet, as mentioned in the foregoing description of FIG. 3, in order to know one or more content items included in each NRT service and files belonging to the content items in further detail, mapping to a content identifier within FDT information on a FLUTE
session is necessary rather than information on the FLUTE
session carrying the corresponding content item(s).

[00258] The NRT service is transferred via FLUTE and access information in an NST is connected to FLUTE session information as follows. A Source IP address becomes a source IP address of a same server that transmits all channels of FLUTE session. NRT service destination IP Address is signaled if there exists a destination IP address at a session level of this FLUTE session.

[00259] A component can be mapped to a channel within a FLUTE session and can signal a separate destination IP
address per channel (this is different from an IP address signaled by a session unit) through component_destination_IP_address. Moreover, a destination port number is signaled through component_destination_UDP_port_num. And, it is able to additionally designate the number of destination ports starting from component_destination_UDP_port_num through port num count.

[00260] By designating ports to plural number, it is able to construct a plurality of channels for one destination IP
address. In this case, one component is able to designate a plurality of channels. Yet, it is recommended that a channel is identified via a destination IP address in general. In this case, one channel can be regarded as mapped to one component.

[00261] In order to signal an additional attribute of a component constructing a session, it is able to use component_attribute_byte. Additional parameters required for signaling a FLUTE session can be signaled through this field.

[00262] In order to signal the FLUTE session, parameters are necessary. Such parameters include necessary parameters and parameters which are selectively necessary in association with the FLUTE session. First, the necessary parameters include a "source IP address" parameter, a "number of channels in the session" parameter, a "destination IP address and port number for each channel in the session" parameter, a "Transport Session Identifier (TSI) of the session" parameter and a "start time and end time of the session" parameter, and the parameters which are selectively necessary in association with the FLUTE session include an "FEC object transmission information" parameter, a "some information that tells a receiver in the first place, that the session contains files that are of interest", and a "bandwidth specification"
parameter.

[00263] The "number of channels in the session" parameter may be explicitly provided or may be obtained by summing the number of streams configuring the session. Among the parameters, the "start time and end time of the session"
parameter may be signaled through the NST suggested by the present invention, and the "source IP address" parameter, the "destination IP address and port number for each channel in the session" parameter, the "Transport Session Identifier (TSI) of the session" parameter and the "number of channels in the session" parameter may be signaled through session-description-descriptor.

[00264] FIG. 14 is an exemplary diagram for a bit-stream syntax of an NCT section configured according to an embodiment of the present invention.

[00265] 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.

(00266] In the following description, each field of NRT_component_data_descriptor is explained in detail.

[00267] A TSI is a 16-bit unsigned integer field, which shall be the Transport Session Identifier (TSI) of the FLUTE
session.

[00268] A session-start-time indicates 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.

[00269] A session-end-time indicates 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.

[00270] A tias bandwidth indicator is a 1-bit field that flags the inclusion of Transport Independent Application Specific (TIAS) bandwidth information. This bit shall be set to `1' to indicate the TIAS bandwidth field is present, and it shall be set to 10' to indicate the TIAS bandwidth field is absent.

[00271] An as-bandwidth-indicator is a 1-bit field that flags the inclusion of Application Specific (AS) bandwidth information. This bit shall be set to 11' to indicate the AS
bandwidth field is present, and it shall be set to 10' to indicate the AS bandwidth field is absent.

[00272] A FEC OTI indicator is a 1-bit indicator that indicates whether FEC Object Transmission Information is provided.

[00273] A tias bandwidth field has a value. This value shall be one one-thousandth of the TIAS maximum bandwidth, rounded up to the next highest integer if necessary.

[00274] An as bandwidth has a value. This value shall be the AS maximum bandwidth.

(00275] A FEC_encoding_id field identifies a FEC encoding ID used in this FLUTE session.

[00276] A FEC instance id field identifies a FEC instance ID used in this FLUTE session.

[00277] By signaling the above described parameters via FLUTE component data bytes, it is able to provide all information mandatory to receive a FLUTE session. And, it is able to use a method of receiving FDT via this session, obtaining information all files carried on a FLUTE session via the received FDT and receiving theses files.

[00278] This FLUTE component descriptor can be delivered via component-level-descriptor loop of NST. In case that there is a plurality of FLUTE channels, such parameters at a session level as TSI, session-start-time, session-end-time and the like should be signaled only once. Hence, one of components of several channels can transmit a FLUTE component descriptor via Component-level-descriptor loop.

[00279] In the following description, NCT is explained.

[00280] FIG. 15 is a diagram for a bit-stream syntax of an NCT section configured according to an embodiment of the present invention.

[00281] In the following description, explained is NCT
associated with signaling/announcement of an NRT content transmitted per NRT content delivery channel signaled via the above described NST.

[00282] In FIG. 15, an NCT is newly defined to signal NRT
content. This is just one of various embodiments and other methods are considerable as well. Via NCT, it is able to signal an NRT content carried on a specific NRT content delivery channel. Information of each field constructing an NCT section is explained in detail as follows. First of all, a table-id field (8 bits) identifies whether a corresponding table section is a table section constructing an NCT.

[00283] An NRT service id field describes a service id of an NRT content delivery channel that delivers a content described in NOT.

[00284] A version number field indicates a version number of NOT. Hence, a receiver is able to know whether an NCT
content is changed, using the version number.

[00285] A num contents in section field indicates the number of contents described in NCT or the number of contents (or, files) carried on a virtual channel described as source id.

[00286] A content version field indicates a version number for content (or a file) having a specific content id value.
In particular, if a content id, which was received and stored in advance by a receiver, is set to `0x0010', a same content, i.e., a file having a content id value set to `0x0010' is transferred. If the content version is different to that of the previously received and stored content, a content newly announced via NCT is received to update or replace the previously stored content. According to the present embodiment, the content version field means a serial number indicating a version of release but may be able to represent a real published (released) time in direct. In this case, if it is difficult to represent a published time using the content-version field, it is able to use a new field capable of representing the published (released) time.

[00287] A content-id field indicates an ID value capable of identifying content (or, a file), which will be received and stored, uniquely.

[00288] A content-available-start-time field indicates a start time of a FLUTE session capable of receiving content.
And, a content-available-end-time field indicates an end time of the FLUTE session capable of receiving the content.

[00289] A content-length-in-seconds field indicates a real playback time of a corresponding content by a unit of second if the content (or the file) is an A/V file.

[00290] A content size field indicates a size of content (or, a file) by a byte unit.

[00291] A content-delivery-bit-rate field indicates a bit rate for transmitting content (or, a file) and means a target bit rate. In particular, this field indicates a bandwidth that will be allocated when a service provider or a broadcasting station transmits a corresponding content. Using this information, a receiver is aware of a minimum time consumed for receiving a corresponding file using the content-size and the content_delivery_bit_rate. Namely, it is able to provide a user with corresponding information by estimating a time taken to receive content. In this case, minimum time for receiving is obtained from calculating (content-size*8)/(content_delivery_bit_rate) by a unit of seconds.

[00292] A content_title_length field indicates a length of content_title_text() by a byte unit. Using this, it is able to know how many bytes need to be read to enable a receiver to exactly obtain content title text() information.

[00293] A content title text () field is a content title in the format of a multiple string structure (MSS).

[00294] As a method of constructing the above described NST, one or more NRT channels can include one channel.

[00295] In this disclosure, an NRT channel is constructed by an NRT service unit. And, it is capable to have at least one FLUTE session for transferring a file via FLUTE.

[00296] In general, a FLUTE session can be uniquely identified/referenced using such a parameter as a TSI, an IP, a port address and the like and is temporally bound to a session-start-time and a session-end-time.

[00297] In constructing a table, using session-start-time and session-end-time, a FLUTE session during this time period is announced.

[00298] It is able to configure information on all NRT
channels, which are currently transmitted or shall be transmitted in the future, with one table. This can be divided into a present time (a predetermined period from a present time) and a future time (after the period defined as the present time). Alternatively, the information can be sent by being divided into three sections including a predetermined time within a present time (e.g., 24 hours), a predetermined time after the former predetermined time (e.g., 24 hours) and a time after the latter predetermined time and then constructing tables for the three sections, respectively.

[00299] Moreover, using a table id, it is able to discriminate whether it indicates guide information on a currently receivable content or guide information on a content receivable in the future. This relates to a method of separating an NRT service receivable within a short time range from a current time and services receivable after the time into different tables and then transmitting the tables.

[00300] In case of receiving the guide information on a content receivable in the future, a receiver performs temporal alignment using available-start-time and available-end-time information of each content and enables the guide information on the NRT service to be outputted to a user.

[00301] Yet, despite changing a table constructing method different from the above described example, each field constructing a table element shall be identical.

A Method for Providing an NRT Service [00302] A receiver constructs NRT guide information using the above described NRT service signaling data and then displays the constructed NRT guide information to provide to a user. In this case, a method of constructing the NRT guide information may use a received NCT or NST for example. This will be explained in the following descriptions of embodiments.

[00303] FIG. 16 is a flowchart for a method of configuring NRT guide information and providing contents according to another embodiment of the present invention.

[00304] Referring to FIG. 16, a receiver checks an NRT
service carried on a virtual channel [S1601] and then accesses an NRT signaling channel transmitted via an IP layer [S16021.

[00305] Subsequently, NST is extracted from the accessed NRT signaling channel [S1603].

[00306] Detailed information on an NRT content delivery channel per NRT service is obtained from the extracted NST
[S16041.

[00307] The receiver parses the extracted NST, connects the NRT service, and receives and pre-stores the NRT contents transferred through the FLUTE session and FDT information of the received NRT contents [S1605]. Herein, during PID of TP
including an NCT, the receiver is known the corresponding PID
which is previously assigned or recognized well-known.

[00308] An NCT having NRT_service_id matching a service-id value per the NRT content delivery channel is extracted from the obtained detailed information [00309] NCT is received [S1606]. The receiver obtains detailed information of NRT contents using each field in the received NCT [51607]. NRT guide information is constructed using the detailed information obtained in the step S1607, e.g., content-delivery-bit-rate, content-available-start-time, content-available-end-time, content title text(), etc. and is then displayed [S16081.

[00310] If a signal indicating that a specific NRT content has been selected by a user via the displayed NRT guide information is received [S1609], the receiver determines content id in the pre-stored FDT and content identifier of the selected NRT content. And the receiver reproduces corresponding NRT content [S1610].

An NRT Service Signaling Architecture [00311] A signaling structure of the above described NRT
service is shown in FIG. 17.

[00312] FIG. 17 is a diagram for an NRT service signaling structure configured according to another embodiment of the present invention.

[00313] Referring to FIG. 17, each ATSC virtual channel includes at least one of content delivery channel to be transferred as IP stream including each NRT service and NRT
service signaling channel to be transferred as IP stream transferring signaling information of each content delivery channel. At this time, the NST is transferred via the NRT
service signaling channel. The NST includes a table entry and signals the content delivery channel transferring corresponding NRT service. For instance, three NRT channels are provided on ATSC Virtual Channel 0 and NRT channels 0, 1 and 2 are NRT content delivery channels. In case of ATSC
Virtual Channel 1, three NRT channels are provided on NRT

channel 5. And, NRT channels 3, 4 and 5 are NRT content delivery channels. In particular, one virtual channel includes one or more NRT channels and the NRT channel can be an NRT content delivery channel. And, an NST is able to identify each of the NRT channels or each of the NRT content delivery channels. Each of the NRT channels carries an IP
stream. On this NRT service signaling, a signaling flow according to a method of accessing an NRT content delivery channel is available.

NRT Content Delivery Channel [00314] As a method of accessing an NRT content delivery channel for carrying NRT content, the following method is available.

[00315] A method of directly signaling NRT content delivery channel information via an NST table is for directly delivering basic information on an NRT channel and access information via an NST. If an NST side performs this NRT
channel metadata transmission, the following advantages exist.

[00316] First of all, in this case, by directly signaling in NST without an additional process for receiving and processing separate service guide information, it is able to receive channel metadata in the early timing point. Therefore, it is able to raise a service access speed. Moreover, it is able to perform update signaling for a changed item of a channel in a broadcasting environment more quickly and by real time.

[003171 Thus, if NRT service information carrying an NRT
content delivery channel on an NST is directly signaled, a content delivery channel access is possible with an NST only without a separate signaling process.

[00318] An NRT content delivery channel for carrying real NRT content can have an NRT channel type value set to `OxOF'.
NRT Content Delivery Channel Details Descriptor [00319] In order to perform signaling on an NRT content delivery channel via an NST in the course of the above process, the following method is available. It is able to identify an NRT service carrying an NRT content delivery channel if a service category value is set to 'OxOF'.
Additional information of an NRT content delivery channel can be delivered being transmitted in a manner that an NRT
content delivery channel details descriptor exemplarily shown in Fig 17 is inserted in a descriptor loop of NST.

[00320] FIG. 18 is a diagram for a bit-stream syntax of an NRT Content delivery channel details descriptor configured according to an embodiment of the present invention.

[003211 Fields of an NRT Content delivery channel details descriptor are explained in detail as follows.

[00322] A descriptor tag is 8-bit unsigned integer shall have the value 'OxTBD', identifying this descriptor as NRT content delivery channel details descriptor.

[00323] A descriptor length is 8-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor.

[00324] A storage reservation is 32-bit unsigned integer shall specify minimum device storage (in bytes) required for subscription to this channel.

[00325] An Updated is 32-bit unsigned integer, which shall represent time when the channel metadata was last updated as the number of GPS seconds since 00:00:00 UTC, January 6, 1980.

[00326] A content types length field shall specify the length (in bytes) of the content_types_text ().

[00327] A content types text() field shall give a comma-separated list of strings that describe the type of channel content e.g. by "category", "tag" or "relation".

[00328] A mime types length field shall specify the length (in bytes) of the mime _types_text ( ) .

[00329] A mime types text() field shall give a comma-separated list of MIME types for content items in the offered channel.

[00330] A charging rules length field shall specify the length (in bytes) of the charging_rules_text().

[00331] A charging rules text() field shall give Information that at least defines who is responsible for the channel charging, charging method (based upon a subscription or a consumption).

[00332] A num purchase options field (8-bit) shall specify the number of purchase options in this NRT Content delivery channel descriptor.

[00333] A purchase_option_id_length field shall specify the length (in bytes) of the purchase_option_id_text ().

[00334] A purchase_option_id_text() field shall give an identifier of the purchase option, that will be used to identify the selected option.

[00335] A cost-information-flag is a 1-bit Boolean flag that shall indicate, when set to `1', that the cost information is present for this component.

[00336] A price_information_flag is a 1-bit Boolean flag that shall indicate, when set to `1', that the amount and currency is present for this component.

[00337] A cost-information-length field shall specify the length (in bytes) of the cost-information-text().

[00338] A cost-information-text () field shall give an identifier of the purchase option, that will be used to identify the selected option.

[00339] An amount is a 32-bit float, which shall specify the monetary value of the price for this purchase option.

[00340] A currency is a 16-bit unsigned integer, which shall specify the monetary currency codes.

[00341] The above described descriptor is included in a position of service-level-descriptor within NST or can be included in a position of content-level-descriptor within NCT.
A FDT Schema [00342] FIG. 19 is an exemplary diagram to explain a FDT
schema for mapping a file to content-id according to an embodiment of the present invention, and FIG. 20 is an exemplary diagram to explain a FDT schema for mapping a file to content id according to another embodiment of the present invention, which represents a FDT instant level entry file designating method.

[00343] In the following description, a FDT instance level refers to a level containing a portion, in which the common attribute is defined, if the common attribute of all files declared in the FDT needs to be defined. The FDT file level is used to indicate a level containing definition of the individual attribute of each of the files.

[00344] The receiver identifies whether transferred service via corresponding channel is an NRT service based upon the NST and NCT. Also, the receiver identifies content items and files of corresponding NRT service.

[00345] As mentioned in the foregoing description, the receiver may identify files and content items in the fixed NRT service. However, the receiver can not be matched the files to the content items because of not having information on mapping the files to the content items. Accordingly, the receiver can not process the received fixed NRT service.

[00346] Therefore, the present invention can provide a method for mapping the files to the content items. In this case, the receiver can properly process the received fixed NRT services. In this disclosure, the method may be specified based on the FDT information in the FLUTE session transmitting fixed NRT services. For instance, each file constructing the content items is identified based on content-location and TOI field specified in the FLUTE session.
Moreover, the TOI field or content-location field and content item is corresponded to be matched a content identifier in the FDT with the content id field in the NCT.

[00347] Referring to FIGs. 19 and 20, a part indicated by #1 declares content id at FDT-Instance level. In this case, the declared content id is given to all files declared within the corresponding FDT-Instance. Of course, by newly giving content id at a file level, it is able to overdrive this information. Alternatively, if a specific file belongs to another content item instead of a content item defined at the FDT-Instance level, this can be announced by giving a file level content id that will be explained in the following description. In the present embodiment, content_id is represented using 16 bits.

[00348] A part indicated by #2 declares content-id at a file level. If a file included within FDT Instance belongs to a different content item, it is signaled that each file belongs to a prescribed content item using this method.

[00349] A part indicated by #3 is a method for informing each file whether the corresponding file is an entry file. In particular, a file, which is played back in the first place, or a file corresponding to a root file, which should be executed first to access a content item, among several files constructing a content item is called an entry file. This part indicates a method of announcing this information. It is able to omit `entry' attribute. If it is omitted as `false', a basic value means that a corresponding file is not an entry file.

[00350] By signaling a presence or non-presence of an entry according to a group belonging at a file level, a specific file plays a role as an entry in a specific group but may fail to play the role in another group.

[00351] Regarding an embodiment of an entry file, if a content item is constructed as a web page, assume that index.htm and other several associated pictures and text files exist, the index.htm becomes the entry file.

[00352] As a method of announcing a presence or non-presence of an entry file in case of granting content identifier at FDT-instance level, the following two kinds of methods can be taken into consideration.

[00353] 1) Method of granting File-level content identifier to a file corresponding to an entry file in addition and setting its entry attribute to `true': In this case, it is disadvantageous in that content identifier is overlapped at FDT-Instance level and file level. Yet, this case can provide a most flexible structure.

[00354] 2) It is able to consider a method of directly referencing files playing a role as an entry file in the content identifier definition at FDT-instance level like another embodiment of the FDT scheme shown in FIG. 20. For this, in the embodiment shown in FIG. 20, FDT-Content-ID-Type is separately defined for FDT-instance level content identifier. This is extended to include a content location of an entry file as indicated by #2.

[00355] In case of this method, it may be disadvantageous in that a content location is repeatedly signaled. But, it becomes advantageous in that entry file configuring information can be directly obtained per content item.

An embodiment of overall operations of receiver [00356] FIG. 21 is a flowchart to explain a process for processing an NRT service in a receiver according to an embodiment of the present invention.

[00357] Referring to FIG. 21, a receiver reads an NCT for signaling an NRT service [S2101]. The receiver obtains information on a content item constructing the NRT service via the read NCT [S2102]. In this case, the information on a content item, for example, may be displayed an NRT guide information which is constructed based on the content id, the content delivery bit rate, the content-available-start-time, the content-available-end-time, the content title text() and so on.

[00358] A service guide is constructed based upon the obtained information on the content item constructing the NRT
service and is then displayed [S2103].

[00359] If at least one content is selected from the displayed service guide by a user or the like [S2104], content id for a corresponding content and service-id associated with the content-id are obtained from the NCT for the selected content [S21051.

[00360] The receiver reads an NST in the information for signaling the NRT service to receive the selected content [S2106] and then accesses a FLUTE session for carrying a file constructing the corresponding content item by finding service id that matches the service id obtained in the step S2104 [S2107].

[00361] The receiver reads a FDT in the corresponding FLUTE
session and then determined whether or not content identifier of the corresponding field is identical to the cotent_id in the acquired NCT.

[00362] If content identifier attribute for the corresponding file is matched with the content_id of the NCT, the receiver receives a corresponding file object and then stores the received file object [S2108].

[00363] In this case, the receiver can be aware of a file list belonging to each content-item by parsing FDT instances within a session. The receiver is also able to recognize which file in the file list plays a role as an entry. In particular, the receiver is able to know that each file belongs to a prescribed content item using the FDT instance.
The receiver is able to arrange a file list by a content item unit separately and then stores the arranged list, if necessary.

[00364] When a specific content item starts to be used by a selection made by a user or the like, content consumption is initiated using the content item configuration information obtained in the above process and the entry information included in the content item configuration information.

[00365] In this case, in constructing a service guide using the NOT, it is able to construct a service guide using both NCT and NST by parsing them together instead of parsing NCT
and NST in order. For instance, after descriptors for NST and associated NRT service have been parsed, application type and other requirement information are read by each NRT service unit. Moreover, application (service category) information on each service is displayed on an NRT service guide output screen and detailed information is displayed using other fields of NRT service info descriptor (displaying a size of a corresponding service using storage_requirement field, displaying audio and video codec information using audio_codec_type field and video_codec_type field, etc.) [00366] For instance, referring to Fig. 16, the NRT service may be provided by a PUSH method or through an NRT service dedicated channel according to an embodiment of the present invention. At this time, the receiver receives the content items within the received NRT service through the accessed FLUTE session and then stores. And, the receiver reproduces wanted content item within the stored content items based on the NCT. Herein, the wanted content item is selected by a user.

[00367] However, referring to Fig. 21, the receiver parses an NCT and then provides a service guide to a user based on the parsed NOT. And, if the user selects a specific content item, the receiver parses an NST. Then the receiver accesses an FLUTE session transmitting the NRT service including the selected content item. The receiver receives the NRT service including the selected content item and then stores the content item. Finally, the receiver can reproduce the stored content item.

[00368] In the above-mentioned, the method of Fig. 16 differs from the method of Fig. 21. The method of Fig. 16 can quickly reproduce the content item by pre-storing all content items in the NRT service. Also, the receiver can only store the wanted content item according to the method of Fig. 21.
Herein, the receiver can provide a service guide and then only receive the content item selected by the user.

[00369] It will be apparent to those skilled in the art that various modifications and variations can be made in the present invention without departing from the spirit or scope of the inventions. Thus, it is intended that the present invention covers the modifications and variations of this invention provided they come within the scope of the appended claims and their equivalents.

[Mode for Carrying Out the Present Invention]

As described above, the related details have been described in the best mode for carrying out the present invention.

[Industrial Applicability]

As described above, the present invention may be applied entirely or partially to a broadcasting system and a communication system.

Claims (15)

1. A method of providing a Non-Real-Time (NRT) service, the method comprising:

extracting identification information of first signaling information and second signaling information based upon a program specific information/program and system information protocol (PSI/PSIP) table;

receiving the first signaling information and the second signaling information based upon the extracted identification information;

constructing and displaying a service guide using the received first signaling information;

acquiring first content identification information of a content selected from the displayed service guide;

accessing a File Delivery over Unidirectional Transport (FLUTE) session using the received second signaling information;

acquiring second content identification information matched with the acquired first content identification information; and receiving and storing one or more files constructing a content based upon the acquired second content identification information.

2. The method of claim 1, wherein the identification information is extracted using at least one of a virtual channel table (VCT), a data service table (DST) and a program map table (PMT) in the PSI/PSIP table.

3. The method of claim 1, wherein the one or more file, the first signaling information and the second signaling information is received after a sequentially packetizing of an internet protocol (IP), an addressable section and an MPEG-2 transport stream.

4. The method of claim 1, wherein the first signaling information is an NRT content table (NCT) and the second signaling information is an NRT service table (NST).

5. The method of claim 1, wherein the second content identification information is extracted from a file description table (FDT) in the accessed FLUTE session.

6. The method of claim 1 further comprises constructing and displaying a service guide using the received first signaling information.

7. The method of claim 6 further comprises acquiring first service identification information in connection with the acquired first content identification information from the first signaling information associated with the selected content item in the displayed service guide.

8. The method of claim 7 further comprises extracting second service identification information matched with the acquired first service identification information from the received second signaling information.

9. A broadcasting receiver, comprising:

a baseband processor for extracting identification information of first signaling information and second signaling information using a program specific information/program and system information protocol (PSI/PSIP) table and receiving the first signaling information and the second signaling information based upon the extracted identification information;

a first handler for constructing and displaying a service guide using the received first signaling information;
a second handler for acquiring a first content identifier from the received first signaling information of a content selected from the displayed service guide;

a third handler for accessing a File Delivery over Unidirectional Transport (FLUTE) session using the received second signaling information and acquiring a second content identifier matched with the acquired first content identifier;

a controller for controlling to receive and store one or more files constructing a content item based upon the acquired second content identifier; and a storage unit for storing the received files.

10. The broadcasting receiver of claim 9, wherein the controller controls to extract identification information using at least one of a virtual channel table (VCT) , a data service table (DST) and a program map table (PMT) in the PSI/PSIP table.

11. The broadcasting receiver of claim 9, wherein the controller controls to receive the one or more file, the first signaling information and the second signaling information is received after a sequentially packetizing of an IP, an addressable section and an MPEG-2 transport stream.

12. The broadcasting receiver of claim 9, wherein the controller controls to receive the first signaling information and the second signaling information, and wherein the first signaling information is an NRT content table (NCT) and the second signaling information is an NRT service table (NST).

13. The broadcasting receiver of claim 9, wherein the controller controls to receive the second content identification information from the extracted a file description table (FDT) in the accessed FLUTE session.

14. The broadcasting receiver of claim 9, wherein the controller controls to acquire the first service identification information in connection with the acquired with the first content identification information from the first signaling information associated with a content item selected from the displayed service guide.

15. The broadcasting receiver of claim 9, wherein the controller controls to extract the second identification information matched with the acquired first service identification information from the received second signaling information.