WO2012099427A2 - 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치 - Google Patents

방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치 Download PDF

Info

Publication number
WO2012099427A2
WO2012099427A2 PCT/KR2012/000511 KR2012000511W WO2012099427A2 WO 2012099427 A2 WO2012099427 A2 WO 2012099427A2 KR 2012000511 W KR2012000511 W KR 2012000511W WO 2012099427 A2 WO2012099427 A2 WO 2012099427A2
Authority
WO
WIPO (PCT)
Prior art keywords
trigger
service
field
nrt
information
Prior art date
Application number
PCT/KR2012/000511
Other languages
English (en)
French (fr)
Other versions
WO2012099427A3 (ko
Inventor
이준휘
서종열
서동완
김관석
김상현
토마스고머
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to KR1020137018384A priority Critical patent/KR101690831B1/ko
Priority to CA2824965A priority patent/CA2824965C/en
Priority to US13/980,335 priority patent/US8978083B2/en
Publication of WO2012099427A2 publication Critical patent/WO2012099427A2/ko
Publication of WO2012099427A3 publication Critical patent/WO2012099427A3/ko
Priority to US14/604,070 priority patent/US9769518B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/28—Arrangements for simultaneous broadcast of plural pieces of information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/40—Arrangements for broadcast specially adapted for accumulation-type receivers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H60/00—Arrangements for broadcast applications with a direct linking to broadcast information or broadcast space-time; Broadcast-related systems
    • H04H60/35—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users
    • H04H60/38—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space
    • H04H60/40—Arrangements for identifying or recognising characteristics with a direct linkage to broadcast information or to broadcast space-time, e.g. for identifying broadcast stations or for identifying users for identifying broadcast time or space for identifying broadcast time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4345—Extraction or processing of SI, e.g. extracting service information from an MPEG stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/015—High-definition television systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/08—Systems for the simultaneous or sequential transmission of more than one television signal, e.g. additional information signals, the signals occupying wholly or partially the same frequency band, e.g. by time division

Definitions

  • the present invention relates to a broadcast service transmission method, a reception method thereof, and a reception device thereof.
  • Digital television is able to provide a variety of services in addition to video, audio, which is a unique feature of television (TV).
  • broadcast information Electronic Program Guide: EPG
  • EPG Electronic Program Guide
  • broadcast services received from two or more channels may be simultaneously provided.
  • the receiving system is equipped with a large-capacity storage device and is connected to the Internet or a data communication channel capable of bidirectional communication, there are many services that can be provided using broadcast signals.
  • services using broadcast signals are diversified as described above, the necessity of accurately driving services using broadcast signals increases.
  • An object of the present invention is to provide a method for receiving and processing a non-real-time service and a method for transmitting a non-real-time service.
  • the present invention also provides a method and an apparatus for interworking a content downloaded through a non-real-time service with a real-time broadcasting service.
  • Another object of the present invention is to provide a transmission method and a receiving apparatus for interworking a non-real time service and a real time broadcast service without affecting an existing receiver.
  • a broadcast receiving method of a broadcast receiving device comprises the steps of: receiving a first packetized stream; Extracting display time information from a header of the first packetized stream; Extracting trigger information including a target object identifier from the payload of the first packetized stream; Recognizing a type of the trigger information; If the trigger information corresponds to a ready trigger and the state of the object corresponding to the target object identifier is in a released state, preparing an object corresponding to the target object identifier and transitioning the state of the object to a ready state; If the trigger information corresponds to an execution trigger and the state of the object corresponding to the target object identifier is in the ready state, executing the object corresponding to the target object identifier to transition the state of the object to the active state; And if the trigger information corresponds to the stop trigger and the state of the object corresponding to the target object identifier is in the active state, stopping the object corresponding to the target object identifier to transition the state of the object to the stopped state.
  • Broadcast service receiving apparatus includes a receiving unit for receiving a first packetized stream; A trigger processor extracting display time information from a header of the first packetized stream and extracting trigger information including a target object identifier field and a trigger action field from a payload of the first packetized stream; And a service manager that immediately performs an action corresponding to the trigger action field with respect to an object corresponding to the target object identifier field if the display time information is not extracted from the header of the first packetized stream.
  • the broadcast service receiving apparatus comprises the steps of: receiving a first packetized stream; Extracting display time information from a header of the first packetized stream; Extracting trigger information including a target object identifier from the payload of the first packetized stream; Recognizing a type of the trigger information; Acquiring location information of a file belonging to the target object identifier when the trigger information is a preparation trigger; And when a current time reaches the display time information, downloading a file belonging to the target object identifier through the location information.
  • content downloaded through a non-real-time service may be associated with a real-time broadcast service.
  • the non-real-time service and the real-time broadcast service can be linked without affecting the existing receiver.
  • a broadcast service can be provided at an accurate timing.
  • 1 is a diagram illustrating a concept of providing an RT service and an NRT service.
  • FIG. 2 is a diagram illustrating a structure of an NRT service according to an embodiment of the present invention.
  • FIG. 3 illustrates a protocol stack for an NRT service configured according to an embodiment of the present invention.
  • FIG. 4 illustrates a protocol stack for an NRT service configured according to another embodiment of the present invention.
  • FIG. 5 illustrates a bitstream section of a TVCT table section (VCT) configured according to an embodiment of the present invention.
  • 6 and 7 illustrate examples of defining a value of a service_type field according to an embodiment of the present invention.
  • FIG. 8 illustrates a bitstream syntax of a DST table section (data_service_table_section) for identifying an application of an NRT service and data_service_table_bytes included in the DST section.
  • FIG. 9 is a reception system for receiving and servicing an NRT service using an ATSC A / 90 standard for delivering a data broadcast stream and an ATSC A / 92 standard for transmitting an IP multicast stream in a reception system according to the present invention. It is a figure for demonstrating a method.
  • FIG. 11 illustrates a method of signaling DSM-CC addressable section data using a VCT.
  • FIG. 14 illustrates a bit stream syntax of an NRT_component_descriptor (MH_component_descriptor) configured according to an embodiment of the present invention.
  • FIG. 15 illustrates a bit stream syntax of an NRT component descriptor to which NRT_component_data configured according to an embodiment of the present invention belongs.
  • FIG. 16 illustrates a bitstream syntax of an NRT-IT section for signaling an NRT application configured according to an embodiment of the present invention.
  • FIG. 17 illustrates an embodiment of a bit stream syntax structure for an NCT section (NRT_content_table_section) according to the present invention.
  • FIG. 18 shows an embodiment of a bit stream syntax structure of an SMT section that provides signaling information about NRT service data.
  • FIG. 19 illustrates an FDT schema for mapping a file and content_id according to an embodiment of the present invention
  • FIG. 20 illustrates an FDT schema for mapping a file and content_id according to another embodiment of the present invention. It is shown to.
  • FIG. 20 is a diagram for explaining an FDT schema for mapping a file and content_id according to another embodiment of the present invention.
  • 21 is a flowchart illustrating a method of operating a receiver according to an embodiment of the present invention.
  • 22 and 23 illustrate an embodiment different from an embodiment of a reception system capable of receiving, storing, and playing back NRT content for an NRT service.
  • 24 is a flowchart illustrating a method of receiving and providing an NRT service by a receiver according to an embodiment of the present invention.
  • 25 illustrates a bitstream syntax of a trigger configured according to an embodiment of the present invention.
  • FIG. 26 is a diagram illustrating a structure of a PES according to a synchronized data streaming method including a trigger according to an embodiment of the present invention.
  • FIG. 27 illustrates, in bitstream syntax, a synchronized data packet structure of a PES payload for transmitting a trigger, according to an embodiment of the present invention.
  • FIG. 28 illustrates an embodiment of a content type descriptor structure that may be included in tap () on a DST.
  • FIG. 29 illustrates an embodiment of a syntax of the PMT and a service identifier descriptor.
  • FIG. 30 illustrates a trigger stream descriptor according to an embodiment of the present invention.
  • FIG. 31 is a diagram illustrating an embodiment of an AIT table.
  • 32 is a diagram illustrating an embodiment of an STT table.
  • FIG. 33 is a block diagram schematically illustrating a transmitter for transmitting a TDO and a trigger according to an embodiment of the present invention.
  • 34 is a block diagram schematically illustrating a receiver 300 for receiving a TDO and a trigger according to an embodiment of the present invention.
  • 35 is a flowchart schematically illustrating a trigger transmission method according to an embodiment of the present invention.
  • 36 is a flowchart schematically illustrating an operation of the receiver 300 according to an embodiment of the present invention.
  • FIG. 37 is a flowchart illustrating a method of receiving using a trigger table in a trigger receiving method according to an embodiment of the present invention.
  • 38 is a flowchart illustrating an operation of the receiver 300 when transmitting trigger signaling information and a trigger using a DST according to an embodiment of the present invention.
  • 39 is a flowchart illustrating an operation of a receiver when a trigger is transmitted using a trigger stream descriptor according to an embodiment of the present invention.
  • FIG. 40 is a flowchart illustrating an operation of a receiver when a trigger is transmitted using a stream type according to an embodiment of the present invention.
  • 41 is a flowchart illustrating an operation of a receiver when transmitting a trigger using an AIT according to an embodiment of the present invention.
  • FIG. 42 is a flowchart illustrating an operation of a receiver when transmitting a trigger using STT according to an embodiment of the present invention.
  • 44 is a flowchart illustrating a method of transmitting activation trigger data according to an embodiment of the present invention.
  • 46 is a flowchart illustrating a maintenance trigger data transmission method according to an embodiment of the present invention.
  • 49 is a flowchart illustrating a preparation trigger receiving method according to an embodiment of the present invention.
  • 50 is a flowchart illustrating a preparation trigger receiving method according to another embodiment of the present invention.
  • 51 illustrates bitstream syntax of a trigger configured according to another embodiment of the present invention.
  • 53 shows the syntax of an internet location descriptor according to an embodiment of the present invention.
  • FIG. 54 is a flowchart illustrating a trigger transmission method according to another embodiment of the present invention.
  • 55 is a flowchart illustrating a method of operating a receiver according to an embodiment of the present invention.
  • 56 is a view illustrating a method of determining location information of a content item by a receiver according to an embodiment of the present invention.
  • 57 is a TDO state transition diagram illustrating how a receiver processes a trigger according to an embodiment of the present invention.
  • RT service used in the present invention means literally a real time service. In other words, it is a time-bound service.
  • non-real time (NRT) service means non-real-time services other than RT services.
  • non-real-time services are services that are not bound by time.
  • the data for the NRT service may be referred to as NRT service data.
  • the broadcast receiver according to the present invention may receive NRT service through a medium such as terrestrial, cable, or the Internet.
  • the NRT service may be stored in the storage medium of the broadcast receiver and then displayed on the display device according to a preset time or a user's request.
  • the NRT service is received in a file form and stored in a storage medium.
  • the storage medium is an internal HDD mounted in the broadcast receiver.
  • the storage medium may be a USB (Universal Serial Bus) memory or an external HDD connected to the outside of the broadcast receiving system.
  • NRT service signaling information In order to receive files constituting the NRT service, store them in a storage medium, and service the user, signaling information is required. In the present invention, this may be referred to as NRT service signaling information or NRT service signaling data.
  • the NRT service according to the present invention may be classified into a fixed NRT service and a mobile NRT service according to a method of obtaining an IP datagram including NRT service signaling data.
  • the fixed NRT service is provided to the fixed broadcast receiver
  • the Mobile NRT service is provided to the mobile broadcast receiver.
  • 1 illustrates a concept of providing an RT service and an NRT service.
  • the broadcasting station transmits the RT service according to the existing scheme, that is, like the current terrestrial broadcasting (or mobile broadcasting).
  • the broadcasting station may transmit the RT service and use the remaining bandwidth in the process or provide the NRT service using the dedicated bandwidth. That is, the RT service and the NRT service are transmitted through the same channel or different channels. Accordingly, NRT service signaling information (or NRT service signaling data) is required to distinguish RT service from NRT service in a broadcast receiver, store the divided NRT service, and provide the same to a user when necessary. NRT service signaling information (or NRT service signaling data) will be described in detail later.
  • a broadcast station may transmit broadcast service data in real time, and may transmit news clips, weather information, advertisements, Push VODs, and the like in non real time.
  • the NRT service may be news clips, weather information, advertisements, push VOD, as well as specific scenes of a live broadcast stream, detailed information of a specific program, and previews.
  • Conventional broadcast receivers can receive and process real-time services, but cannot receive and process non-real-time services. That is, the conventional broadcast receiver (ie, legacy device) is the principle that the operation is not affected by the NRT stream included in the channel for transmitting the real-time service. In other words, the conventional broadcast receiver cannot process the received NRT service because the conventional broadcast receiver is not provided with a means capable of properly processing the NRT service.
  • the broadcast receiver that is, the NRT device
  • the broadcast receiver can receive and properly process the NRT service combined with the RT service, it can provide a variety of functions to the viewer than the conventional broadcast receiver.
  • FIG. 2 is a diagram illustrating a structure of an NRT service according to an embodiment of the present invention.
  • One NRT service according to the present invention includes one or more content items (or content, or NRT content) as shown in FIG. 2, and one content item includes one or more files.
  • the file and the object may be used in the same sense.
  • the content item is the smallest unit that can be played independently.
  • the news may be an NRT service, and economic news, political news, and life news may each be content items. This can be called.
  • Each of the economic news, political news, and life news may be composed of one or more files.
  • the NRT service may be transmitted in the form of an MPEG-2 transport stream (TS) packet through the same broadcast channel or dedicated broadcast channel as the RT service.
  • TS transport stream
  • a unique PID may be allocated to the TS packet of the NRT service data and transmitted.
  • IP-based NRT service data is transmitted through MPEG-2 TS packetization.
  • NRT service signaling data necessary for receiving NRT service data is transmitted through an NRT service signaling channel.
  • the NRT service signaling channel is transmitted through a specific IP stream on the IP layer.
  • the specific IP stream may also be transmitted as an MPEG-2 TS packet.
  • the NRT service signaling data transmitted through the NRT service signaling channel includes an NRT service map table (SMT), an NRT service table (NST), an NRT content table (NCT), and an NRT information table (NRT).
  • NRT Information Table, NRT-IT provides access information of at least one NRT service or content item constituting the NRT service running in the IP layer.
  • the NRT-IT or NCT provides detailed information of content items or files constituting the NRT service.
  • NRT service signaling data which may include SMT (or NST) and NRT-IT (or NCT), may be included in a PSIP table on MPEG2 TS or through an NRT service signaling channel on an IP layer in a virtual channel. May be sent.
  • a plurality of NRT service data may be provided through one virtual channel.
  • the non-real-time information table NRT-IT includes information describing content that can be downloaded to be stored in the receiving device.
  • the information provided to the NRT-IT includes the title of the content (eg, the name of the program that can be downloaded), the time the content can be downloaded, and the content recommendation, availability of caption services, content identification, and other metadata. Information may be included as follows.
  • the text fragment table is a table for providing detailed description information about the content item or service.
  • the TFT includes a data structure that supports multiple languages, and thus can represent detailed descriptions (each string corresponding to one language) in several different languages.
  • the text fragment table is included in private sections having a table_id value (TBD) and may be distinguished by TFT_id.
  • TFT section is included in IP packets within the service signaling channel, which may be a channel assigned the multicast IP address 224.0.23.60 and port 4937 by the IANA.
  • the receiver may identify whether a corresponding service is an NRT service by referring to a service_category field in an SMT, for example.
  • the receiver may uniquely identify the NRT service through the NRT service identifier information (NRT_service_id) field from the SMT.
  • the NRT service may include a plurality of content items.
  • the receiver may identify each NRT content item through the content_id field in the NCT or NRT-IT.
  • the NRT content item and the NRT service may be connected by matching the NRT_channel_id field of the NCT with the aforementioned NRT_service_id field.
  • the NRT service is transmitted through a FLUTE session, and the receiver may extract FDT information from the FLUTE session.
  • the content_id in the extracted FDT information may be mapped to a content identifier (content_id) of NCT or OMA-BCAST SG to identify and receive NRT service content selected by a user.
  • the receiver identifies each file constituting the NRT content item using the TOI and Content-Location fields specified in the FDT within the FLUTE session, and the respective TOI or Content-
  • the location and content item may map the content_ID field in the FDT to the content identifier (content_id) field of the NCT or the content identifier (content_id) field of the OMA BCAST SG, and identify and receive NRT service content.
  • FIG. 3 illustrates a protocol stack for an NRT service configured according to an embodiment of the present invention.
  • the file-type NRT service is IP packetized in an IP layer and then transmitted in a MPEG-2 TS format through a specific virtual channel.
  • PSI Program Specific Information
  • PSIP Program and System Information Protocol
  • VCT virtual channel table
  • an NRT service signaling channel for transmitting NRT service signaling data for signaling access information of an IP-based NRT service is IP packetized to a specific IP stream in an IP layer and then transmitted in an MPEG-2 TS form. Shall be.
  • the broadcasting station packetizes NRT content items or files according to a file transfer protocol scheme as shown in FIG. 3, and converts the packetized NRT content items or files into ALC or Asynchronous Layered Coding or Layered Coding Transport. Packetize according to the method.
  • the packetized ALC or LCT data is again packetized according to the UDP scheme, and the packetized UDP data is again packetized according to the IP scheme to become IP data.
  • the IP data may include a file description table (FDT) including information on a file delivery over unidirectional transport (FLUTE) session.
  • FDT file description table
  • FLUTE unidirectional transport
  • the packetized IP data may be referred to as an IP datagram.
  • IP datagrams of an NRT service are encapsulated into an addressable section structure and packetized into an MPEG-2 TS format. That is, one addressable section structure has a form in which a section header and a CRC checksum are additionally added to one IP datagram.
  • the form of the addressable section structure may be a structure that conforms to the Digital Storage Media Command and Control (DSM-CC) section format for transmitting private data. Therefore, the addressable section may be referred to as a DSM-CC addressable section.
  • DSM-CC Digital Storage Media Command and Control
  • NRT service signaling data including at least one of SMT (or NST) and NRT-IT (or NCT) necessary to receive NRT content / files may be transmitted through an NRT service signaling channel on an IP layer.
  • NRT service signaling data may be packetized according to the IP scheme for transmission over the NRT service signaling channel on the IP layer.
  • the NRT service signaling channel is encapsulated in an IP datagram having a well-known IP address and multicasted.
  • NRT service signaling data may be included in PSI (Program Specific Information) or PSIP (Program and System Infromation Protocol) table section data and transmitted.
  • the PSI table may include, for example, a Program Map Table (PMT), a Program Association Table (PAT), and the like
  • the PSIP table may include, for example, a virtual channel table (VCT) and a terrestrial virtual channel (TVCT).
  • VCT virtual channel table
  • TVCT terrestrial virtual channel
  • CVCT Cable Virtual Channel Table
  • STT System Time Table
  • RTT Rating Region Table
  • RTT Rating Region Table
  • ETT Direct Channel Change Table
  • DCCSCT Direct Channel Change Selection Code Table
  • It may include an event information table (EIT) and a master guide table (MGT).
  • EIT event information table
  • MTT master guide table
  • PSI Program Specific Information
  • PSIP Program and System Information Protocol
  • DSM-CC addressable section data DSM-CC addressable section data
  • OMA BCAST DRM data are divided in units of 184 bytes, and then 4 bits are stored in each of 184 bytes.
  • MPEG-2 TS packet of 188 bytes can be produced.
  • the value allocated to the PID of the MPEG header may be the only value capable of identifying the TS packet for transmitting the NRT service and the NRT service signaling channel.
  • MPEG-2 TS packets may be modulated by a predetermined transmission scheme, for example, an 8-VSB transmission scheme, in a physical layer and transmitted to a receiving system.
  • a predetermined transmission scheme for example, an 8-VSB transmission scheme
  • FIG. 4 illustrates a protocol stack for an NRT service configured according to another embodiment of the present invention.
  • FIG. 4 shows an example of a protocol stack for providing a mobile NRT service.
  • FIG. 4 includes an adaptation layer between an IP layer and a physical layer so that an IP datagram of mobile service data and an IP datagram of signaling information can be transmitted without using the MPEG-2 TS format. .
  • the broadcast station packetizes the NRT content / files according to the file transfer protocol scheme in FIG. 4, and packetizes the NRT content / files according to the Asynchronous Layered Coding / Layered Coding Transport (ALC / LCT) scheme.
  • the packetized ALC / LCT data is again packetized according to the UDP scheme, and the packetized ALC / LCT / UDP data is again packetized according to the IP scheme to form ALC / LCT / UDP / IP data.
  • the packetized ALC / LCT / UDP / IP data is referred to as an IP datagram for convenience of description in the present invention.
  • the OMA BCAST SG information may configure an IP datagram through the same process as the NRT content / file.
  • NRT service signaling information (eg, SMT) required for receiving the NRT content / files is transmitted through a service signaling channel, which is packetized according to a user datagram protocol (UDP) scheme.
  • the packetized UDP data is again packetized according to the IP method to become UDP / IP data.
  • the UDP / IP data is also called an IP datagram for convenience of explanation.
  • the service signaling channel is encapsulated in an IP datagram having a well-known IP desiccation address and a well-known desiccation UDP port number and multicasted.
  • IP datagrams of the NRT service, NRT service signaling channel, and mobile service data are collected to generate an RS frame.
  • the RS frame may also include an IP datagram of OMA BCAST SG.
  • the length of the column (ie, the number of rows) in the RS frame is determined to be 187 bytes, the length of the row (ie, the number of columns) is N bytes, and N is signaling information such as a transmission parameter (or TPC data). It may vary.
  • the RS frame is modulated by a predetermined transmission scheme, for example, a VSB transmission scheme, in a mobile physical layer and transmitted to a receiving system.
  • a predetermined transmission scheme for example, a VSB transmission scheme
  • signaling whether or not to transmit an NRT service is performed through a PSI / PSIP table.
  • signaling of whether to transmit an NRT service to a virtual channel table (VCT) or a local virtual channel table (TVCT) according to an embodiment.
  • VCT virtual channel table
  • TVCT local virtual channel table
  • FIG. 5 illustrates a bitstream section of a TVCT table section (VCT) configured according to an embodiment of the present invention.
  • the TVCT table section has a table form of an MPEG-2 private section.
  • the TVCT table section is not limited thereto.
  • the packet identification information (PID) information regarding audio / video is transmitted through TVCT by parsing the VCT and PID of the audio / video, and the packet identification information (PID) information regarding audio / video can be known.
  • the TVCT table section can be divided into header, body and trailer, the header part is from the table_id field to the protocol_version field, and the transport_stream_id field is a 16-bit field, which is defined by a PID value of 0 for multiplexing. (MPEG-2 transport stream ID) in a program association table.
  • the num_channels_in_section field is an 8-bit field, and the body part details the number of virtual channels in the VCT section.
  • the trailer part contains a CRC_32 field.
  • the table_id field (8 bits) is set to 0xC8 to identify that the table section is a table section constituting TVCT.
  • a section_syntax_indicator field (1 bit) is set to 1, indicating that the section follows the general section syntax.
  • the private_indicator field (1 bit) is set to 1.
  • a section_length field (12 bits) specifies the number of bytes remaining in this section from immediately after the section_length field to the end of the section.
  • the value of the section_length field may not be greater than 1021.
  • the table_id_extension field (16 bits) is set to 0x000.
  • a version_number field (5 bits) may have a value of 0 and indicates a version number of the VCT.
  • a section_number field (8 bits) indicates the number of the corresponding table section among the TVCT sections. In the first section of TVCT, section_number must be set to 0x00.
  • the last_section_number field (8 bits) means the table section of the last and highest number among the TVCT sections.
  • protocol_version field (8 bits) is an allowable function of this table type that carries structured parameters differently than defined in the current protocol. Currently, only one valid value of protocol_version is zero. A non-protocol_version can be used in future versions of the standard to recognize structurally different tables.
  • a num_channels_in_section field (8 bits) specifies the number of virtual channels of the VCT section. The number is limited by the table section length.
  • a short_name field (16 bits) represents the name of the virtual channel as a code value of 1 to 7 consecutive 16 bit codes.
  • a major_channel_number field (10 bits) represents a major channel number associated with a virtual channel defined in repetition of a "for" loop. Each virtual channel must be associated with a major channel number and a minor channel number. Along with the minor channel number, the major channel number serves as a reference number of the user's virtual channel.
  • a minor_channel_number field (10 bits) represents a minor or sub-channel number in the range of '0' to '999'. Along with major_channel_number, the field is performed with a channel number of two parts in which minor_channel_number represents a second or right part of the number. minor_channel_number should be set to 0 when service_type is analog television. When service_type is ATSC_digital_television or ATSC_audio_only, use a minor number in the range of '1' to '99'. The value of minor_channel_number prevents major_channel_number and minor_channel_number from overlapping in TVCT.
  • a modulation_mode field (8 bits) indicates a modulation mode for a carrier associated with a virtual channel.
  • the carrier_frequnecy field (32 bits) has a recommended value of zero. Use of the field to identify carrier frequencies is allowed but preferably not.
  • a channel_TSID field (16 bits) is an unsigned integer field representing an MPEG-2 transport stream ID associated with a transport stream carrying an MPEG-2 program referred to by a virtual channel in the range of '0x0000' to '0xFFFF'.
  • a program_number field (16 bits) identifies an unsigned integer number associated with a virtual channel defined in MPEG-2 program association table (PAT) and TS program map table (PM PMT). For the virtual channel corresponding to the analog service, program_number is set to '0xFFFF'.
  • ETM_location field (2 bits) describes the presence and location of an extended text message (ETM).
  • Hidden virtual channels are omitted when the user is surfing the channel and appear undefined or when accessing the channel entry directly.
  • Typical applications for hidden channels are test signals and NVOD services.
  • Hidden channels and their events appear in the EPG display according to the state of the hide_guide bit.
  • the hidden_guide field is set to 0 for a hidden channel, the virtual channel and its events may appear in the EPG display. Since the bit is ignored for channels that do not have a hidden bit set, the hidden channels and their events are always included in the EPG display regardless of the state of the hide_guide bit.
  • Typical applications for hidden channels with the hidden_guide bit set set to '1' are test signals and services that are easy to obtain through application level pointers.
  • the service_type field (6 bits) indicates the type of service transmitted on the virtual channel.
  • 6 and 7 illustrate examples of defining a value of a service_type field according to an embodiment of the present invention.
  • the value '0x04' of the service_type shown in FIG. 6 means that the service_type is ATSC_data_only_service and that the NRT service can be transmitted through the virtual channel.
  • the value '0x08' of the service_type shown in FIG. 7 means that the service_type is ATSC_nrt_service and that the virtual channel provides NRT service conforming to the ATSC standard.
  • a source_id field (16 bits) indicates the source of the program associated with the virtual channel.
  • the descriptors_length field represents the total length (in bytes) of descriptors for the following virtual channels.
  • the descriptor () field contains zero or more descriptors.
  • the additional_descriptors_length field represents the total length (in bytes) of the following VCT descriptor list.
  • the trailer part is a 32-bit field that guarantees zero output from the registers of the decoder defined in the MPEG-2 system after processing the entire STT section. Contains a cyclic redundancy check (CRC) value.
  • CRC cyclic redundancy check
  • the broadcast station may transmit NRT service data or NRT service signaling data conforming to the ASTC standard through the DST table section shown in FIG. 8.
  • a table_id field (8 bits) is a field for identifying a type of a corresponding table section. Through this field, it can be seen that a corresponding table section is a table section constituting a DST. For example, if the value of this field has 0XCF, the receiver may identify that the corresponding table section is a table section constituting the DST.
  • a section_syntax_indicator field (1 bit) is an indicator defining a section format of a DST.
  • the section format may be, for example, a short-form syntax (0) of MPEG.
  • the private_indicator field (1 bit) indicates whether the shape of the corresponding section follows the private section type and may be set to '1'.
  • a private_section_length field (12 bits) represents the length of the remaining table section after this field. Also, the value of this field does not exceed '0xFFD'.
  • the table_id_extension field (16 bits) is dependent on the table and may be a logical part of the table_id field providing a range of remaining fields.
  • a version_number field (5 bits) indicates the version number of the DST.
  • a current_next_indicator field (1 bit) indicates whether a transmitted DST table section is currently applicable. If this field value is 0, it means that the table does not exist yet and is valid for the next table.
  • a section_number field (8 bits) indicates a section number in sections in which a corresponding table section composes a DST table.
  • the section_number of the first section of the DST is set to '0x00'.
  • section_number is incremented by one each time the section of the DST is increased.
  • the last_section_number field (8 bits) indicates the last section number constituting the DST table. (Highest section_number)
  • data_service_table_bytes represents a data block constituting the DST, and a detailed structure thereof will be described later.
  • the CRC_32 field is a 32-bit field. Cyclic redundancy check that guarantees zero output from the registers of the decoder defined in the MPEG-2 system after processing the entire DST section. ) Value.
  • semantics of fields including the data_service_table_bytes structure described above is defined as follows.
  • the sdf_protocol_version field (8 bits) describes the version of the Service Description Framework protocol.
  • the application_count_in_section field (8 bits) describes the number of applications listed in the DST section.
  • the compatibility_descriptor () field indicates that the structure includes a DSM-CC compatibility descriptor.
  • the purpose is to signal the compatibility requirements of the application in the receiving platform to determine its ability to use that data service.
  • An app_id_byte_length field (16 bits) describes the number of bytes used to identify an application.
  • the app_id_description field (16 bits) may describe the format and semantics of the following application identification bytes.
  • the value of the app_id_description field may be defined as shown in Table 1 below.
  • the app_id_byte field (8 bits) represents a byte of an application identifier.
  • a tap_count field (8 bits) describes the number of Tap () structures used by the corresponding application.
  • the protocol_encapsulation field (8 bits) describes the type of protocol encapsulation used to transmit the specific data element referenced by the Tap () field.
  • the value of the protocol_encapsulation field may be defined and used as shown in Table 2 below.
  • the action_type field (7 bits) may indicate an attribute of data referred to by the Tap () field.
  • a resource_location field (1 bit) describes the location of the association_tag field that matches the association_tag value listed in the next Tap structure. If this field is set to '0', the matching association_tag exists in the PMT of the current MPEG-2 program. Unlike this, if it is set to '1', the matching association_tag exists in the DSM-CC Resource Descriptor in the Network Resources Table of the corresponding data service.
  • the Tap () field may include information for finding a data element of an application step included in a communication channel of a lower layer.
  • the association_tag field in the Tap () field may include correspondence information between data elements of an application step.
  • the value of the association_tag field in one Tap structure corresponds to the value of the association_tag field of one association tag descriptor included in the current PMT.
  • the Tap () field may include a specific structure including fields as shown in Table 3 below.
  • the tap_id field (16 bits) is used by the application to identify data elements.
  • the value of tap_id is ranged by the value of app_id_byte fields related to Tap () in DST.
  • the tap_id value is selected by the data service provider.
  • the tap_id value may be used in an application for handling data elements.
  • the Use field (16 bits) is used to specify the communication channel referenced by the association_tag.
  • the association_tag field (16 bits) uniquely identifies either the DSM-CC resource descriptor listed in the Network Resource Table or the data elementary stream listed in the PMT. The value of this field may match the association_tag value of the association_tag_descriptor in the PMT of the data service.
  • the Selector () field describes the specific data element available in the communication channel or data elementary stream referenced by the association_tag field.
  • the selector structure may indicate the protocol required for that data element.
  • a tap_info_length field (16 bits) may describe the number of bytes of descriptors of a field next to the field.
  • the descriptor () field may include descriptor information according to a corresponding descriptor format.
  • An app_info_length field (8 bits) describes the number of bytes of descriptors following the field.
  • the descriptor () field may include descriptor information according to a corresponding descriptor format.
  • An app_data_length field (16 bits) describes the length in bytes of the app_data_byte fields.
  • app_data_byte (8 bits) represents input parameters related to the application and other private data fields in one byte.
  • a service_info_length field (8 bits) describes the number of byte units of the following descriptors.
  • the descriptor () field may include descriptor information according to a corresponding descriptor format.
  • the service_private_data_length field (16 bits) describes the length in bytes of the private fields.
  • the service_private_data_byte field (8 bits) represents a private field in 1 byte.
  • FIG. 9 is a reception system for receiving and servicing an NRT service using an ATSC A / 90 standard for delivering a data broadcast stream and an ATSC A / 92 standard for transmitting an IP multicast stream in a reception system according to the present invention. The method is explained.
  • information on the streams constituting each virtual channel is signaled to the service location descriptor of the VCT or the ES_loop of the PMT.
  • the service type of the VCT is 0x02 (i.e., digital A / V / Data) or 0x04 (i.e., data only), as in FIG. 7 or 8, or 0x08 (i.e., NRT Only). service
  • an NRT service stream may be transmitted through the virtual channel.
  • 0x95 that is, DST transmission
  • the DST is used to identify an NRT application (ie, an NRT service).
  • the App_id_descrption field of the DST defines the format and interpretation of subsequent application identification bytes.
  • '0x0003' is allocated to the App_id_descrption field to identify an NRT application.
  • the next Application_id_byte value becomes a Service ID value of the NRT application.
  • the service ID for the NRT application may have a URI value uniquely identifying the corresponding service worldwide.
  • the PID of the MPEG-2 TS packet divided from the IP datagram of the NRT service signaling channel is found through the tap information. Then, an IP datagram transmitting an NRT service signaling channel can be obtained from MPEG-2 TS packets having PIDs found through the tap information, and NRT service signaling data can be obtained from the obtained IP datagram. .
  • the IP access information of the NRT service signaling channel well-known IP access information, that is, a well-known IP address and a well-known UDP port number may be used.
  • the receiver accesses the IP multicast address (or address range) to receive an IP stream, that is, an IP packet, and extracts NRT service signaling data from the received IP packet.
  • the receiver may receive NRT service data, that is, NRT content items / files, store them in a storage medium or display them on a display device based on the extracted NRT service signaling data.
  • NRT service data that is, NRT content items / files
  • the NRT service may be signaled using a new value, for example, 0x96, instead of 0x95 in the Stream Type field value of the DST.
  • a new value for example, 0x96
  • the existing receiver may ignore it and guarantee backward compatibility.
  • the data transmission scheme using DST is a standard for transmitting all types of IP datagrams through a digital broadcast stream, and may be inefficient for NRT service. Accordingly, in FIG. 10 and FIG. 11, as an embodiment, an NRT service is performed by signaling a PID of a specific stream including IP address information and section data of an IP datagram for an NRT service through data of a DSM-CC addressable section. A method of receiving is shown.
  • the receiver may obtain information that an NRT service stream may be transmitted through the virtual channel. That is, the receiver may map the PID of the virtual channel and the channel number to obtain information on whether the NRT service exists according to the service_type information.
  • the receiver may receive a DSM-CC addressable section including NRT service data through Elementary_PID.
  • the receiver may acquire the PID of the DSM-CC addressable section through the VCT or the PMT.
  • the receiver may obtain an NRT_IP_address_list_descriptor_A () field including an IP address of an NRT service signaling channel corresponding to a PID obtained from a PMT of a corresponding stream or an IP address of a FLUTE session for transmitting NRT service data.
  • the receiver may receive the DSM-CC addressable section data from the IP multicast stream or the IP subnet based on the IP address obtained from the NRT_IP_address_list_descriptor_A () field.
  • the receiver finds the DSM-CC addressable section in which the PID corresponding to the obtained elementray_PID exists in the received DSM-CC addressable section data, thereby searching for specific NRT service (eg, A, B, or C) data.
  • the corresponding IP datagram may be obtained.
  • FIG. 11 illustrates a method of signaling DSM-CC addressable section data using a VCT.
  • the receiver may obtain information that the NRT service stream can be transmitted when the service type (service_type) specified in the VCT is 0X02, 0X04, or 0X08.
  • the receiver may obtain an elementary_PID having a stream type of 0X0D from the service_location_descriptor () field in order to receive the DSM-CC stream.
  • the receiver may obtain an NRT_IP_address_list_descriptor_B () field including the IP address of the NRT service signaling channel corresponding to the obtained elementray_PID or the IP address of the FLUTE session for transmitting the NRT service data from the VCT.
  • the receiver may receive the DSM-CC addressable section data from the IP multicast stream or the IP subnet based on the IP address obtained from the NRT_IP_address_list_descriptor_B () field.
  • the receiver parses the DSM-CC addressable section in which the PID corresponding to the obtained elementray_PID exists from the received DSM-CC addressable section data, thereby receiving a specific NRT service (eg, A, B, or C) obtain an IP datagram including the data.
  • a specific NRT service eg, A, B, or C
  • 0x08 is allocated to the service_type field value in the VCT to indicate that one or more NRT services are transmitted to the corresponding virtual channel.
  • the PSI / PSIP section handler obtains the VCT and PMT from the broadcast signal received on the selected channel.
  • the PSI / PSIP section handler parses the obtained VCT to check whether there is an NRT service. This can be known by checking the value of the service_type field in the virtual channel loop of the VCT. For example, if the service_type field value is not 0x08, the corresponding virtual channel does not transmit the NRT service. In this case, since the virtual channel transmits an existing service (that is, legacy ATSC service), the receiver performs an appropriate operation according to the information included in the virtual channel.
  • the demultiplexer transmits an NRT service.
  • the service location descriptor in the virtual channel loop of the VCT is parsed to extract the PID of the DST.
  • the DST is received using the extracted PID.
  • the receiver checks whether the corresponding service provided through the channel selected from the received DST is an NRT service.
  • the NRT service can be confirmed from the value of the App_id_descrption field.
  • '0x0003' is allocated to the App_id_descrption field to identify an NRT application (ie, an NRT service).
  • NRT application ie, an NRT service.
  • the next Application_ id_byte value becomes a Service ID value of an NRT application (ie, an NRT service). Therefore, after identifying the NRT application (i.e., NRT service) as described above, the service manager or the PSI / PSIP section handler performs a tap to find the PID of the MPEG-2 TS packet divided from the IP datagram of the NRT service signaling channel. Extract. Then, the stream PID including the association_tag of the extracted Tap is extracted from the PMT.
  • the addressable section handler may receive the MPEG-2 TS packets corresponding to the extracted stream PID to decapsulate, ie, remove the MPEG-2 header, and restore the DSM-CC addressable section.
  • the receiver removes the section header and the CRC checksum from the DSM-CC addressable section to recover an IP datagram transmitting an NRT service signaling channel and obtains NRT service signaling data from the recovered IP datagram.
  • the access information of the IP datagram transmitting the NRT service signaling channel is a well-known destination IP address and a well-known destination UDP port number.
  • the receiver accesses the IP multicast address (or address range) to receive an IP stream, that is, an IP packet, and extracts NRT service signaling data from the received IP packet.
  • the receiver may receive NRT service data, that is, NRT content items / files, store them in a storage medium or display them on a display device based on the extracted NRT service signaling data.
  • NRT service data that is, NRT content items / files
  • the above-described NRT service may be provided through a DCD (Dynamic Content Delivery) service.
  • the DCD service is a service that periodically transmits the content to the receiver or when the user desires, and the content at this time is selected by the server according to the information of the receiver.
  • the DCD service supports a point-to-point method and a broadcast method for communication means for content delivery, and the present invention provides the above-described NRT service for OMA BCAST, which is one of the broadcast methods of the DCD service. In one embodiment, the transmission method is performed.
  • the NRT service data can be transmitted through the OMA BCAST-type DCD service.
  • the receiver may acquire DCD channel information for receiving the NRT service, and receive the NRT service through the corresponding DCD channel based on the DCD channel information.
  • the DCD channel information may be included in the above-described NST and transmitted.
  • the receiver may receive the NST and perform DCD bootstrap to obtain DCD channel information.
  • the above-described NST may include DCD channel metadata that can be received through a DCD administrator channel for signaling DCD channel information. Accordingly, the receiver may acquire information and metadata about a channel capable of receiving the NRT service through the NST.
  • the NST includes metadata of a channel capable of receiving an NRT service, there are some advantages.
  • a service access speed may be increased by receiving channel metadata capable of directly receiving an NRT service in the NST without receiving NRT service signaling data based on the service type of the above-described virtual channel.
  • update signaling for channel changes may be performed in real time in a broadcast environment.
  • the access information included in the OMA BCAST SG can be obtained by referring to the NST.
  • the receiver receives the DCD channel metadata based on the DCD channel information included in the NST, and obtains connection information for receiving the NRT service based on the NRT service signaling data and the DCD channel metadata acquired in the NST. can do.
  • the NST may include a list of NRT services linked to other virtual channels and transmit the same. Therefore, in this case, the list information of the NRT service may be transmitted through a specific NRT service signaling channel through the IP layer rather than the PSI or PSIP layer. Thus, in this case backward compatibility with PSI or PSIP can be preserved.
  • the DCD channel information including the DCD channel metadata may be included in the access information of the SG of the OMA BCAST, and the access information may correspond to the NRT service information included in the NST. More specifically, the receiver may obtain NRT service information included in the NST from an access fragment of the OMA BCAST SG. Accordingly, the receiver may obtain information for receiving the NRT service by receiving the NST corresponding to the obtained NRT service information.
  • the NRT service transmitted through the DCD channel can be classified by separately assigning a service category.
  • the service category of the NRT service transmitted through the DCD channel may be identified as 0X0F.
  • the syntax is written in the form of MPEG-2 private section for the sake of understanding, but the format of the data may be in any form.
  • other methods such as signaling in the form of a Session Description Protocol (SDP) and signaling through a Session Announcement Protocol (SAP) may be used.
  • SDP Session Description Protocol
  • SAP Session Announcement Protocol
  • NST describes service information and IP access information in a virtual channel through which NST is transmitted, and NRT broadcast stream information of a corresponding service using NRT_service_id, which is an identifier of an NRT broadcast stream to which each service belongs. Also provide.
  • the NST according to the present embodiment includes description information of each fixed NRT service in one virtual channel, and other additional information may be included in a descriptor area.
  • a table_id field (8 bits) is a field for identifying the type of a corresponding table section. Through this field, it is understood that the corresponding table section is a table section constituting the NST.
  • a section_syntax_indicator field (1 bit) is an indicator defining a section format of an NST.
  • the section format may be, for example, a short-form syntax (0) of MPEG.
  • the private_indicator field (1 bit) indicates whether or not the type of the section follows the private section type and is set to '1'.
  • a section_length field (12 bits) indicates the length of the remaining table section after this field. Also, the value of this field does not exceed '0xFFD'.
  • the table_id_extension field (16 bits) is dependent on the table and becomes a logical part of the table_id field that provides the range of remaining fields.
  • the table_id_extension field includes an NST_protocol_version field.
  • An NST_protocol_version field (8 bits) indicates a protocol version for indicating the NST to which parameters having a structure different from those defined in the current protocol are transmitted. Currently, this field value is zero. If a field value is later specified as a nonzero value, it is for a table with a different structure.
  • a version_number field (5 bits) represents the version number of the NST.
  • a current_next_indicator field (1 bit) indicates whether a transmitted NST table section is currently applicable. If this field value is 0, it means that the table does not exist yet and is valid for the next table.
  • a section_number field (8 bits) indicates the section number in the sections in which the corresponding table section composes the NST table.
  • section_number of the first section of the NRT Service Table (NST) is set to '0x00'. section_number is incremented by one each time the section of the NRT service table is increased.
  • the last_section_number field (8 bits) indicates the last section number constituting the NST table. (Highest section_number)
  • a carrier_frequency field (32 bits) indicates a transmission frequency corresponding to the channel.
  • a channel_TSID field (16 bits) means a unique channel identifier of a broadcast stream in which a corresponding NST section is transmitted.
  • a program_number field (16 bits) indicates a program number associated with a virtual channel.
  • a source_id field (16 bits) indicates the source of the program associated with the virtual channel.
  • a num_NRT_services field (8 bits) indicates the number of NRT services in the NST section.
  • the NST according to the present embodiment provides information about a plurality of fixed NRT services using a for loop.
  • the same field information may be provided for each fixed NRT service.
  • An NRT_service_status field (2 bits) identifies the status of the mobile service.
  • the MSB indicates whether the corresponding mobile service is active (1) or inactive (0)
  • the LSB indicates whether the corresponding mobile service is hidden (1) or not (0).
  • Hidden services are mainly used for proprietary applications, and ordinary receivers ignore them.
  • the SP_indicator field (1 bit) is a field for indicating a service protection applied to at least one of components required to provide a meaningful presentation of a corresponding mobile service.
  • a CP_indicator field (1 bit) indicates whether content protection of a corresponding NRT service is performed. If the CP_indicator field value is 1, it may mean that content protection is applied to at least one of the components required to provide a meaningful presentation of the corresponding NRT service.
  • NRT_service_id field (16 bits) is an indicator uniquely identifying the corresponding NRT service within the range of the corresponding NRT broadcast.
  • the NRT_service_id does not change throughout the service.
  • the NRT_service_id for the service may not be used for another service until an appropriate time elapses.
  • a Short_NRT_service_name field (8 * 8 bits) indicates a short name of the NRT service. If there is no short name of the NRT service, the field may be filled with a null value (eg, 0x00).
  • An NRT_service_category field (6 bits) identifies the type of service transmitted in the corresponding NRT service.
  • a num_components field (5 bits) indicates the number of IP stream components included in the NRT service.
  • the IP_version_flag field (1 bit) indicates that the source_IP_address field, the NRT_service_destination_IP_address field, and the component_destination_IP_address field are IPv4 addresses when set to '0', and the source_IP_address field, NRT_service_destination_IP_address field, and component_destination_IP_address field when the value is set to '1'. .
  • a source_IP_address_flag field (1 bit) indicates that when a flag is set, a source IP address value for a corresponding NRT service exists to indicate source specific multicast.
  • the NRT_service_destination_IP_address_flag field (1 bit) indicates that there is an NRT_service_destination_IP_address field for providing a default IP address for components of the corresponding NRT service.
  • a source_IP_address field (128 bits) has a corresponding field when source_IP_address_flag is set to 1, but a corresponding field will not exist when source_IP_address_flag is set to 0. If this field is present, this field will contain the source IP address of all IP datagrams carrying components of the NRT service. The limited use of the 128-bit long address in this field is intended to enable future use of IPv6, although the use of IPv6 is currently undefined. Source_IP_address becomes a source IP address of the same server transmitting all channels of the FLUTE session.
  • the NRT_service_destination_IP_address field (128 bits) has a corresponding source_IP_address field when source_IP_address_flag is set to 1, but a corresponding source_IP_address field will not exist when source_IP_address_flag is set to 0. If the corresponding source_IP_address field does not exist, the component_destination_IP_address field will exist for each component in the num_components loop. The limited use of the 128-bit long address in the corresponding source_IP_address field is intended to enable the use of IPv6 in the future, although the use of IPv6 is not defined at present. NRT_service_destination_IP_Address is signaled if there is a destination IP address of the session level of this FLUTE session.
  • the NST provides information about a plurality of components using a for loop.
  • the essential_component_indicator field (1 bit) indicates that the corresponding component is an essential component for the NRT service when the value of the corresponding field is set to 1. Otherwise, it indicates that the component is an optional component.
  • a port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component. The value of the destination UDP port numbers is increased by one starting from the component_destination_UDP_port_num field value.
  • a component_destination_IP_address_flag field (1 bit) is a flag indicating that a component_destination_IP_address field exists for a corresponding component when it is set to 1.
  • a component_destination_IP_address field (128 bits) has a corresponding field when component_destination_IP_address_flag is set to 1, but a corresponding field will not exist when component_destination_IP_address_flag is set to 0. If this field is present, this field will contain the source IP address of all IP datagrams carrying components of the NRT service. The limited use of the 128-bit long address in this field is intended to enable future use of IPv6, although the use of IPv6 is currently undefined.
  • a component_destination_UDP_port_num field (16 bits) indicates a destination UDP port number for the corresponding UDP / IP stream component.
  • a num_component_level_descriptors field (4 bits) provides the number of descriptors that provide additional information for the corresponding IP stream component.
  • the component_level_descriptors field identifies one or more descriptors that provide additional information for the corresponding IP stream component.
  • a num_NRT_service_level_descriptors field (4 bits) indicates the number of NRT service level descriptors for a corresponding service.
  • NRT_service_level_descriptor identifies one or more descriptors that provide no additional information for the NRT service.
  • the specific service type for the NRT service may be informed.
  • the specific service type may include, for example, a portal service that provides web content, a push VOD, and an A / V download.
  • a num_virtual_channel_level_descriptors field (4 bits) describes the number of virtual channel level descriptors for the corresponding virtual channel.
  • virtual_channel_level_descriptor () represents a descriptor that provides additional information about the virtual channel described by the corresponding NST.
  • the NRT service is transmitted through FLUTE, and access information on the NST table is connected with FLUTE session information as follows.
  • Source_IP_address is a source IP address of the same server that transmits all channels of the FLUTE session.
  • NRT_service_destination_IP_Address is signaled when there is a destination IP address of the session level of this FLUTE session.
  • the component may be mapped to a channel in the FLUTE session and may signal a separate destination IP address for each channel (different from the IP address signaled in the session unit) through the component_destination_IP_address.
  • the destination port number may be signaled through component_destination_UDP_port_num and the number of destination ports starting from component_destination_UDP_port_num may be additionally specified through port_num_count.
  • a plurality of channels may be configured for one destination IP address.
  • one component may designate a plurality of channels. In general, however, it is desirable to distinguish channels by their destination IP addresses. Here, it can be seen that one channel is mapped to one component.
  • Content items / files for the NRT service are transmitted through FLUTE and signal corresponding FLUTE session information using the access information on the NST table.
  • FIG. 14 illustrates a bit stream syntax of an NRT_component_descriptor (MH_component_descriptor) configured according to an embodiment of the present invention.
  • NRT_component_descriptor () will appear in the component descriptor loop of each component of each NRT service in the NST. And all the parameters in the descriptor correspond to the parameters used for the components of the NRT service.
  • a component_type field (7 bits) identifies an encoding format of a component.
  • the identification value may be one of values assigned for payload_type of the RTP / AVP stream.
  • the identification value may also be a dynamic value in the range of 96 to 127.
  • the values of this field correspond to the values in payload_type in the RTP header of the IP stream transmitting the corresponding components for the components constituting the media transmitted through the RTP.
  • component_type field in the range of 43 to 71 are defined in future versions of the standard.
  • the component_type 38 defined for the FLUTE component may be used by ATSC to further signal the parameters described below for the FLUTE session, and a new NRT value of 43, which is not yet assigned, may be used. Can also be defined and used as component_type for transmission.
  • a num_STKM_streams field (8 bits) identifies the number of STKM streams associated with that component.
  • the STKM_stream_id field (8 bits) identifies the STKM stream with the keys to decrypt the corresponding protected component obtained.
  • the STKM_stream_id field is referred to in the component descriptor for the STKM stream.
  • the NRT_component_data (component_type) field provides at least one of encoding parameters and other parameters necessary for representing the corresponding component.
  • the structure of the NRT_component_data element is determined by the value of the component_type field.
  • the File Delivery Table (FDT) of FLUTE sessions is used to deliver item lists of all content items and provide the size, data type and other information of the items related to obtaining the items.
  • the present invention obtains information for accessing a FLUTE session for transmitting the corresponding content using the NST to receive the selected content from the SG configured using the NRT-IT.
  • the present invention maps the information on the file transmitted through the FLUTE session with the information of the content item of the NRT-IT. In this case, identification of the service including the selected content item is resolved through the NRT_service_id of the NST.
  • the NRT service is transmitted through FLUTE, and access information on the NST table is connected with FLUTE session information as follows.
  • Source_IP_address becomes the source IP address of the same server that transmits all channels of the FLUTE session.
  • NRT_service_destination_IP_Address is signaled when there is a destination IP address of the session level of this FLUTE session.
  • a component may be mapped to a channel in a FLUTE session and may signal a separate destination IP address (different from the IP address signaled on a session basis) through each component_destination_IP_address.
  • the destination port number may be signaled through component_destination_UDP_port_num and the number of destination ports starting from component_destination_UDP_port_num may be additionally specified through port_num_count.
  • a plurality of channels may be configured for one destination IP address.
  • one component may designate a plurality of channels. However, in general, it is recommended to distinguish the channel by the destination IP address. In this case, one channel is mapped to one component.
  • Component_attribute_byte may be used to signal an additional attribute of a component configuring a session. Additional parameters necessary for signaling a FLUTE session may be signaled through this.
  • parameters are required to signal a FLUTE session, and these parameters include mandatory parameters that are absolutely necessary and parameters that are optionally necessary in connection with the FLUTE session.
  • the mandatory parameters include the source IP address, the number of channels in the session, the destination IP address and port number for each channel in the session. for each channel in the session, the Transport Session Identifier (TSI) of the session, and the start time and end time of the session parameters.
  • TTI Transport Session Identifier
  • Optional parameters related to this may include FEC Object Transmission Information, Some information that tells receiver in the firstplace, that the session contains files that are of interest and Bandwidth specification parameters are included.
  • the number of channels of the session may be explicitly provided, or may be obtained by summing the number of streams constituting the session.
  • the start time and end time of the session the source IP address, the destination IP address and port number of each channel in the session through the NST and component_descriptor.
  • the parameters of the address and port number for each channel in the session, the Transport Session Identifier (TSI) of the session, and the number of channels in the session may be signaled.
  • TTI Transport Session Identifier
  • FIG. 15 illustrates a bit stream syntax of an NRT component descriptor to which NRT_component_data configured according to an embodiment of the present invention belongs.
  • One NRT service may be included in multiple FLUTE sessions. Each session may be signaled using one or more NRT component descriptors depending on the IP addresses and ports used for the session.
  • the TSI field (16 bits) indicates the TSI of the FLUTE session.
  • the session_start_time field indicates the time at which the FLUTE session starts. If the value of this field is all 0, the session can be interpreted as already started.
  • the session_end_time field indicates the time when the FLUTE session ends. If the values of all of the fields are 0, the session may be interpreted as continuing indefinitely.
  • a tias_bandwidth_indicator field (1 bit) indicates flags including transport independent application specific (TIAS) bandwidth information. If the TIAS bandwidth field is indicated as present, the corresponding bit must be set to 1, and if the TIAS bandwidth field is indicated as not present, the corresponding bit must be set to 0.
  • TIAS transport independent application specific
  • the as_bandwidth_indicator field (1 bit) is flags including application specific (AS) bandwidth information. If the AS bandwidth field is present, the corresponding bit must be set to 1. To indicate that the AS bandwidth field is not present, the corresponding bit must be set to 0.
  • AS application specific
  • An FEC_OTI_indicator field (1 bit) indicates whether FEC object transmission information (OTI) information is provided.
  • the tias_bandwidth field represents TIAS maximum bandwidth.
  • the as_bandwidth field has a value of AS maximum bandwidth.
  • the FEC_encoding_id field represents an FEC encoding ID used in the corresponding FLUTE session.
  • the FEC_instance_id field represents an FEC instance ID used in a corresponding FLUTE session.
  • This FLUTE component descriptor may be delivered through a Component_level_descriptor loop of NST.
  • TSI, session_start_time, session_end_Time, etc. which are session level parameters, should be signaled only once, so that only one component of the components of multiple channels may transmit the FLUTE component descriptor through the Component_level_descriptor loop.
  • FIG. 16 illustrates a bitstream syntax of an NRT-IT section for signaling an NRT application configured according to an embodiment of the present invention.
  • the information provided by the NRT-IT may include the title of the content (eg the name of the downloadable program), the downloadable time and information such as content advisories, the availability of caption services, content identification and other meta.
  • Contains data One item of content may consist of one or more files. For example, audio / video clips can be played back as JPEG thumbnail images that can be used for screen display.
  • An instance of an NRT-IT may contain data corresponding to a randomly defined period of time or may describe NRT content starting at a specified time and ending in an indefinite future.
  • Each NRT-IT represents a start time and a duration that can be indefinite.
  • Each NRT-IT instance can be divided into up to 256 sections. Each section contains information of multiple content items, but the information of a particular content item cannot be divided and stored in two or more sections.
  • NRT_information_table_section () in availability order.
  • last_section_number is greater than 0 (meaning that the NRT-IT has been sent to multiple sections)
  • all content item descriptions in a particular section other than the first section will be matched with the first availability of the content item description in the next section. Will have the same or higher initial availability.
  • Each NRT-IT identifies an NRT service associated with a particular value of service_id that is valid for a particular virtual channel for that period.
  • the table_id field (8 bits) is set to 0xTBD to identify that the table section is a table section constituting the NRT-IT.
  • a service_id field (16 bits) describes a service_id field associated with an NRT service showing a content item described in the section.
  • the NRT_IT_version_number field (5 bits) is defined as a set in one or more NRT_content_table_section () with common values for the service_id, current_next_indicator, protocol_version, and time_span_start fields. Identifies the version number of the NRT-IT instance. The version number is increased by 1 modulo 32 when the field of the NRT-IT instance changes.
  • protocol_version field (8 bits) is set to zero.
  • the function of protocol_version allows table types with parameters that may be structurally different from those defined in the current protocol in the future. Currently the only valid value for protocol_version is 0. A nonzero value in protocol_version is used in future versions of the standard to recognize structurally different tables.
  • time_span_start field (32 bits) shows the start of the instance period of the NRT-IT expressed as the number of GPS seconds since 00:00:00 UTC, January 6, 1980.
  • the time of day of time_span_start should be in minutes 00 of the hour.
  • the value 0 of time_span_start shows the duration of the NRT-IT instance started from the past.
  • the value of time_span is the same for each section of a multi-sectioned NRT-IT instance.
  • the values of time_span_start and time_span_length are set so as not to overlap with other NRT-IT instances of the IP subnet in a specified period.
  • time_span_length field (11 bits) identifies the number of minutes started at the time recognized in time_span_start covered by the instance of the NRT-IT. Once set, the value of time_span_length is not changed from the value of given time_span_start. If the value of time_span_length is 0, the NRT-IT instance covers all times started at time_span_start in the indefinite future. When the value of time_span_start is 0, time_span_length is meaningless.
  • time_span_start is the same for each section of the multi-sectioned NRT-IT instance.
  • the values of time_span_start and time_span_length are set so as not to overlap with other NRT-IT instances of the IP subnet in a specified period.
  • a num_items_in_section field (8 bits) indicates the number of content items described in the NRT-IT section.
  • a content_linkage field (16 bits) indicates an identification number of content within a range of 0x0001 to 0xFFFF. The value 0x0000 is not used.
  • the content_linkage combines the metadata of the NRT-IT with one or more files of two linkage functions: FLUTE FDT associated with the NRT service and also forms an identifier for Text Guaranteement in Text FragmentTable (TF_id).
  • the value of the content_linkage field corresponds to the value of the FDTCotent-Linkage element or the value of the File-Content-Linkage element in the FLUTE FDT of each file associated with the content item.
  • the priority rule is applied when matching each content_linkage value including the corresponding content linkage element in the FLUTE FDT.
  • the TF_availiable flag is set to '1' if the Text Fragment exists in the Text Frangment Table of the service signaling channel. If a Text Fragment is not included in the service signaling channel for the content item, the value of the TF_availiable field is set to '0'.
  • the low_lantency flag is set to '1', the content is valid in the current digital transmission with a sufficiently low latency that the number of times the user should try when waiting. If set to '0', the retrieval delay is longer and the user interface suggests later viewing to the user.
  • playback_length_in_seconds (20 bits) is an integer representing the playback time of the content in seconds. Content containing text and / or still images is represented by the value '0'. For content including audio or audio / video content, playback_length_in_seconds indicates the playback time of the audio or audio / video content.
  • the content_length_included flag When the content_length_included flag is set to '1', it indicates that the content_length field is present in the repetition of the 'for' loop. If set to '0', it indicates that the content_length field does not exist in the repetition of the 'for' loop.
  • the playback_delay_included flag When the playback_delay_included flag is set to '1', the playback_delay field indicates that it is present in an iteration of a 'for' loop. If set to '0', the playback_delay field indicates that it is not present in the iteration of the 'for' loop.
  • the expiration field indicates that it exists in an iteration of a 'for' loop. If set to '0', the expiration field does not exist in the iteration of the 'for' loop.
  • the duration (12 bit) field indicates the scheduled cycle time of the carousel, in minutes, that includes the referenced content item in the range of 1 to 2880.
  • the receiver uses a duration parameter that determines the amount of time to capture the referenced content.
  • playback_delay (20 bits) is represented by the number of seconds following the receipt of the first byte before playing in the associated content, while buffering the incoming stream. A value of 0 indicates that playback has started immediately. If playback_delay is not set, the receiver retrieves the complete file or the file before playback.
  • the expiration field (32 bits) represents an expiration time expressed as the number of GPS seconds since 00:00:00 UTC, January 6, 1980. After expiration, the content is deleted from memory. If no expiration time is set, the receiver uses its own method of managing memory resources.
  • a content_name_length_ field (8 bits) indicates the length (byte unit) of content_name_text.
  • the content_name_text () field represents a content item title in a format of a multi-string structure.
  • a content_descriptors_length field (12 bits) indicates the total length (in bytes) of the content_descriptor that provides additional information about the content level.
  • the content_descriptor is a descriptor applied to each content item separately.
  • descriptor_length (10 bits) represents the total length of the descriptor (byte unit).
  • the descriptor is a descriptor generally applied to all content items described in the current NRT-IT section.
  • NCT section 17 illustrates an embodiment of a bit stream syntax structure for an NCT section (NRT_content_table_section) according to the present invention.
  • NRT_content_table_section A detailed description of each field of the NCT section is as follows.
  • a table_id field (8 bits) is an identifier of a table, and an identifier for identifying an NCT may be set.
  • a section_syntax_indicator field (1 bit) is an indicator that defines the section format of the NCT.
  • the private_indicator field (1 bit) indicates whether the NCT follows the private section.
  • a section_length field (12 bits) indicates a section length of NST.
  • An NRT_channel_id field (16 bits) indicates a value that can uniquely identify an NRT service including content described in the NCT.
  • a version_number field (5 bits) represents the version number of the NCT.
  • a current_next_indicator field (1 bit) indicates whether information included in the corresponding NCT section is currently applicable information or future applicable information.
  • a section_number field (8 bits) indicates a section number of the current NCT section.
  • the last_section_number field (8 bits) indicates the last section number of the NCT.
  • a protocol_version field (8 bits) indicates the protocol version to allow NCT to transfer parameters with different structures than those defined in the current protocol (An 8-bit unsigned integer field whose function is toallow, in the future, this NRT Content Table to carry parameters that may be structured differently than those defined in the current protocol.At present, the value for the protocol_version shall be zero.Non-zero values of protocol_version may be used by a future version of this standard to indicate structurally different tables.)
  • a num_contents_in_section field (8 bits) indicates the number of contents described in this NCT. In this case, the number of contents indicates the number of contents (or files) transmitted through a virtual channel specified by source_id.
  • a 'for' loop (or a content loop) is performed as many as the number of contents corresponding to the num_contents_in_section field value, thereby providing detailed information of the corresponding content for each content.
  • a content_version field indicates a version number for content (or file) having a specific content_id value. That is, suppose that the content_id of the content previously received and stored by the receiver is 0x0010, and the same content, that is, the content having the content_id value of 0x0010 is transmitted. In this case, when the content_version field value is changed, newly announced content is received through the NCT to update or replace previously stored content.
  • the content_version field value means a serial number indicating a version of a release, but may actually directly represent published (released) time. In this case, when the publish time is hard to be expressed as the content_version field, a new field that can express the published (released) time may be used.
  • a content_id field (16 bits) indicates an identifier that can uniquely identify the content (or file).
  • a content_available_start_time field (32 bits) and a content_available_end_time field (32 bits) indicate a start time and an end time of a FLUTE session for transmitting the content.
  • ETM_location field (2 bits) describes the presence and location of an extended text message (ETM).
  • a content_length_in_seconds field (30 bits) indicates the actual playback time of the corresponding content in seconds when the content (or file) is an A / V file.
  • a content_size field (48 bits) indicates the size of the content (or file) in bytes.
  • a content_delivery_bit_rate field (32 bits) indicates a bit rate for transmitting the content (or file) and indicates a target bit rate. That is, it indicates how much bandwidth to allocate when the service provider or broadcasting station transmits the corresponding content. Therefore, when the receiver uses content_size and content_delivery_bit_rate, the minimum time required to receive the corresponding content (or file) can be known. That is, the time taken to receive the content can be estimated and the corresponding information can be provided to the user. The minimum reception time is obtained by calculating (conent_size * 8) / (content_delivery_bit_rate), and the unit is seconds.
  • a content_title_length field (8 bits) indicates the length of content_title_text () in bytes. Using this field, the receiver can know how many bytes of data to read in order to correctly obtain content_title_text () information.
  • the content_title_text () field indicates a content title in the format of a multiple string structure.
  • the receiver may acquire configuration information of NRT content / file using the NCT and provide a guide for NRT content / file based on the obtained configuration information of NRT content / file.
  • the access information of the FLUTE session for transmitting the content / file selected from the guide may be obtained from the NST, and the selected content may be received using the obtained FLUTE session access information.
  • the present invention may transmit container information, encoding information, and a decoding parameter of a media object, which are essential for the rendering of content / files constituting an NRT service, in the NCT. Accordingly, the receiving system extracts container information, encoding information, and decoding parameters of the media object, which are essential for rendering of the corresponding content, for each content, and can be used to render the corresponding content.
  • FIG. 18 shows an embodiment of a bit stream syntax structure of an SMT section that provides signaling information about NRT service data.
  • the SMT describes signaling information (or signaling information of NRT service) and IP access information of a mobile service in an ensemble in which the SMT is transmitted.
  • the SMT also provides broadcast stream information of the corresponding service using Transport_Stream_ID, which is an identifier of a broadcast stream to which each service belongs.
  • Transport_Stream_ID is an identifier of a broadcast stream to which each service belongs.
  • the SMT according to the embodiment of the present invention includes description information of each mobile service (or NRT service) in one ensemble, and other additional information may be included in a descriptor area.
  • the SMT section may be transmitted in the form of an IP stream in an RS frame.
  • RS frame decoders of a receiver to be described later decode an input RS frame and output the decoded RS frame to a corresponding RS frame handler.
  • Each RS frame handler divides the input RS frame into row units to form an M / H TP and outputs the M / H TP handler.
  • a table_id field (8 bits) is a field for distinguishing a type of table, and this shows that the table section is a table section in SMT (table_id: An 8-bit unsigned integer number that indicates the type of table section being defined in Service Map Table (SMT).
  • SMT Service Map Table
  • a section_syntax_indicator field (1 bit) is an indicator defining a section format of an SMT.
  • the section format may be, for example, a short-form syntax ('0') of MPEG (section_syntax_indicator: This 1-bit field shall be setto '0' to always indicate that this table is derived from the "short" form of the MPEG-2 privatesection table).
  • the private_indicator field (1 bit) indicates whether the SMT follows the private section (private_indicator: This1-bit field shall be set to '1').
  • section_length A 12-bit field.It specifies the number of remaining bytes this table section immediately following this field.The value in this field shall not exceed 4093 (0xFFD)).
  • a table_id_extension This is a 16-bit field and is table-dependent.It shall be considered to be logically part of the table_id field providing the scope for the remaining fields).
  • the table_id_extension field includes an SMT_protocol_version field.
  • SMT_protocol_version An 8-bit unsigned integer field whose function is to allow, in the the SMT_protocol_version field (8 bits) indicates the protocol version to allow SMT to transmit parameters whose parameters differ from those defined in the current protocol. future, this SMT to carry parameters that may be structured differently than those defined in the current protocol.At present, the value for the SMT_protocol_version shall be zero.Non-zero values of SMT_protocol_version may be used by a future version of this standard to indicate structurally different tables).
  • An ensemble_id field (8 bits) is an ID value associated with a corresponding ensemble, and values of '0x00' to '0x3F' may be allocated. The value of this field is preferably derived from parade_id of TPC data. If the ensemble is transmitted through the primary RS frame, the most significant bit (MSB) is set to '0' and the remaining 7 bits are used as the parade_id value of the parade. Meanwhile, if the ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to '1' and the remaining 7 bits are used as the parade_id value of the parade (ensemble_id: This 8-bit unsigned integer).
  • this field in the range 0x00 to 0x3F shall be the Ensemble ID associated with this Ensemble.
  • the value of this field shall be derived from the parade_id carried from the baseband processor of physical layer subsystem, by using the parade_id of the associated Parade for the least significant 7 bits, and using '0' for the most significant bit when the Ensemble is carried over the Primary RS frame, and using '1' for the most significant bit when the Ensemble is carried over the Secondary RS frame.).
  • a version_number field (5 bits) represents a version number of the SMT.
  • the section_number field (8 bits) indicates the number of the current SMT section (section_number: This 8-bit field shall give the section number of this NRT Service Signaling table section.
  • the section_number of the first section in an NRT Service Signaling table shall be 0x00.
  • the section_number shall be incremented by 1 with each additional section in the NRT Service Signaling table).
  • the last_section_number field (8 bits) indicates the last section number constituting the SMT table.
  • last_section_number This 8-bit field shall give the number of the last section (i.e., the section with the highest section_number) of the Service Signaling table of which this section is a part).
  • a num_services field (8 bits) indicates the number of services in the SMT section. (num_services: This 8 bit field specifies the number of services in this SMT section.). At least one mobile service may be included and received as an ensemble including the SMT, at least one NRT service may be included and received, or both mobile service and NRT service may be included. If only ensemble NRT services including SMT are transmitted and transmitted, the number of NRT services included in the SMT may be indicated.
  • a 'for' loop (or a service loop) is performed as many as the number of services corresponding to the num_services field value, thereby providing signaling information for a plurality of services. That is, signaling information of the corresponding service is displayed for each service included in the SMT section.
  • the service may be a mobile service or an NRT service.
  • the following field information may be provided for each service.
  • the service_id field (16 bits) indicates a value that uniquely identifies this service (A 16-bit unsigned integer number that shall uniquely identify this service within the scope of this SMT section.).
  • the service_id field value of one service does not change while the service is maintained. In order to avoid confusion at this time,
  • the 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 service_id for the service should not be used for another service until after a suitable interval of time has elapsed.).
  • the service_id will identify the NRT service.
  • the Multi_ensemble_service field (2 bits) identifies whether the service is transmitted through one or more ensemble.
  • this field only identifies whether a service is represented as part of a service transmitted over that ensemble. In other words, if the service is an NRT service, the field identifies whether the NRT service is transmitted through one or more ensemble (multi_ensemble_service: A two-bit enumerated field that shall identify whether the Service is carried across more than one Ensemble. , this field shall identify whether or not the Service can be rendered only with the portion of Service carried through this Ensemble.).
  • multi_ensemble_service A two-bit enumerated field that shall identify whether the Service is carried across more than one Ensemble. , this field shall identify whether or not the Service can be rendered only with the portion of Service carried through this Ensemble.
  • the service_status field (2 bits) identifies the state of the corresponding service.
  • the MSB indicates whether the service is active ('1') or inactive ('0'), and the LSB indicates whether the service is hidden ('1') or not ('0').
  • the MSB of the service_status field indicates whether the corresponding NRT service is active ('1') or inactive ('0'), and the LSB indicates that the NRT service is hidden ('1'). Indicates whether or not ('0').
  • An SP_indicator field (1 bit) indicates whether a service is service protected. If the SP_indicator field value is 1, service protection is applied to at least one of the components required to provide a meaningful presentation of the service (A 1-bit field that indicates, when set to 1, service protection is applied). to at least one of the components needed to provide a meaningful presentation of this Service).
  • the short_service_name_length field (3 bits) indicates the length of the short service name described in the short_service_name field in bytes.
  • the short_service_name field indicates the short name of the service (short_service_name: The short name of the Service, each character of which shall be encoded per UTF-8 [29] .When there is an odd number of bytes in the short name, the second byte of the last of the byte pair per the pair count indicated by the short_service_name_length field shall contain 0x00). For example, if the service is a mobile service, the short name of the mobile service is displayed, and if the service is an NRT service, the short name of the NRT service is displayed.
  • a service_category field (6 bits) identifies the type category of the corresponding service. If the value of this field is set to a value indicating "informative only", the value of this field is treated as an informative description of the category of the service. And the receiver is required to examine the component_level_descriptors () field of the SMT to identify the actual category of the received service. For services with video and / or audio components they have an NTP time base component.
  • the value of the service_category field has a value of '0x0E', for example, this indicates that the service is an NRT service.
  • signaling information of a service currently described in the SMT section is signaling information of an NRT service.
  • a num_components field (5 bits) indicates the number of IP stream components in the corresponding service (num_components: This 5-bit field specifies the number of IP stream components in this Service).
  • the IP_version_flag field (1 bit) indicates that the source_IP_address field, the service_destination_IP_address field, and the component_destination_IP_address field are IPv6 addresses when set to '1', and that the source_IP_address field, service_destination_IP_address field, and component_destination_IP_address field are IPv4 addresses when set to '0'.
  • IP_version_flag A 1-bit indicator, which when set to '0' shall indicate that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses. The value of '1' for this field is reserved for possible future indication that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are for IPv6.Use of IPv6 addressing is not currently defined).
  • source_IP_address_flag A 1-bit Boolean flag that shall indicate, when set, that a source IP address value for this Service is present to indicate a source specific multicast.
  • Use service_destination_IP_address_flag A 1-bit Boolean flag that indicates, when set to '1', that a service_destination_IP_address value is present, to serve as the default IP address for the components of this Service).
  • the source_IP_address field (32 or 128 bits) needs to be interpreted when the source_IP_address_flag is set to '1', but does not need to be interpreted when the source_IP_address_flag is not set to '0'.
  • source_IP_address_flag When source_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit IPv4 address indicating a source of the corresponding virtual channel. If the IP_version_flag field is set to '1', this field indicates a 32-bit IPv6 address indicating the source of the corresponding virtual channel (source_IP_address: This field shall be present if the source_IP_address_flag is set to '1' and shall not be present if the source_IP_address_flag is set to '0'.If present, this field shall contain the source IP address of all the IP datagrams carrying the components of this Service.The conditional use of the 128 bit-long address version of this field is to facilitate possible use of IPv6 in the future, although use of IPv6 is not currently defined).
  • the Source_IP_address field is a source IP address of the same server transmitting all channels of the FLUTE session.
  • the service_destination_IP_address field (32 or 128 bits) needs to be interpreted when the service_destination_IP_address_flag is set to '1', but does not need to be interpreted when the service_destination_IP_address_flag is set to '0'. If service_destination_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit destination IPv4 address for the corresponding virtual channel.
  • service_destination_IP_address_flag is set to '1' and the IP_version_flag field is set to '1', this field indicates a 64-bit destination IPv6 address for the corresponding virtual channel. If the service_destination_IP_address cannot be resolved, the component_destination_IP_address field in the num_components loop must be resolved, and the receiving system must use component_destination_IP_address to access the IP stream component (service_destination_IP_address: This field shall be present if the service_destination_IP set_1_address_flag 'and shall not be present if the service_destination_IP_address_flag is set to' 0'.If this 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
  • the SMT according to the present embodiment provides information about a plurality of components by using a for loop.
  • a 'for' loop (or a component loop) is performed as many as the number of components corresponding to the num_components field value, thereby providing access information for a plurality of components. That is, it provides connection information of each component included in the service. In this case, the following field information may be provided for each component.
  • one component corresponds to one FLUTE session.
  • the essential_component_indicator field (1 bit), if set to '1', indicates that the corresponding component is an essential component for a mobile service. Otherwise_component_indicator: A one-bit indicator which, when set to '1' shall indicate that this component is an essential component for the service.Otherwise, this field indicates that this component is an optional component).
  • the component_destination_IP_address_flag field (1 bit) is a flag indicating that the component_destination_IP_address field exists for the component if it is set to '1' (component_destination_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set to '1' that the component_destination_IP_address is present for this component).
  • a port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding UDP / IP stream component.
  • the destination UDP port number is incremented by 1 starting from the value of the destination_UDP_port_num field.
  • the destination UDP port number is incremented by two starting from the value of the destination_UDP_port_num field, because this field shall indicate the number of destination UDP ports associated with this UDP / IP stream component.
  • the values of the destination UDP port numbers shall start from the component_destination_UDP_port_num field and shall be incremented by one, except in the case of RTP streams, when the destination UDP port numbers shall start from the component_estination_UPD_port_num field and shall be incremented by two, to allow for the RTCP streams associated with the RTP streams).
  • a destination_UDP_port_num field (16 bits) indicates a destination UDP port number for the corresponding IP stream component.
  • the value of destination_UDP_port_num is an even number, and the next higher value indicates the destination UDP port number of the associated RTCP stream (component_destination_UDP_port_num: A 16-bit unsigned integer field, that represents the destination UDP port number for this UDP / IP stream component.
  • component_estination_UDP_port_num shall be even, and the next higher value shall represent the destination UDP port number of the associated RTCP stream).
  • component_destination_IP_address field 32 or 128 bits
  • this field indicates a 32-bit destination IPv4 address for the corresponding IP stream component.
  • IP_version_flag field is set to '1'
  • this field indicates a 128-bit destination IPv6 address for the corresponding IP stream component (component_destination_IP_address: This field shall be present if the component_destination_IP_address_flag is set to '1' and shall not be present if the component_destination_IP_address_flag is set to '0'.
  • the destination address of the IP datagrams carrying this component of the M / H Service shall match the address in this field.
  • the destination address of the IP datagrams carrying this component shall match the address in the M / H_service_destination_IP_address field.
  • a num_component_level_descriptors field (4 bits) indicates the number of descriptors that provide additional information of the component level.
  • the component_level_descriptor () is included in the component loop as many as the number corresponding to the num_component_level_descriptors field value, thereby providing additional information about the component.
  • a num_service_level_descriptors field (4 bits) indicates the number of descriptors that provide additional information of the corresponding service level.
  • Service_level_descriptor () is included in the service loop as many as the number corresponding to the num_service_level_descriptors field value to provide additional information about the service. If the service is a mobile service, additional information about the mobile service is provided. If the service is an NRT service, additional information about the NRT service is provided.
  • a num_ensemble_level_descriptors field (4 bits) is the number of descriptors that provide additional information of the ensemble level.
  • Ensemble_level_descriptor () is included in the ensemble loop as many as the number corresponding to the num_ensemble_level_descriptors field value, thereby providing additional information about the ensemble.
  • component_descriptor () may also be provided as component_level_descriptors () in the SMT of FIG. 18.
  • the component_descriptor () is used as one of the component level descriptor component_level_descriptors () of the SMT, and describes additional signaling information of the corresponding component.
  • the signaling information necessary for receiving the corresponding FULTE session in the mobile NRT service may also be provided using the component descriptor of FIG. 14.
  • the component_data (component_type) field provides data for FLUTE file delivery as shown in FIG. Since description of each field of FIG. 14, FIG. 15 was mentioned above, it abbreviate
  • FIG. 19 illustrates an FDT schema for mapping a file and content_id according to an embodiment of the present invention
  • FIG. 20 illustrates an FDT schema for mapping a file and content_id according to another embodiment of the present invention.
  • the FDT instant level entry file designation method is represented.
  • NRT content has multiple files but each file has no representation, making it difficult to find related files of NRT content.
  • FIGS. 19 and 20 illustrate inserting content_id into the FDT in each file.
  • the FDT instance level means a level including a definition part of the common attributes of all files declared in the FDT, and the FDT file level includes definitions of individual attributes in each file. It can be used to mean a level.
  • the receiver identifies whether the service transmitted through the channel is an NRT service based on SMT.
  • the receiver also identifies the content item and file of the corresponding NRT service.
  • the receiver can identify the file and the content item in the NRT service, but the receiver cannot match the file of the content item because there is no information about the file of the content item. Thus, the receiver cannot process the received NRT service.
  • the present invention may provide a method for identifying whether a content item is associated.
  • the method will show what files exist in the content item.
  • the receiver can properly process the received NRT service.
  • the method may designate based on the FDT information in the FLUTE session by transmitting the NRT service. For example, each file that constructs a content item is identified based on the content-location and TOI fields specified in the FLUTE session.
  • the content_id in the FDT is matched with the content identifier (content_id) of the NCT or the content identifier of the content fragment in the OMB BCAST SG.
  • the part indicated by 1 denotes a content identifier at the FDT-Instance level, where the content identifier declared is all files declared in the FDT-Instance. Is given to. Of course, this information may be overridden by assigning a new content identifier at the file level. Alternatively, if a specific file belongs to a content item other than the content item defined at the FDT-Instance level, this may be indicated by giving a file level content_id to be described below. In this embodiment, content_id is expressed using 16 bits.
  • the part labeled 2 declares the content_id at the file level. If the files included in the FDT instance belong to different content items, this method allows each file to belong to which content item and all files of the content to which entry. Signal whether it belongs.
  • Number 3 is a method for notifying whether each file is an entry file for each file.
  • the file that corresponds to the root file that must be played first among the files that make up the content item or must be accessed first to access the content item is called an entry file.
  • the entry attribute may be omitted and the default value is false, indicating that the file is not an entry file.
  • "entry” is the head of the file that needs to be processed to execute the file. . For example, "index.html” may be "entry”.
  • the entry file can be set to "true” and other files can be set to "false”. Through the entry file, duplication of transmitting the same file can be effectively controlled. Once the file has downloaded, there is no need to download it to another or separate instance because the entry file points to a file of content for another reference.
  • a particular file signals the entry in a group related to the file level to serve as an entry in a particular group but may fail in other groups.
  • the following two methods can be considered to indicate whether an entry file is provided when a content identifier is assigned at the FDT-instance level.
  • the content identifier overlaps at the FDT-Instance level and the file level. It may have a structure. In other words, one of the file-level and the FDT-instance level may specify the content_id, but when the other content_id is specified together at the file-level and the FDT-instance level, the content_id of the file-level has priority.
  • the FDT-Content-ID-Type is separately defined for the FDT-instance level content identifier and extended to include the content location of the entry file as indicated by 2.
  • the entry level is defined by its content_id. For example, it shows which entry file is in each content_id.
  • the overlapping signaling of content-location may be a disadvantage, but it may be advantageous that the entry file configuration information may be directly obtained for each content item.
  • 21 is a flowchart illustrating a method of operating a receiver according to an embodiment of the present invention.
  • a receiver receives NRT service signaling data through an NRT service signaling channel, displays NRT guide information using the received NRT service signaling data, and displays selected NRT content for the selected NRT content.
  • the NRT service data may be received to provide an NRT service.
  • a channel is selected by the user (S1000). Then, the physical transport channel is tuned according to the selected channel.
  • the VCT and the PMT are obtained from the broadcast signal received through the tuned physical transport channel (S1010).
  • the acquired TVCT (VCT) is parsed to determine whether there is an NRT service (S1020). This can be known by checking the value of the service_type field in the virtual channel loop of the VCT. For example, when the value of the service_type field is 0x08, it may be checked whether there is an NRT service. If it is not 0X08, since the corresponding virtual channel does not transmit the NRT service, an appropriate operation such as providing general A / V service may be performed according to the information included in the virtual channel (S1111).
  • the virtual channel transmits the NRT service, so that it matches with a specific PID (PID_NST) of a stream including a well-known IP address for accessing the NRT service signaling channel.
  • PID_NST a specific PID of a stream including a well-known IP address for accessing the NRT service signaling channel.
  • the receiver receives a transport packet (TP) having a PID value corresponding to the PID value from the obtained PID value PID_NST (S1040).
  • TP transport packet
  • the receiver extracts NRT service signaling data including an NRT service table (NST) from the received TP, or extracts an IP address for accessing the above-described NRT service signaling channel from the received TP, and then forms another form through the IP layer.
  • NST NRT service table
  • the receiver obtains channel information for transmitting NRT service data for each NRT service from the NST (S1060).
  • the receiver obtains an NRT content table (NCT) having a value of an NRT_channel_id field that matches the Channel_id value, which is an identifier of the obtained channel information, from the NRT service signaling data (S1070).
  • NCT NRT content table
  • the receiver obtains content information on NRT content constituting each NRT service from each field of the acquired NCT (S1080).
  • the content information may include at least one of the content_delevery_bit_rate, content_available_start_time, content_available_end_time, and content_title_text () fields according to the above-described embodiment of the NCT.
  • the receiver displays NRT guide information using content information.
  • the user may select NRT content to use or receive from the displayed NRT guide information.
  • the receiver acquires NRT service access information to which the selected NRT content belongs from the NST (S1100).
  • the NRT service access information may include, for example, channel information or IP address information for receiving NRT service data.
  • the receiver may access the channel or server for transmitting the NRT service using the obtained NRT service access information, receive the corresponding NRT content (S1110), and perform an appropriate operation according to the received NRT content.
  • 22 and 23 illustrate an embodiment different from an embodiment of a reception system capable of receiving, storing, and playing back NRT content for an NRT service.
  • the receiver of FIG. 23 includes an operation controller 100, a baseband processor 110, a service demultiplexer 120, a stream component handler 130, a media handler 140, a file handler 150, a service manager 160, PVR Manager 170, First Storage 180, SG Handler 190, EPG Manager 191, NRT Service Manager 192, Application Manager 194, Middleware Engine 193, Presentation Manager 195 And a user interface (UI) manager 196.
  • UI user interface
  • the baseband processor 110 may include a tuner 111 and a demodulator 112.
  • the service demultiplexer 120 includes an MPEG-2 TP handler 121, a PSI / PSIP handler 122, an MPEG-2 TP demultiplexer 123, a descrambler 124, and a second storage 125. can do.
  • the stream component handler 130 may include a packetized elementary stream (PES) decoder 131, an elementary stream (ES) decoder 132, a PCR handler 133, an STC handler 134, and a DSM-CC addressable section handler 135. ), An IP datagram handler 136, a descrambler 137, a UDP handler 138, a service signaling section handler 138-1, and a conditional access system (CAS) 139.
  • PES packetized elementary stream
  • Media handler 140 may include an A / V decoder 141.
  • the file handler 150 may include an ALC / LCT stream handler 151, a file reconstruction buffer 152, an XML parser 153, an FDT handler 154, a decompressor 155, and a third storage unit ( 156, and file decoder 157.
  • the tuner 111 tunes a broadcast signal of a desired channel among broadcast signals received through terrestrial waves, for example, by controlling the service manager 160 to generate an intermediate frequency (IF) signal. Down conversion is performed to the demodulator 112.
  • the tuner 111 may receive a real time stream and a non real time stream. In the present invention, the non-real time stream will be referred to as an NRT stream.
  • the demodulator 112 performs automatic gain control, carrier recovery, and timing recovery on the digital IF signal of the passband input from the tuner 111, converts it into a baseband signal, and performs channel equalization. For example, when the broadcast signal is a VSB modulated signal, a VSB demodulation process is performed to perform automatic gain control, carrier recovery, and timing recovery.
  • the demodulated and channel equalized data in the demodulator 112 is output to the MPEG-2 TP handler 121 in the form of an MPEG-2 Transport Stream (TS) packet.
  • TS MPEG-2 Transport Stream
  • the MPEG-2 TP (Transport Stream Packet) handler 121 is composed of an MPEG-2 TP buffer and an MPEG-2 TP parser, and temporarily stores the output of the demodulator 112 and then analyzes a TS header to demodulate the demodulator 112. Is output to the demultiplexer 123 if it is an A / V TS packet for real time or an NRT TS packet, and to the PSI / PSIP handler 122 if it is a TS packet for a PSI / PSIP table.
  • the PSI / PSIP handler 122 includes a PSI / PSIP section buffer and a PSI / PSIP parser, and temporarily stores TS packets output from the MPEG-2 TP handler 121 and then refers to the TS by referring to a table identifier.
  • the table is restored from the PSI / PSIP section data included in the payload of the packet and parsed.
  • whether a table is composed of one section or a plurality of sections can be known through a table_id field, a section_number field, and a last_section_number field in the corresponding section. Collecting sections with the same table identifier completes the corresponding table.
  • the parsed table information is collected by the service manager 160 and stored in the first storage unit 180.
  • Table information such as VCT, PAT, PMT, DST, etc. according to the present invention is stored in the first storage unit 180 through the above process.
  • the service manager 160 stores the table information in the first storage unit 180 in the form of a service map and guide data.
  • the demultiplexer 123 divides the audio TS packet and the video TS packet into the PES decoder 131 if the input TS packet is an A / V TS packet in real time, and outputs the same to the PES decoder 131.
  • the DSM-CC handler 135 the demultiplexer 123 outputs a TS packet including a Program Clock Reference (PCR) to the PCR handler 133 and a CAS packet 139 if a TS packet includes CA (Conditional Access) information.
  • the NRT TS packet is divided into a TS packet including NRT service data and a TS packet including an NRT service signaling channel.
  • the TS packet of the NRT service data is assigned a unique PID to identify the NRT service, and the PID of the TS packet including the NRT service signaling channel is extracted using DST and PMT.
  • the demultiplexer 123 If the payload of the input TS packet is scrambled, the demultiplexer 123 outputs the descrambler 124 to the descrambler 124, and the descrambler 124 outputs information necessary to descramble from the CAS 139.
  • the control word is used to descramble the TS packet.
  • the demultiplexer 123 stores the real time A / V packet input by any one of temporary recording, scheduled recording, and time shift in the second storage unit 125.
  • the second storage unit 125 is a mass storage medium and may be, for example, an HDD. Download (ie, storage) and upload (ie, playback) in the second storage unit 125 are controlled by the PVR manager 170.
  • the demultiplexer 123 divides the audio TS packet and the video TS packet from the A / V TS packet uploaded from the second storage unit 125 and outputs the PTS decoder 131 according to a reproduction request.
  • the demultiplexer 123 is controlled by the service manager 160 and / or the personal Vedeo recorder (PVR) manager 170 for the above-described processing.
  • PVR personal Vedeo recorder
  • the service manager 160 when the service manager 160 indicates that the service_type field value in the VCT indicates that the NRT service is transmitted, the service manager 160 extracts identification information of each NRT service from the NRT service descriptor (NRT_service_descriptor ()) received in the virtual channel loop of the VCT. And the PID of the DST is extracted from the service location descriptor (or the ES loop of the PMT) of the VCT to receive the DST.
  • NRT_service_descriptor NRT_service_descriptor
  • the NRT service is identified from the received DST, and the PID of the MPEG-2 TS packet including the NRT service signaling channel is extracted using the DST and PMT to receive the identified NRT service.
  • the extracted PID is output to the demultiplexer 123.
  • the demultiplexer 123 outputs MPEG-2 TS packets corresponding to the PID output from the service manager 160 to the addressable section handler 135.
  • the PCR is a time reference value used for time synchronization of the audio ES and the video ES in the A / V decoder 141.
  • the PCR handler 133 restores the PCR included in the payload of the input TS packet and outputs the PCR to the STC handler 134.
  • the STC handler 134 restores the STC (System Time Clock), which becomes the reference clock of the system, from the PCR and outputs the STC (System Time Clock) to the A / V decoder 141.
  • the PES decoder 131 includes a PES buffer and a PES handler.
  • the PES decoder 131 temporarily stores the audio TS packet and the video TS packet, and then removes the TS header from each TS packet to restore the audio PES and the video PES.
  • the reconstructed audio PES and video PES are output to the ES decoder 132.
  • the ES decoder 132 includes an ES buffer and an ES handler.
  • the ES decoder 132 removes each PES header from the audio PES and the video PES and restores the pure data to the audio ES and the video ES.
  • the reconstructed audio ES and video ES are output to the A / V decoder 141.
  • the A / V decoder 141 decodes the audio ES and the video ES with respective decoding algorithms, restores them to a state before compression, and outputs the same to the presentation manager 195. At this time, time synchronization is performed when decoding the audio ES and the video ES according to the STC.
  • the audio decoding algorithm may be an AC-3 decoding algorithm, an MPEG 2 audio decoding algorithm, an MPEG 4 audio decoding algorithm, an AAC decoding algorithm, an AAC + decoding algorithm, an HE AAC decoding algorithm, an AAC SBR decoding algorithm, an MPEG surround decoding algorithm, or a BSAC decoding.
  • At least one of the algorithm may be applied, and the video decoding algorithm may apply at least one of an MPEG 2 video decoding algorithm, an MPEG 4 video decoding algorithm, an H.264 decoding algorithm, an SVC decoding algorithm, and a VC-1 decoding algorithm.
  • the CAS 139 includes a CA stream buffer and a CA stream handler.
  • the CAS 139 temporarily stores the TS packet output from the MPEG-2 TP handler 121 or the service protection data restored and output from the UDP datagram handler 138. Thereafter, information (eg, a control word used for scramble) for descrambling is restored from the stored TS packet or service protection data. That is, an EMM (Entitlement Management Message), an ECM (Entitlement Control Message), etc., included in the payload of the TS packet are extracted, and the extracted EMM, ECM, etc. are analyzed to obtain information necessary for descramble.
  • the ECM may include a control word (CW) used for scramble. In this case, the control word may be encrypted with an authentication key.
  • the EMM may include an authentication key and entitlement information of the corresponding data. Information necessary for descrambling obtained by the CAS 139 is output to the descramblers 124 and 137.
  • the DSM-CC section handler 135 is composed of a DSM-CC section buffer and a DSM-CC section parser.
  • the DSM-CC section handler 135 temporarily stores the TS packets output from the demultiplexer 123 and includes the DSM-CC section handler 135 in the payload of the TS packets.
  • the addressable section is restored, the header and CRC checksum of the addressable section are removed, the IP datagram is restored, and then output to the IP datagram handler 136.
  • the IP datagram handler 136 is composed of an IP datagram buffer and an IP datagram parser. After buffering the IP datagram received from the DSM-CC section handler 135, the IP datagram handler 136 extracts a header of the buffered IP datagram. After analyzing and restoring the UDP datagram from the payload of the IP datagram, the data is output to the UDP datagram handler 138.
  • the scrambled UDP datagram is descrambled by the descrambler 137 and then output to the UDP datagram handler 138.
  • the descrambler 137 receives information necessary to descramble (eg, a control word used for scramble) from the CAS 139 to descramble the UDP datagram, and then performs a UDP datagram. Output to handler 138.
  • the UDP datagram handler 138 is composed of a UDP datagram buffer and a UDP datagram parser, and buffers UDP datagrams output from the IP datagram handler 136 or the descrambler 137 and then buffers the UDP.
  • the header of the datagram is extracted and analyzed to restore data included in the payload of the UDP datagram. In this case, if the restored data is service protection data, the data is output to the CAS 139, if the NRT service signaling data is output to the service signaling section handler 138-1, and if the NRT service data is output to the ALC / LCT stream handler 151. .
  • the access information of the IP datagram transmitting the NRT service signaling channel is a well-known destination IP address and a well-known destination UDP port number.
  • the IP datagram handler 136 and the UDP datagram handler 138 have a well-known destination IP multicast address and a well-known destination UDP port number, and transmit an NRT service signaling channel.
  • a cast stream, that is, NRT service signaling data is extracted and output to the service signaling section handler 138-1.
  • the service signaling section handler 138-1 includes a service signaling section buffer and a service signaling section parser.
  • the service signaling section handler 138-1 restores and parses an NST from the NRT service signaling data and outputs the parsed NST to the service manager 160. Parsing the NST may extract access information of a FLUTE session for transmitting content / files constituting an NRT service and signaling information necessary for rendering the NRT service. For example, information necessary for rendering of content / files of an NRT service transmitted to each FLUTE session may be extracted from the NST.
  • Information necessary for rendering the content / files of the NRT service may be container information, encoding information, or may be a decoding parameter of a media object.
  • the information parsed from the NST is collected by the service manager 160 and stored in the first storage unit 180.
  • the service manager 160 stores the information extracted from the NST in the first storage unit 180 in the form of a service map and guide data.
  • the role of the service manager 160 may be performed by the NRT service manager 192. That is, the information parsed from the NST may be collected by the NRT service manager 192 and stored in the first storage unit 180.
  • the ALC / LCT stream handler 151 is composed of an ALC / LCT stream buffer and an ALC / LCT stream parser. After buffering the data of the ALC / LCT structure output from the UDP datagram handler 138, the ALC / LCT stream handler 151 receives the ALC from the buffered data. Parse the header and header extension of the / LCT session. As a result of analyzing the header and header extension of the ALC / LCT session, if the data transmitted to the ALC / LCT session is an XML structure, the data is output to the XML parser 153, and if the file structure is a file structure, the file reconstruction buffer 152 is output.
  • the data is output to the file decoder 157 or stored in the third storage unit 156.
  • the ALC / LCT stream handler 151 is controlled by the NRT service manager 192 when data transmitted through the ALC / LCT session is data for an NRT service. In this case, if data transmitted to the ALC / LCT session is compressed, the data is decompressed by the decompressor 155 and then output to at least one of the XML parser 153, the file decoder 157, and the third storage unit 156.
  • the XML parser 153 analyzes the XML data transmitted through the ALC / LCT session, outputs the analyzed data to the FDT handler 154 if the analyzed data is data for a file-based service, and if the data is for service guide, the SG handler ( 190)
  • the FDT handler 154 analyzes and processes a file description table of the FLUTE protocol through an ALC / LCT session. If the received file is a file for NRT service, the FDT handler 154 is controlled by the NRT service manager 192.
  • the SG handler 190 collects and analyzes data for a service guide transmitted in an XML structure and outputs the data to the EPG manager 191.
  • the file decoder 157 decodes the file output from the file reconstruction buffer 152 or the file output from the decompressor 155 or the file uploaded from the third storage unit 156 using a predetermined algorithm to decode the middleware engine 193. Output to the A / V decoder 141.
  • the middleware engine 193 analyzes and executes data of a file structure, that is, an application.
  • the application may be output to an output device such as a screen or a speaker through the presentation manager 195.
  • the middleware engine 193 is a JAVA based middleware engine.
  • the EPG manager 191 receives the service guide data from the SG handler 190 according to the user's input, converts the service guide data into the display format, and outputs it to the presentation manager 195.
  • the application manager 194 performs overall management regarding the processing of the application data received in the form of the file or the like.
  • the service manager 160 collects and analyzes PSI / PSIP table data or NRT service signaling data transmitted through an NRT service signaling channel to generate a service map and stores the service map in the first storage unit 125. In addition, the service manager 160 controls access information on the NRT service desired by the user, and controls the tuner 111, the demodulator 112, the IP datagram handler 136, and the like.
  • the operation controller 100 is the service manager 160, the PVR manager 170, the EPG manager 191, the NRT service manager 192, and the application manager 194 according to a user's command input through the UI manager 196. ), At least one of the presentation manager 195 is controlled to perform a function according to the user's command.
  • the NRT service manager 192 performs overall management of the NRT service transmitted in the form of content / file through a FLUTE session on the IP layer.
  • the UI manager 196 transmits a user's input to the operation controller 100 through the UI.
  • the presentation manager 195 may include at least one of audio and video data output from the A / V decoder 141, file data output from the middleware engine 193, and service guide data output from the EPG manager 191. And at least one of the screens.
  • any one of the service signaling section handler 138-1, the service manager 160, and the NRT service manager 192 configures the NRT service from the FLST session loop (or component loop of the NST) of the NST.
  • the FLUTE level access information is obtained from NRT_FLUTE_File_delivery_descriptor () received in the FLUTE session loop of the NST.
  • the FLUTE level access information is obtained from component_descriptor () received in the component loop of the NST.
  • the ALC / LCT stream handler 151 and the file decoder 157 access the FLUTE file delivery session using the obtained FLUTE level access information to collect files belonging to the session. Collecting these files constitutes one NRT service.
  • the NRT service may be stored in the third storage unit 156 or output to the middleware engine 193 or the A / V decoder 141 to be displayed on the display device.
  • the third storage unit 156 is a storage medium for storing a file such as NRT service data.
  • the third storage unit 156 may be shared with the second storage unit 125 or may be used separately.
  • 24 is a flowchart illustrating a method of receiving and providing an NRT service by a receiver according to an embodiment of the present invention.
  • the receiver may acquire NRT service signaling information through an NRT service signaling channel or receive an IP datagram in the case of a mobile NRT service, and obtain an SMT from the NRT service signaling information (S2010).
  • NRT service information may be obtained by parsing NRT_service_info_descriptor in a service level descriptor loop in SMT.
  • the obtained NRT service information may include an application type for each NRT service or requirement information for other NRT services.
  • the receiver outputs an NRT service guide based on the obtained NRT service information (S2030).
  • the NRT service guide may display application and service category information for each service.
  • detailed information may be further displayed based on each field of the NRT service info descriptor.
  • the detailed information may include, for example, capacity information of the corresponding NRT service according to the storage_requirement field or audio or video codec information of the corresponding NRT service according to the audio_codec_type or video_codec_type field.
  • the user may select an NRT service to receive or use based on the information displayed in the service guide.
  • the receiver obtains an identifier (content_id) for a content item constituting the selected NRT service from the NCT.
  • the receiver obtains an NRT_service_id corresponding to the selected NRT service from the SMT, obtains an NCT having an NRT_channel_id value that matches the obtained NRT_service_id value, and uses an NCT identifier (content_id) for a content item configuring a corresponding NRT service through the obtained NCT. ) Can be obtained.
  • the receiver accesses a FLUTE session to receive a file configuring a corresponding content item using the acquired content item identifier (content_id) (S2050). Since each file constituting the content item is matched with the TOI or Content-Location field specified in the FDT in the FLUTE session, the receiver then receives the file of the corresponding content item using the FLUTE session (S2060). For example, the reception of a file may be performed by reading an FDT in a corresponding FLUTE session and receiving a corresponding file or an object when the Content-ID attribute field of the corresponding file matches the acquired content_id.
  • the receiver may obtain a list of files corresponding to the content item by parsing the FDT instances in the corresponding FLUTE session.
  • the receiver acquires entry information including a list of files serving as an entry among the list of files (S2070).
  • the receiver provides the NRT service to the user based on the received content item and a list or entry information of files corresponding to the content item (S2080).
  • the content downloaded through the NRT service can be used at a point in time desired by the user independently of real-time broadcasting.
  • the broadcasting station may transmit the NRT service in advance, store and receive by the receiver, and designate to execute the content item of the corresponding NRT service at a time when a specific real time broadcast is transmitted or displayed on the receiver.
  • the NRT service may include content that can be executed at a specific time after downloading in advance in association with real-time broadcasting.
  • the NRT service may include content for preparing in advance to execute a specific NRT service at a specific time.
  • the NRT service content triggered at a specific time associated with real-time broadcasting such that a specific action is executed for a specific NRT service may be referred to as a triggered declarative object (TDO).
  • TDO triggered declarative object
  • the NRT service application may be classified into a non-real time declarative object (NDO) or a trigger declarative object (TDO) according to whether or not it is executed at a specific time.
  • the broadcasting station may transmit trigger information for triggering such a trigger declarative object (TDO).
  • TDO trigger declarative object
  • the trigger information may include information for the receiver to perform a specific action on a specific trigger declarative object at a specific time point.
  • the trigger information may include trigger signaling data (trigger signaling information) for signaling a trigger and trigger data constituting the trigger.
  • trigger signaling data trigger signaling information
  • a data stream for transmitting trigger data may be referred to as a trigger stream.
  • the trigger data may mean the trigger itself.
  • Such a trigger may include at least one of a trigger identifier for identifying a trigger, a TDO identifier for identifying an NRT service for triggering, action information to be performed on the TDO, and a trigger time.
  • the trigger identifier may be an identifier for uniquely identifying the trigger.
  • the broadcaster may transmit one or more triggers to broadcast program information for a predetermined time provided through the EIT.
  • the receiver may perform an action on the trigger target TDO at a specific time for each trigger based on one or more triggers. In this case, the receiver may distinguish each trigger using a trigger identifier.
  • the TDO identifier may be an identifier for identifying NRT service content that is a target of a trigger. Accordingly, the TDO identifier may include at least one of a triggered NRT service identifier (NRT_service_id), content linkage (content_linkage), a URI, or a URL of an NRT content item entry. And a target identifier (targer_service_id) for identifying a trigger target TDO to be described later.
  • the TDO action information may include information on an action to be performed on the TDO to be triggered.
  • the action information may be at least one of execution, termination, and extension instructions of the target TDO.
  • the action information may include an instruction for generating a specific function or event in the target TDO.
  • the trigger may request the receiver to activate the target TDO.
  • the action information includes an extension command of the target TDO
  • the trigger may indicate to the receiver that the target TDO is to be extended.
  • the action information includes a termination command of the target TDO
  • the trigger may indicate to the receiver that the target TDO should be terminated.
  • the broadcast station may control the TDO operation in the receiver according to the real-time broadcast content through the trigger.
  • the trigger time may mean a time designated for performing (triggering) a designated action on the target TDO.
  • the trigger time may be synchronized with a video stream of a specific virtual channel in order to associate the NRT service with a real time broadcast.
  • the broadcasting station may designate the trigger time with reference to the PCR referenced in the video stream.
  • the receiver may trigger the TDO at a time designated by the broadcasting station by referring to the PCR referenced by the video stream.
  • the broadcast station may signal the trigger by including a trigger identifier in the header of the video stream to transmit the correct trigger time.
  • the trigger time may be designated as UTC time.
  • UTC time has the advantage that you can trigger by referring to absolute time, not relative time.
  • Such trigger time may be an accurate trigger time and may include an approximate start time.
  • the receiver may receive an approximate time and prepare an action for the target TDO in advance before the correct trigger time. For example, the receiver may prepare to execute the TDO in advance and operate the TDO naturally at the trigger time.
  • 25 illustrates a bitstream syntax of a trigger configured according to an embodiment of the present invention.
  • the trigger or trigger data is configured in the form of a trigger table, and the syntax is written in the form of an MPEG-2 private section to facilitate understanding, but the format of the data may be in any form.
  • other methods such as signaling in the form of a Session Description Protocol (SDP) and signaling through a Session Announcement Protocol (SAP) may be used.
  • SDP Session Description Protocol
  • SAP Session Announcement Protocol
  • the table_id field is arbitrarily set (0XTBD) to identify that the table section is a table section constituting the trigger.
  • section_syntax_indicator field is set to 1, it indicates that the section follows the general section syntax.
  • the private_indicator field is set to 1.
  • the section_length field details the number of bytes remaining in this section from immediately after the section_length field to the end of the section.
  • the source_id field represents a source of a program associated with a virtual channel.
  • the TTT_version_number field may indicate version information of the trigger.
  • the version information of the trigger may indicate the version of the trigger protocol.
  • the trigger version information can be used to determine if there is a change in the trigger structure or the trigger itself. For example, if the version information of the trigger is the same, the receiver may determine that there is no change in the trigger. In addition, when there is a change in the version information of the trigger, the receiver may determine that there is a change in the trigger.
  • the trigger version information may include a plurality of version numbers, and the receiver may determine whether a change has occurred in the trigger based on some of the plurality of version numbers.
  • the section_number field indicates the number of the corresponding table section.
  • the last_section_number field means a table section of the last and highest number among the sections.
  • the num_triggers_in_section field means the number of triggers included in the corresponding table section.
  • the number of triggers included in one section may be one or plural.
  • the next 'for' loop may be repeated by the number of triggers.
  • the trigger_id field represents an identifier for uniquely identifying a trigger.
  • the trigger_time field represents a time for performing a trigger. Meanwhile, this field may not be included in the section, in which case the trigger time may be a time specified from the broadcast stream as described above.
  • the trigger_action field represents action information of a trigger to be performed at the trigger time.
  • the trigger action may include any one of preparation for the target TDO, execution of the target TDO, extension of the target TDO, or termination of the target TDO, and a command for generating a specific function or event in the target TDO. It may also include.
  • the trigger_description_length field represents the length of trigger_description_text.
  • the trigger_description_text field represents a textual description of the trigger.
  • the service_id_ref field represents an identifier for identifying a target TDO of a trigger.
  • the service_id_ref field may indicate an NRT_service_id field of SMT or NST to identify an NRT service of a target TDO of a trigger.
  • the content_linkage field represents an identifier for identifying a target TDO content item of a trigger.
  • the content_linkage field may indicate the content_linkage field of the NRT-IT or NCT to identify a target TDO content item of the trigger.
  • the service_id_ref field and the content_linkage field may be included in a class indicating one target TDO.
  • the num_trigger_descriptors field represents the number of trigger descriptors.
  • the trigger_descriptor () field represents a descriptor including information about a trigger.
  • a broadcaster may transmit one trigger according to a virtual channel.
  • the above-described trigger table may be included in the 0X1FF stream which is the PSIP basic PID and transmitted.
  • the first method is characterized in that the trigger table can be distinguished from other tables by uniquely allocating the table_id of the trigger table.
  • a PID corresponding to a trigger table may be allocated to a master guide table (MGT), and the trigger table may be transmitted in a stream of the corresponding PID.
  • MCT master guide table
  • the second method is characterized in that the receiver can process all tables in the stream of the corresponding PID as the trigger table.
  • At least one of trigger and trigger signaling information is transmitted through MPEG2 PES (Packetized Elemetary Stream) to designate an exact time point synchronized with video and audio.
  • MPEG2 PES Packetized Elemetary Stream
  • the receiver decoder operates in synchronization with the time stamp of the transmitter encoder.
  • the encoder has a main oscillator and a counter called the System Time Clock (hereinafter referred to as STC).
  • STC belongs to a specific program and is the main clock of the program for the video and audio encoders.
  • a display time information that is, a presentation time stamp (hereinafter referred to as a PTS) is generated, and the first part of a picture block or audio block Insert in
  • a Decode Time Stamp hereinafter referred to as DTS
  • the DTS and the PTS are identical except for the frame relocation of the B picture.
  • the DTS is additionally needed only for this frame relocation.
  • ATSC is defined to insert a PTS and a DTS at the beginning of each picture.
  • the output of the encoder buffer has a time stamp called a Program Clock Reference (hereinafter, referred to as PCR) at the transport packet level.
  • PCR time stamp may occur at intervals within 100 msec, and such PCR is used to synchronize the STC of the decoder and the STC of the encoder.
  • the video stream and the audio stream may have respective PTSs or DTSs corresponding to common STCs for synchronization of decoders. Therefore, it is possible to know when the audio stream and the video stream should be played for each decoding unit through each PTS and DTS, and audio and video are synchronized using the same.
  • the decoder of the receiver outputs the PES packet from the received TS stream to the Video PES Depacketizer, and outputs the PCR value inserted into the TS packet header to the PCR Counter. do.
  • the PCR counter counts PCR values 100 and outputs them to the comparison unit.
  • the video PES depacketizer outputs the header of the PES packet to the DTS / PTS extractor, and transmits the elementary stream (ES), that is, the image data to be displayed, to the elementary stream buffer & decoder (Elementary Stream). Buffer & Decoder).
  • the DTS / PTS extractor extracts the DTS value and the PTS value from the PES packet header and outputs the same to the comparator.
  • the comparison unit outputs each signal for the PCR value input from the PCR counter to the DTS value or the PCR value 100 to the PTS value to the decoding / display control block.
  • the decoding / display controller receives a signal indicating that the PCR value is a DTS value from the comparator, decodes the image data buffered in the elementary stream butter & decoder, and stores the decoded image data in a decoded stream memory. .
  • the decoding / display control unit displays the image data decoded and stored in the decoded stream memory through the display unit when receiving a signal for the PCR value of the PTS value from the comparator.
  • the MPEG2 PES may include a PTS and a DTS in a header, thereby synchronizing the presentation time between data transmitted during data transmission and one elementary stream (ES) or a plurality of ESs. . This may be referred to as a synchronized data stream.
  • ES elementary stream
  • a broadcast station may include trigger data or a trigger stream in a payload of a PES by using the synchronized data stream scheme, and designate a trigger time as a PTS value of a PES packet header.
  • the receiver may trigger the target TDO at a precise time according to the PCR value referenced by the PTS of the PES including the trigger.
  • the broadcasting station may synchronize the trigger at the exact time when the audio and video that the broadcasting station intends to trigger are played by using the PTS of the PES packet header designated as the trigger time and the PTS value of the audio and video PES packet header.
  • the header of the PES stream packet including the trigger may have a steam_type value of 0x06 to indicate a synchronized data stream method, stream_id may indicate an identifier of a preset stream, and PES_packet_length includes a payload of a PES stream. It may indicate the length of the PES stream.
  • FIG. 26 is a diagram illustrating a structure of a PES according to a synchronized data streaming method including a trigger according to an embodiment of the present invention.
  • the PES of the synchronized data streaming method may include a PES header and a PES payload, and the PES payload may include a synchronized data packet structure.
  • a trigger composed of a trigger table or another type of data may be included in the PES payload portion of FIG. 26 and transmitted.
  • the broadcaster may packetize the trigger in the form of an IP datagram and transmit the packetized trigger in the IP data region.
  • FIG. 27 illustrates, in bitstream syntax, a synchronized data packet structure of a PES payload for transmitting a trigger, according to an embodiment of the present invention.
  • the trigger may be included in the synchronized data packet structure and transmitted. A detailed description of each field in the structure follows.
  • the data_identifier field is an identifier for identifying the type of data included in the PES data packet. This may be set to 0X22 depending on the data type.
  • the sub_stream_id field is an identifier settable by the user (user private).
  • the PTS_extention_flag field indicates whether a PTS_field field exists. If the value of this field is 1, a PTS extension field may exist in the PES_data_packet field. In addition, if there is no PTS extension field, the value of this field may be zero.
  • the output_data_rate_flag field may be set to 0.
  • the syncnronized_data_packet_header_length field represents the length of an optional field included in a PES packet header. This field may be included when the PTS_extention_flag field is 1 and may indicate a length including synchroziced_data_privete_data_byte (s).
  • the PTS_extension field extends the PTS delivered from the header of the corresponding PES packet. This field may include 9 bits of Program Clock Reference (PCR) extension information.
  • PCR Program Clock Reference
  • the receiver can extend the PTS resolution of the synchronized data from 11.1 microseconds (90 kHz), which is the MPEG2 standard, to 37 nanoseconds (27 MHz).
  • the synchronized_data_private_data_byte field indicates the byte of the payload of the synchronized PES packet. If the protocol_encapsulation field in the data service table (DST) is one of a synchronized datagram, an IP datagram without LLC / SNAP, or a multiprotocol datagram with LLS / SNAP, the synchronized_data_byte field is unique. It can contain one datagram. Thus, when LLC / SNAP is used, only 8 bytes of the LLC / SNAP header may appear in the synchronized_data_byte of the first 8 bytes of the PES packet.
  • DST data service table
  • the receiver may extract the trigger stream from the payload of the PES.
  • the receiver may perform an action on the target TDO by using the PTS value of the PES header as the trigger time. Therefore, by synchronizing the trigger with respect to the PTS, which is a reference time for synchronizing the display of video and audio, the TDO may be triggered at the correct time in units of frames.
  • the trigger time is designated as PTS, synchronization with video and audio can be easily performed.
  • trigger signaling information for acquiring a trigger stream is transmitted.
  • the receiver may receive trigger signaling information and obtain a trigger stream included in the synchronized data stream of the PES based on the received trigger signaling information.
  • trigger signaling information for obtaining a trigger stream transmitted using synchronized data streaming.
  • a transmission method using DST 2. a transmission method through a service id descriptor, 3. a transmission method through a trigger stream descriptor, or 4. a stream type for a trigger stream
  • trigger signaling information is transmitted using at least one method of defining and transmitting.
  • the trigger signaling information may be transmitted through a data_service_table (DST) for an NRT service.
  • the DST is a table section for transmitting a data service.
  • a description of the DST and a description of one embodiment of data_service_bytes () constituting the DST are the same as described with reference to FIG. 8, and thus will be omitted.
  • the above-described DST may include signaling data for receiving each elementary stream (ES) constituting a data service. Therefore, trigger signaling data for receiving the trigger stream may also be included in the DST.
  • ES elementary stream
  • each data service may include one or more applications, and each application may be in the form of an application identification structure including an application identifier such as app_id.
  • Each application may include one or more data elements or data streams constituting the application.
  • the broadcasting station may include one trigger stream in a specific virtual channel (VC) to transmit the trigger stream through the data service.
  • VC virtual channel
  • one trigger stream can be transmitted per application. Therefore, embodiments of transmitting trigger signaling information by dividing the case for the two methods will be described below.
  • a data service for transmitting a trigger stream may be referred to as a trigger service.
  • the broadcast station may assign a fixed service identifier (Service ID) to the trigger service.
  • Service ID service identifier
  • the receiver may identify that one trigger stream is being transmitted on the corresponding virtual channel, for example, when the service identifier is 0X01 as a fixed value.
  • the broadcast station may transmit trigger signaling information in the application identification structure included in the DST.
  • the broadcast station may add 0x0001 as a value of the App_id_description field of the DST to set a value representing a bidirectional application for linking an NRT service such as TDO with real-time broadcasting.
  • app_id_byte_length may use 3 bytes as 0x0003 and app_id_byte may be allocated as 0x01 to indicate that the corresponding data service includes trigger stream signaling information.
  • the receiver can identify tap () including the trigger signaling information.
  • the receiver extracts trigger signaling information including an association_tag value from the identified tap () structure, and a stream having a PID whose association_tag_descriptor is among the data elementary streams (ES) listed in the PMT extracted from the broadcast stream matches the extracted association_tag. Receive the trigger stream can be received.
  • the NRT service is signaled through SMT or NST and can be uniquely identified through a 16-bit service identifier (service_id).
  • content items constituting the NRT service may be identified through a content_linkage or content identifier in the NCT or NRT-IT. Therefore, the trigger service can be transmitted together with the NRT service by extending app_id_byte through DST.
  • the app_id_byte may include data obtained by combining a service ID field and a content_linkage field of the trigger service. Accordingly, the first 16 bits of the app_id_byte may correspond to a service ID field in the SMT or NST, and then 32 bits may correspond to a content linkage field in the NCT or NRT-IT.
  • the broadcaster may transmit trigger signaling information to tap () through an application identification structure on the DST.
  • trigger signaling information may be transmitted using the protocol_encapsulation field of the DST.
  • the protocol_encapsulation field For example, if app_id_byte_length in DST is set to 0x0000, no app id is allocated, and when the value of the protocol_encapsulation field is 0x0F, it may indicate that trigger signaling information is included in the corresponding tap () structure. Accordingly, when app_id_byte_length is 0x0000 and the value of the protocol_encapsulation field is 0x0F, the receiver may receive trigger signaling information from the corresponding tap () structure, thereby obtaining a PID value on the PMT indicating the trigger stream as described above A trigger stream can be received.
  • trigger signaling information may be transmitted using a content type descriptor field of a DST.
  • an embodiment of a content type descriptor structure that may be included in tap () on a DST is as follows.
  • the descriptorTag field may have a value of 0x72 for indicating a contentTypeDescriptor.
  • the descriptorLenth field represents the total length of a descriptor (byte unit).
  • the contentTypeByte field represents a MIME media type value of the data referenced by the tap to which this descriptor is connected.
  • MIME media types are defined in 5 of RFC2045 section [8].
  • a content type descriptor may be added to a tap () structure including trigger signaling information. Accordingly, when the app_id_byte_length is 0x0000 and the content type descriptor of the tap () structure matches the preset content, the receiver may receive trigger signaling information from the corresponding tap () structure, which indicates the trigger stream as described above. It is possible to obtain a PID value on the PMT and receive a trigger stream.
  • a MIME media type may be designated as a specific type.
  • one NRT service may be a trigger service for transmitting a trigger stream, and different trigger streams may be transmitted for each content item in the trigger service.
  • each application may include one trigger stream.
  • a trigger stream may be included in each content item of the NRT service and transmitted.
  • the above-described application identification structure can be used.
  • app_id_byte_length is 0x0003
  • each trigger stream may be transmitted corresponding to each NRT service or content item.
  • the method of transmitting trigger signaling information and the method of receiving a trigger stream in a later step are the same as those in which one trigger stream is included per virtual channel, and thus will be omitted.
  • FIG. 29 illustrates an embodiment of a syntax of the PMT and a service identifier descriptor.
  • a program map table indicates information about a program broadcast in each channel.
  • the PMT may receive the PMT by parsing the 'packet ID' through which the PMT is transmitted in a program association table (PAT) in which the 'packet ID' is defined as '0x00'.
  • PAT program association table
  • the service identifier descriptor may be included in a descriptor loop for each elementary stream (ES) of the PMT.
  • the list information of the service included in each program element may be included.
  • the structure of the service identifier descriptor is as follows.
  • the descriptor_tag field is a field for indicating that this descriptor is service_id_descriptor () and may have a value of 0xC2.
  • the descriptor_length field represents the length in bytes from after this field until the end of this descriptor.
  • the service_count field indicates the number of services included in the program element to which the present descriptor is attached.
  • the service_id field represents a service identifier included in a program element to which this descriptor is attached.
  • the trigger stream may be transmitted through a predetermined Well-known IP address.
  • the broadcasting station may transmit a specific service identifier (eg, 0x01) corresponding to the trigger stream in the service identifier descriptor to signal the trigger. That is, trigger signaling information for receiving a trigger stream may be transmitted through a service identifier descriptor. Accordingly, when the service identifier of the service_id_descriptor included in the ES descriptor loop in the ES loop of the PMT is 0x01, the receiver may determine that elementray_PID in the ES loop is a PID indicating the trigger stream, and receives the trigger stream using the PID. can do.
  • a trigger may be signaled using a trigger stream descriptor.
  • the trigger stream descriptor may be included in an ES descriptor loop in the ES loop of the PMT. Therefore, when the trigger stream exists, the trigger stream descriptor may exist in the ES descriptor loop.
  • the receiver may receive the trigger stream by obtaining a PID of the trigger stream from elementray_PID in the corresponding ES loop.
  • the trigger stream descriptor for transmitting trigger signaling information may include at least one of a service identifier (target service id) of a TDO, which is a target of a trigger in the trigger stream, or an IP address list for transmitting the trigger stream.
  • target service id a service identifier of a TDO
  • IP address list for transmitting the trigger stream.
  • the descriptor_tag field represents a trigger stream descriptor (trigger_stream_descriptor) when the value is a preset value.
  • the descriptor_length field represents the length in bytes from after this field until the end of this descriptor.
  • the target_service_count field represents the number of target NRT services (TDOs) of one or more triggers included in a trigger stream.
  • the target_service_id field represents a service identifier (service_id) of a target NRT service (TDO) of one or more triggers included in a trigger stream.
  • the receiver may know the service identifier (service_id) of the target TDO even before receiving the trigger stream by using the target_service_id field.
  • the target_content_item_count field represents the number of target NRT service content items of one or more triggers included in a trigger stream.
  • the target_content_linkage field indicates target NRT service content item linkage (content_linkage) of one or more triggers included in a trigger stream.
  • the trigger stream descriptor is an embodiment, it will be apparent that additional information may be added or configured in other forms. For example, in case of transmitting one trigger stream per virtual channel, the field related to the content item may be omitted. In addition, at least one of a trigger stream identification information field and a profile information field for identifying a trigger stream may be added.
  • the broadcast station may transmit list information of the trigger target NRT service such as TDO by using the above-described trigger stream descriptor.
  • the broadcaster may transmit trigger signaling information using the target_service_id and targe_content_linkage fields.
  • the trigger stream descriptor may further include a list of IP address information or port numbers for transmitting the trigger stream.
  • a broadcast station may transmit trigger signaling information by designating a stream type.
  • the receiver may extract trigger signaling information using the stream type from the PMT, and may receive the trigger stream through this.
  • the trigger stream For example, one of the stream types currently preliminarily set, 0x96 may be designated as the trigger stream.
  • the conventional receiver has no information on the case where the stream type is 0x96, and thus may discard the trigger stream without processing. Therefore, there is an advantage that the compatibility with the receiver of the lower model is guaranteed.
  • a trigger may be transmitted to an application information (AIT) table for transmitting application information in a data broadcast such as a multimedia home platform (MHP) or an advanced common application platform (ACAP).
  • AIT application information
  • MHP multimedia home platform
  • ACAP advanced common application platform
  • Fig. 31 shows an embodiment of such an AIT table.
  • a trigger may be included in a descriptor of the STT and transmitted to refer to a system time table (STT) as a trigger time.
  • STT system time table
  • FIG. 33 is a block diagram schematically illustrating a transmitter for transmitting a TDO and a trigger according to an embodiment of the present invention.
  • a transmitter 200 includes an NRT service transmitter 210, a trigger transmitter 220, a multiplexer 230, and a modulator 240.
  • the NRT service transmitter 210 includes an NRT service (TDO) generator 211 and an NRT service signaling data generator 212.
  • the trigger transmitter 220 includes a trigger generator 221 and trigger signaling data. It is configured to include a generator 222.
  • the NRT service (TDO) generation unit 211 receives data for generating an NRT service from a service provider to generate an NRT service, packetizes the generated NRT service into an IP datagram, and then converts the generated NRT service into an IP packet Packetize The packetized NRT service data is transmitted to the multiplexer 230.
  • the NRT service generation unit 211 transmits metadata including channel information and service_id to transmit the NRT service to the NRT service signaling data generation unit 212.
  • trigger information including a trigger time for triggering the TDO, identification information of the target TDO, and trigger action information is extracted and transmitted to the trigger generator 221.
  • the NRT service signaling data generator 212 generates NRT service signaling data for receiving an NRT service using the received NRT service metadata, packetizes the packet into a transport packet, and then sends the packet to the multiplexer 230. send.
  • the trigger generator 221 generates trigger data by using trigger information of the TDO received from the NRT service (TDO) generator.
  • the generated trigger data is transmitted into a transmission packet and transmitted to the multiplexer 230.
  • the trigger generator 221 transmits metadata for trigger reception, such as a packet identifier (PID) of the transmitted trigger data, to the trigger signaling data generator 222.
  • PID packet identifier
  • the trigger signaling data generator 222 generates trigger signaling data based on the received metadata, and transmits the trigger signaling data to the multiplexer 230 by packetizing the trigger signaling data.
  • the multiplexer 230 multiplexes the received transmission packets for each channel, and transmits the multiplexed signal to the modulator 240.
  • the modulator 240 transmits the multiplexed signal to the outside through a modulation process for transmission.
  • a modulation process for transmission There may be various methods as the modulation method, and the present invention is not limited to the modulation method.
  • 34 is a block diagram schematically illustrating a receiver 300 for receiving a TDO and a trigger according to an embodiment of the present invention.
  • the receiver 300 uses a demodulator 310, a demultiplexer 320, a trigger processor 330, an NRT service processor 340, and a service manager 350.
  • the trigger processor 330 includes a trigger receiver 331 and a trigger signaling data receiver 332.
  • the NRT service processor 340 includes an NRT service (TDO) receiver 341 and an NRT service signaling data receiver. And 342.
  • the demodulator 310 receives the modulated signal from the transmitter 200, demodulates the demodulated signal according to a predetermined demodulation scheme, and transmits the demodulated signal to the demultiplexer 320.
  • the demultiplexer 320 demultiplexes the demodulated signal, restores original transport packets for each channel, and transmits the decoded signal to each receiver of the trigger processor 330 or the NRT service processor 340.
  • the NRT service signaling data receiver 342 extracts the information for receiving the NRT service by receiving and restoring the packetized NRT service signaling data as described above from the demultiplexer 320 and then extracts the information for receiving the NRT service, and then the NRT service (TDO) receiver Send to 341.
  • the NRT service (TDO) receiving unit 341 receives the transmission packets of the NRT service from the demultiplexer 320 by using the information for receiving the NRT service, restores them to NRT service data, and transmits them to the service manager 350. do.
  • the trigger signaling data receiver 332 receives and restores the packetized trigger signaling data as described above from the demultiplexer 320, extracts information for receiving the trigger, and transmits the information to receive the trigger to the trigger receiver 331.
  • the trigger receiver 331 receives the transport packets including the trigger from the demultiplexer 320 using information for receiving the trigger, restores the trigger data, and transmits the trigger data to the service manager 350.
  • the service manager 350 receives at least one of trigger data or NRT service (TDO) data from the trigger processor 330 or the NRT processor 340. In addition, the service manager 350 performs or applies a trigger action to the trigger target TDO at the trigger time so that the trigger action for the TDO is performed.
  • TDO NRT service
  • 35 is a flowchart schematically illustrating a trigger transmission method according to an embodiment of the present invention.
  • the NRT service generator 211 receives NRT service data from the outside or generates NRT service data based on data received from an NRT service provider (S100).
  • the NRT service generator 211 packetizes the generated data into a transport packet.
  • the NRT service generator 211 transmits information for receiving transport packets including the NRT service to the NRT service signaling data generator 212.
  • the NRT service signaling data generation unit 212 generates the NRT service signaling data as described above and packetizes it into a transport packet (S110).
  • the NRT service generator 211 determines whether the generated NRT service is a trigger declarative object, that is, TDO (S120).
  • the NRT service generator 211 transmits trigger information including a trigger time, a trigger action, and target TDO identification information to trigger the target TDO, to the trigger generator 221.
  • the trigger generator 211 generates trigger data using the received trigger information (S130).
  • the generated trigger data is transported into packets and transmitted to the multiplexer.
  • the target service identifier for the target TDO and the trigger action information to be applied to the target service may be inserted into the payload of the packetized stream, that is, PES, and transmitted.
  • the trigger time information may be specified, for example, in the form of PTS or DTS, inserted into the payload or header of the PES, and transmitted.
  • the trigger signaling data generator 222 generates trigger packetization data for identifying and receiving a trigger transmitted by the trigger generator 221, packetizes the packet, and transmits the packet to a multiplexer (S140).
  • the trigger signaling data may include a trigger stream descriptor or a service identifier descriptor inserted in the program map table, and may include a packet identifier of a trigger stream corresponding to each descriptor.
  • the trigger signaling data may include a packet identifier of a trigger stream included in the TAP structure of the DST.
  • the multiplexer 230 multiplexes at least one of the transport packetized NRT service data, NRT service signaling data, trigger data, and trigger signaling data for each transmission channel, and transmits the transmitted packet to the modulator 240.
  • the modulator 240 performs modulation for transmitting the multiplexed signal and transmits the modulated signal to an external receiver or a broadcasting network (S160).
  • 36 is a flowchart schematically illustrating an operation of the receiver 300 according to an embodiment of the present invention.
  • the receiver 300 selects a channel selected by the user or a preset channel (S200).
  • the demodulator 310 demodulates the signal received from the selected channel, and the demultiplexer 320 demultiplexes the demodulated signal for each transmission channel (S210).
  • the NRT service receiver 341 and the NRT service signaling data receiver 342 receive the NRT service data and transmit the received NRT service data to the service manager 350 as described above.
  • the trigger signaling data receiver 332 or the NRT service signaling data receiver 342 checks whether trigger reception is possible (S220).
  • the trigger acknowledgment may use any of the methods described above. That is, the trigger signaling data receiver 332 or the NRT service signaling data receiver 342 checks the PID corresponding to the trigger in the PSIP base PID or the MGT, the method using the tap structure of the DST, the service identifier descriptor or the trigger stream descriptor. It can be determined whether trigger reception is possible using any one of a method using a method, a method using a trigger stream type, and a method using AIT or STT.
  • the trigger signaling data receiver 332 receives a transport packet including the trigger signaling data, restores the trigger signaling data, and transmits the trigger signaling data to the trigger receiver 331 (S230).
  • the trigger receiver 331 extracts trigger data from the received transport packet using the trigger signaling data, and transmits the trigger data to the service manager 350 (S240).
  • the trigger receiving unit 331 may receive the trigger stream using the packet identifier corresponding to the above-described trigger stream descriptor.
  • the trigger receiver 331 may extract trigger information from the trigger stream and transmit the trigger information to the service manager 350.
  • the received trigger stream is a PES
  • the PTS included in the header of the PES may be extracted as the trigger time
  • the target service identifier and the trigger action included in the payload of the PES may be extracted and transmitted to the service manager 350. have.
  • the service manager 350 When the trigger is received, the service manager 350 performs a trigger action on the target TDO at the trigger time, so that the trigger of the TDO is performed (S250).
  • the PTS of the PES when the PTS of the PES is the trigger time, the PTS of the trigger stream may be synchronized with the PTS included in the header of the PES of the audio and video streams so that accurate playback timing can be set.
  • FIG. 37 is a flowchart illustrating a method of receiving using a trigger table in a trigger receiving method according to an embodiment of the present invention.
  • the demodulator 310 receives and demodulates a broadcast signal for the selected channel.
  • the trigger signaling data receiver 332 receives the PSIP table through the demultiplexer 320, and determines whether there is a trigger table among the received tables to identify a trigger service (S310).
  • the trigger signaling data receiving unit 332 may identify a trigger service by searching for a PID allocated to a trigger table in an MGT or PSIP base table or a table corresponding to Table_id assigned to a trigger table.
  • the receiver 300 If the trigger service is not identified, the receiver 300 provides a general broadcast service.
  • the trigger receiving unit 331 receives the searched trigger table and parses the received trigger table (S320 and S330).
  • the service manager 350 receives trigger information including a trigger time parsed from a trigger table, a trigger action, and target TDO identification information, and performs a corresponding trigger action on the corresponding TDO at the corresponding trigger time (S340).
  • 38 is a flowchart illustrating an operation of the receiver 300 when transmitting trigger signaling information and a trigger using a DST according to an embodiment of the present invention.
  • the receiver 300 uses the demodulator 310 and the demultiplexer 320 from the broadcast signal received through the tuned physical transmission channel. Acquire the VCT and PMT (S3010).
  • the PSI / PSIP section handler or trigger signaling data receiver 332 or the NRT service signaling data receiver 342 parses the obtained VCT and PMT and checks whether there is an NRT service.
  • the corresponding virtual channel does not transmit the NRT dedicated service.
  • the receiver 300 since the corresponding virtual channel transmits an existing broadcast service, the receiver 300 performs an appropriate operation according to the information included in the corresponding virtual channel.
  • the corresponding virtual channel may include an NRT service. In this case, it is called an adjunct NRT service included in the corresponding virtual channel, and the receiver 300 may perform the same process as when receiving the NRT service.
  • the NRT service signaling data receiver 342 or the trigger signaling data receiver 332 may determine that the NRT service may be received through the corresponding virtual channel. In this case, if the stream_type field value included in the service location descriptor (or ES loop of PMT) of the VCT is 0x95 (that is, DST transmission), the DST is received using the elementary_PID field value at this time (S3020). This may be performed by the demultiplexer 320 under the control of the service manager 350.
  • the trigger signaling data receiving unit 342 identifies a trigger service from the received DST (S3040).
  • the method for identifying the trigger service may include identifying a specific value assigned to app_id_description and app_id_byte using an application identification structure as described above, identifying a specific value assigned to a protocol_encapsulation field, and content type descriptor. You can use any of the methods to identify the tap that is present.
  • the receiver 300 performs an appropriate operation according to the NRT service included in the virtual channel ( S3030).
  • the trigger signaling data receiver 332 extracts a tap from the DST including trigger signaling information (PID of the trigger stream) (S3060).
  • the trigger signaling data receiving unit 332 extracts a stream PID including the association_tag of the extracted Tap from the PMT (S3070).
  • the trigger receiver 331 receives MPEG-2 TS packets corresponding to the extracted stream PID and decapsulates the TS header, thereby restoring a PES stream including the trigger stream.
  • the stream type (stream_type) of the PES packet including the trigger stream may be 0x06 indicating a synchronized data stream.
  • the trigger receiving unit 331 parses at least one of the PTS of the PES packet header, the target TDO identifier included in the trigger stream, the trigger identifier, or the trigger action information from the recovered PES stream (S3070).
  • the service manager 350 performs the action on the target TDO at the trigger time by using the PTS of the PES packet header including the trigger as the trigger time (S3080).
  • the target TDO may be an NRT service indicated by the parsed target TDO identifier.
  • the action may be any one of a preparation, execution, extension, and termination command indicated by parsed trigger action information.
  • 39 is a flowchart illustrating an operation of a receiver when a trigger is transmitted using a trigger stream descriptor according to an embodiment of the present invention.
  • the receiver 300 uses the demodulator 310 and the demultiplexer 320 from the broadcast signal received through the tuned physical transmission channel. Obtain the VCT and PMT (S4000).
  • the broadcast signal includes a VCT and a PMT, and parses the VCT and PMT obtained by the trigger signaling data receiver 332 or the PSI / PSIP section handler.
  • the trigger signaling data receiver 332 checks whether a trigger is transmitted from the VCT and the PMT to the corresponding virtual channel. To this end, the trigger signaling data receiver 332 determines whether the aforementioned trigger stream descriptor (Trigger_stream_descriptor) exists in the ES descriptor loop of the PMT corresponding to the corresponding virtual channel (S4020). Whether the trigger_stream_descriptor is present is searched for descriptors in the ES descriptor loop, and is determined based on whether the stream_type value is 0x06 corresponding to synchronized data streaming and whether the descriptor_tag field of the descriptor matches the value set to correspond to the trigger stream descriptor. can do.
  • Trigger_stream_descriptor Trigger_stream_descriptor
  • Trigger_stream_descriptor If it is determined in the PMT that Trigger_stream_descriptor is not identified and does not exist, the corresponding virtual channel does not transmit a trigger, and thus the receiver 300 performs an appropriate operation according to a broadcast service included in the corresponding virtual channel (S4025).
  • the trigger signaling data receiver 332 extracts Elementray_PID included in the corresponding ES loop of the PMT (S4030).
  • the extracted stream PID may be a PID value of a stream including a trigger stream.
  • the trigger receiving unit 331 receives MPEG-2 TS packets corresponding to the extracted stream PID to remove the encapsulation, that is, the TS header, and restore the PES stream including the trigger stream.
  • the stream type (stream_type) of the PES packet including the trigger stream may be 0x06 indicating a synchronized data stream.
  • the trigger receiving unit 331 parses at least one of the PTS of the PES packet header, the target TDO identifier included in the trigger stream, the trigger identifier, and the trigger action information from the recovered PES stream (S4040).
  • the service manager 350 performs the action on the target TDO at the trigger time using the PTS of the PES packet header including the trigger as the trigger time (S4050).
  • the target TDO may be an NRT service indicated by the parsed target TDO identifier.
  • the action may be any one of a preparation, execution, extension, and termination command indicated by parsed trigger action information.
  • FIG. 40 is a flowchart illustrating an operation of a receiver when a trigger is transmitted using a stream type according to an embodiment of the present invention.
  • the receiver 300 uses the VCT and PMT using the demodulator 310 and the demultiplexer 320 from the broadcast signal received through the tuned physical transmission channel. Acquire.
  • the broadcast signal includes a VCT and a PMT, and parses the VCT and the PMT from which the trigger signaling data receiver 332 or the PSI / PSIP section handler is obtained (S400).
  • the trigger signaling data receiver 332 checks whether a trigger is transmitted from the VCT and the PMT to the corresponding virtual channel. To this end, the trigger signaling data receiver 332 determines whether there is a specific stream type 0x96 described above in the ES descriptor loop of the PMT corresponding to the corresponding virtual channel (S410).
  • the receiver 300 performs an appropriate operation according to a broadcast service included in the corresponding virtual channel (S415). ).
  • the trigger signaling data receiver 332 extracts Elementray_PID included in the corresponding ES loop of the PMT (S420).
  • the extracted stream PID may be a PID value of a stream including a trigger stream.
  • the trigger receiving unit 331 receives MPEG-2 TS packets corresponding to the extracted stream PID to remove the encapsulation, that is, the TS header, and restore the PES stream including the trigger stream.
  • the trigger receiving unit 331 parses at least one of a PTS of a PES packet header, a target TDO identifier included in a trigger stream, a trigger identifier, and trigger action information from the recovered PES stream (S430).
  • the service manager 350 performs the action on the target TDO at the trigger time using the PTS of the PES packet header including the trigger as the trigger time (S440).
  • the target TDO may be an NRT service indicated by the parsed target TDO identifier.
  • the action may be any one of a preparation, execution, extension, and termination command indicated by parsed trigger action information.
  • 41 is a flowchart illustrating an operation of a receiver when transmitting a trigger using an AIT according to an embodiment of the present invention.
  • the trigger signaling data receiver 332 receives the AIT using the demodulator 310 and the demultiplexer 320 (S500).
  • the trigger signaling data receiver 332 checks whether a trigger is transmitted from the AIT. To this end, the trigger signaling data receiver 332 confirms that a trigger descriptor exists in the AIT (S510).
  • the receiver 300 performs an appropriate operation according to the corresponding application service (S515).
  • the trigger receiver 332 extracts trigger data from the trigger descriptor, parses the extracted trigger data, and transmits the trigger data to the service manager 350 (S530).
  • the service manager 350 performs an action on the target TDO at the trigger time based on the parsed trigger data (S540).
  • the target TDO may be an NRT service indicated by the parsed target TDO identifier.
  • the action may be any one of a preparation, execution, extension, and termination command indicated by parsed trigger action information.
  • FIG. 42 is a flowchart illustrating an operation of a receiver when transmitting a trigger using STT according to an embodiment of the present invention.
  • the trigger signaling data receiver 332 receives the STT using the demodulator 310 and the demultiplexer 320 (S600).
  • the trigger signaling data receiver 332 checks whether a trigger is transmitted from the STT. To this end, the trigger signaling data receiving unit 332 confirms that a trigger descriptor exists in the STT (S610).
  • the receiver 300 If it is determined that the trigger descriptor does not exist, since the corresponding STT does not include a trigger, the receiver 300 performs an appropriate operation according to the broadcast signal (S615).
  • the trigger receiver 332 extracts trigger data from the trigger descriptor, parses the extracted trigger data, and transmits the trigger data to the service manager 350 (S630).
  • the service manager 350 performs an action on the target TDO at the trigger time based on the parsed trigger data (S540).
  • the target TDO may be an NRT service indicated by the parsed target TDO identifier.
  • the action may be any one of a preparation, execution, extension, and termination command indicated by parsed trigger action information.
  • a trigger data transmission pattern according to an embodiment of the present invention will be described with reference to FIGS. 43 and 44.
  • the transmission pattern of the activation triggering data (ATD) will be described.
  • trigger data including a trigger action set to a value corresponding to activation may be activation trigger data.
  • the activation trigger data triggers activation (execution) of an object corresponding to the target service identifier.
  • the transmitter 200 knows when the receiver 300 will change the channel, when the receiver 300 will power on, and when the receiver 300 will select the channel where the corresponding NRT service exists. Therefore, the transmitter 200 may periodically and repeatedly download the download contents transmitted by the NRT method through the terrestrial broadcasting.
  • the transmitter 200 may also periodically transmit activation trigger data.
  • activation trigger data is transmitted in a very short period of time, waste of a transmission band is caused, and since the receiver 300 periodically checks activation trigger data, overhead may occur.
  • the receiver 300 may not activate the received NRT data even though it has received NRT data corresponding to the activation trigger data. Therefore, proper timing of transmission of activation trigger data is required.
  • the activation time T1 represents a time at which activation of the NRT (T1) service is triggered.
  • the valid time Te represents the time when the NRT T1 began to be transmitted last before the activation time T1.
  • the transmission period change time To represents the time at which the period during which the activation trigger data is transmitted is changed.
  • the transmission period change time To is a time parameter that the transmitter 200 can determine.
  • the time window Tp1 represents before the valid time Te.
  • the time window Tp2 represents between the valid time Te and the activation time T1.
  • the time window Tp3 represents between the valid time Te and the transmission period change time To.
  • the time window Tp4 represents between the transmission period change time To and the activation time T1.
  • the receiver 300 In order for the NRT (T1) service to be executed at the activation time T1, the receiver 300 completes reception and storage of the NRT (T1) service before the activation time T1 and generates activation trigger data for the NRT (T1) service. Need to receive To this end, if the receiver 300 tunes a channel transmitting the NRT (T1) service before the valid time Te and maintains the channel until the reception of the NRT (T1) service is completed, the receiver 300 receives the NRT (T1). The service may be stored before the activation time T1. Therefore, even if activation trigger data is transmitted in the time window Tp2, since the receiver 300 cannot receive the NRT (T1) service, transmission of the activation trigger data in the time window Tp2 may be meaningless.
  • the receiver 300 tunes a channel transmitting the NRT (T1) service in the time window Tp1 and completes the reception of the NRT (T1) service and then changes the channel to another channel, the receiver 300 If the channel is changed to a channel for transmitting the NRT (T1) service in the time window Tp2, the receiver 300 may have an NRT (T1) service. Therefore, the transmitter 200 needs to transmit activation trigger data in the time window Tp2.
  • the transmitter 200 may transmit the activation trigger data by distinguishing the time window Tp3 and the time window Tp4 by the transmission period change time To. Prior to the transmission period change time To, since at least the time window Tp4 remains until the NRT (T1) service is executed, the transmitter 200 transmits the activation trigger data in a long period. In this case, the transmitter 200 may transmit activation trigger data with n * Tp4 as a cycle.
  • the transmitter 200 may transmit the activation trigger data in a short period. At this time, the transmitter 200 may transmit the activation trigger data as much as the short period (M).
  • the short period P (Tp4) at this time may be [Tp4 / M]. [] Represents a Gaussian symbol.
  • the short period transmission number M may be designed in consideration of the channel change time of the receiver 300. Therefore, when the receiver 300 changes the channel to the channel providing the NRT (T1) service before the P (Tp4) before the activation time T1, the NRT (T1) service may be normally provided.
  • the receiver 300 enters the channel providing the (T1) service between T1-P (Tp4) and the activation time (T1), the NRT (T1) service cannot be provided normally, but it is only a short time. It is less likely to occur. In this case, this can be compensated by the retention trigger data described later.
  • the valid time Te was earlier than the transmission period change time To, it is not necessarily limited to this. That is, the transmission period change time To may be earlier than the valid time Te.
  • 44 is a flowchart illustrating a method of transmitting activation trigger data according to an embodiment of the present invention.
  • the trigger transmission unit 220 sets the activation time (T1) of the NRT (T1) service, which is the target object (S5101), sets the transmission period change time (To) (S5103), and the number of short period transmissions (M). ) Is set (S5105).
  • the trigger transmitter 220 transmits activation trigger data for the NRT (T1) service in a long period (S5109).
  • the trigger transmitter 220 may transmit the activation trigger data at intervals of n * Tp4.
  • the trigger transmitter 220 activates for the NRT (T1) service in a short period.
  • the trigger data is transmitted (S5113).
  • the trigger transmitter 220 terminates the transmission of activation trigger data for the NRT (T1) service (S5115).
  • the current system time t is compared with the transmission period change time To or the activation time T1 of the NRT (T1) service. Therefore, the time reference of the current system time t, the transmission period change time To, and the activation time T1 of the NRT (T1) service needs to be the same.
  • the current system time t, the transmission period change time To, and the activation time T1 of the NRT (T1) service may all be UTC time. If the activation time T1 of the NRT (T1) service is given as the PTS, since the PTS uses PCR as a reference, the current system time t may correspond to the STC. This may apply to the time comparisons mentioned herein.
  • a trigger data transmission pattern according to another embodiment of the present invention will be described with reference to FIGS. 45 to 47.
  • the transmission pattern of maintenance triggering data (MTD) will be described.
  • the trigger data including the trigger action set to a value corresponding to the hold may be the hold trigger data.
  • the maintenance trigger information may trigger the maintenance of activation of this object. If the object corresponding to the target service identifier of the maintenance trigger data is not yet activated in the receiver 300, the maintenance trigger information may trigger activation of the object.
  • the activation time Ta represents the activation time of the TDO
  • the termination time Tf represents the termination time of the TDO.
  • the additional action time Taction represents the time when another further action for the TDO is triggered (activated) after the activation time Ta and before the end time Tf.
  • the time window Tplife represents between the activation time Ta and the end time Tf, in particular the life time of the TDO.
  • the time window Tp1 represents between the activation time Ta and the additional action time Taction.
  • the time window Tp2 represents between the additional action time Taction and the end time Tf.
  • the receiver 300 When the receiver 300 returns to the A channel after changing the tuning channel from the A channel to the B channel, the receiver 300 needs to redo the previously executed TDO.
  • the NRT content TDO corresponding to the A channel is stored in the receiver 300 in advance and the receiver 300 enters the A channel after the activation time Ta of the TDO, the receiver 300 executes the TDO. There is a need to do it.
  • the transmitter 200 may transmit maintenance trigger data according to an embodiment of the present invention.
  • the receiver 300 may need an MTD in the following cases. That is, when the receiver 300 returns to the A channel again within the time window Tplife after changing the tuning channel from the A channel to the B channel, the receiver 300 may require the MTD. In addition, when the receiver 300 is powered off in the A channel and then powered on to return to the A channel again within the time window Tplife, the receiver 300 may require an MTD. When the receiver 300 returns to the A channel again within the time window Tplife after changing the tuning channel from the A channel to the B channel within the time window Tplife, the receiver 300 may require an MTD. When the receiver 300 is powered off on the A channel within the time window Tplife and then powered on and returned back to the A channel within the time window Tplife, the receiver 300 may require an MTD.
  • the transmitter 200 continuously transmits the MTD within the time window Tplife so that the TDO associated with the MTD can be redone.
  • the transmission period Pmtd of the MTD may be set in consideration of the time taken for power on / off of the receiver 300 and the time when channel change occurs.
  • the transmitter 200 may configure and transmit an MTD having the same form as the ATD within the time window Tp1.
  • the transmitter 200 may configure and transmit an MTD in which a specific additional action is added to the ATD.
  • the transmitter 200 may configure and transmit an MTD having the same form as the trigger data corresponding to the TDO action, or add a specific additional action to the trigger data corresponding to the TDO action.
  • the MTD may be configured and transmitted.
  • 46 is a flowchart illustrating a maintenance trigger data transmission method according to an embodiment of the present invention.
  • the trigger transmitter 220 sets an activation time Ta for the target object TDO (S5201).
  • the trigger transmitter 220 determines a transmission period Pmtd of the MTD for the target object in operation S5203.
  • the transmission period Pmtd of the MTD may be set to a predetermined value.
  • the transmission period Pmtd of the MTD may be set in consideration of the channel change time of the receiver 300 or the time taken for power on / off of the receiver 300.
  • the trigger transmitter 220 does not transmit the MTD for the target object (S5207).
  • the trigger transmitter 220 confirms the change of the trigger data. (S5211).
  • the trigger transmitter 220 transmits the changed trigger data and the maintenance trigger data including the additional action (S5213).
  • the trigger transmitter 220 transmits the maintenance trigger data including the trigger data before the change and the additional action (S5215).
  • the trigger transmitter 220 ends the transmission of the maintenance trigger data (S5217).
  • the trigger receiver 331 of the receiver 300 receives maintenance trigger data (S5301).
  • the reception of the maintenance trigger data may be performed according to the various embodiments described above.
  • the service manager 350 of the receiver 300 maintains the activation of this object (S5305).
  • the service manager 350 of the receiver 300 activates the object (S5307).
  • trigger data reception timing according to an embodiment of the present invention will be described with reference to FIGS. 48 to 50.
  • reception timing of preparation triggering data PTD
  • the trigger data including the trigger action set to a value corresponding to the preparation may be the preparation trigger data.
  • a target service identifier for preparation and a preparation trigger time may be obtained.
  • the preparation trigger data triggers preparation of an object corresponding to the target service identifier.
  • the transmitter 200 may provide preparation trigger data, which is a trigger for the following pre-work, for the TDO requiring pre-work before the activation time.
  • the preparation trigger data may be sent if the task of checking the internet connection and pre-downloading the downloadable content associated with the TDO is required before the activation time.
  • the ready trigger data may be sent. This may correspond to a case in which a lot of data such as photo data used to generate the user interface is required to decode in advance, or a long time when generating the user interface through metadata associated with the TDO. In addition, this may correspond to a case where a download of a web-based TDO is required in advance.
  • the preparation trigger data may be transmitted in order to check a connection possibility with the server in advance or to perform a connection with the server in advance.
  • the above pre-work may have a form combined with each other.
  • the preparation trigger time Tp represents the time when preparation of the TDO is triggered by the PTD.
  • the activation time Ta represents the time at which the TDO is activated, and the end time Tf represents the time at which the TDO is terminated.
  • the time window Tpa represents between the preparation trigger time Tp and the activation time Ta, and the time window Tplife represents between the activation time Ta and the end time Tf.
  • the time window Tpa may vary according to the preliminary work according to the preliminary work.
  • the transmitter 200 may transmit the preparation trigger data having the preparation trigger time set to zero. That is, when the receiver 300 receives the preparation trigger data having the preparation trigger time set to 0, the receiver 300 may immediately start downloading the content.
  • the receiver 300 may not receive a PTD for the TDO requiring the download content for activation or may trigger preparation for the TDO immediately before the activation time Ta. If the download content is required for the activation of the TDO but has not been downloaded, the receiver 300 may not activate the TDO at the activation time Ta or may download the content after activation. If the TDO action contains this information, the receiver 300 may determine the activation of the TDO based on the TDO action.
  • the transmitter 200 may set a preparation trigger time Tp for a TDO requiring UI generation or a network check according to the type of the TDO.
  • the transmitter 200 may continuously transmit the PTD having the trigger time set to Tp even in the time window Tpa).
  • the receiver 300 compares the preparation trigger time Tp) with the current system time, and if the current system time is after the preparation trigger time Tp), the receiver 300 performs PTD to complete preparation of the TDO as soon as possible before the activation time Ta). Start the preparation of the TDO as soon as it is received.
  • 49 is a flowchart illustrating a preparation trigger receiving method according to an embodiment of the present invention.
  • FIG. 49 illustrates a method of processing downloading preparation trigger data.
  • the trigger receiving unit 331 of the receiver 300 receives the preparation trigger data (S5401), parses and stores the received preparation trigger data (S5403).
  • the reception of the preparation trigger data may be performed according to various embodiments of receiving the trigger data described above.
  • the service manager 350 processes the received preparation trigger data as another kind of preparation trigger data (S5407).
  • the service manager 350 checks the Internet connection (S5409).
  • the service manager 350 ignores the received PTD (S5411). In order to reduce the load for continuously processing the downloaded PTD, the service manager 350 may store the received PTD and ignore it. When the TDO associated with the downloading PTD is terminated, the service manager 350 may delete the received PTD.
  • the service manager 350 starts downloading the download content at the trigger time of the received preparation trigger data (S5413).
  • the service manager 350 may activate the TDO corresponding to the target service identifier of the received preparation trigger data in the background so that the activated TDO downloads the download content.
  • the service manager 350 may provide the download manager with the target service identifier and the downloading URL so that the download manager downloads the download content.
  • the activated TDO or download manager stores the download content (S5415). On the other hand, when the download manager has downloaded the content, the download manager stores the download content in association with the target service identifier.
  • 50 is a flowchart illustrating a preparation trigger receiving method according to another embodiment of the present invention.
  • FIG. 50 shows a method of processing a PTD that requires background activation of the TDO to prepare for the TDO.
  • the trigger receiving unit 331 of the receiver 300 receives the preparation trigger data (S5501), parses and stores the received preparation trigger data (S5503).
  • the reception of the preparation trigger data may be performed according to various embodiments of receiving the trigger data described above.
  • the target service identifier and the preparation trigger time may be obtained.
  • the service manager 350 activates the TDO corresponding to the target service identifier of the preparation trigger data in the background (S5507). That is, if the reception time of the PTD is before the preparation trigger time Tp, the service manager 350 activates the TDO in the background when the preparation trigger time Tp is reached. On the other hand, if the reception time of the PTD is after the preparation trigger time Tp, the service manager 350 immediately activates the TDO in the background. At this time, even if the tuning channel of the receiver 300 is changed, the service manager 350 maintains the background state without terminating the TDO.
  • the service manager 350 changes the state of the TDO to the foreground (S5511). In particular, when the receiver 300 returns to the service channel of the TDO between the activation time Ta of the TDO and the end time Tf of the TDO, the service manager 350 changes the state of the TDO to the foreground.
  • the service manager 350 ends the TDO (S5515). In particular, if there are TDOs activated in the background state and not changed to the foreground state, the service manager 350 terminates such TDOs. At this time, the service manager 350 needs to know the end point of the TDO. To this end, the ATD may include an end time point of the corresponding TDO.
  • triggers can be broadly classified into preparation triggers, activation triggers, and maintenance triggers according to their characteristics.
  • the preparation trigger is delivered to the receiver 300 in advance of the activation trigger to pre-preparation for the receiver 300 to perform a preliminary preparation for a function performed through the activation trigger. trigger).
  • the receiver 300 may naturally perform the trigger action at the correct time.
  • An activation trigger is a trigger that instructs a receiver to perform a specific function related to a state change of a TDO, such as executing or terminating a TDO at a specific point in time.
  • a maintenance trigger is a trigger that can provide an instruction or guide on how the receiver 300 handles this trigger when the receiver 300 misses the trigger execution time specified in the activation trigger.
  • the maintenance trigger may have a meaning collectively referred to as a trigger used for life cycle management of the trigger.
  • the receiver 300 completes the preparation necessary for the action indicated by the activation trigger before the triggering time indicated by the activation trigger to perform a natural action at the correct time. Can be.
  • the receiver 300 fails to perform the trigger by entering the corresponding channel immediately before or after the triggering time, the receiver 300 may cope with this through a maintenance trigger. Therefore, the trigger configured as described above may provide a method for achieving optimal trigger performance in various actual viewing environments.
  • 51 illustrates bitstream syntax of a trigger configured according to another embodiment of the present invention.
  • the trigger following the syntax illustrated in FIG. 51 further includes a trigger type field (trigge_type) and a reference target trigger identifier field (target_trigger_id_ref) as compared to the trigger illustrated in FIG. 25.
  • trigge_type a trigger type field
  • target_trigger_id_ref a reference target trigger identifier field
  • the trigger type field indicates the type of trigger. For example, a trigger having a value of the trigger type field of 0x00 may indicate "Reserved for future use”. Triggers having a value of the trigger type field of 0x01, 0x02, and 0x03 may represent a preparation trigger, an activation trigger, and a maintenance trigger, respectively.
  • a scheme other than using the trigger type field may be used to distinguish a ready trigger, an activation trigger, and a maintenance trigger.
  • the trigger data does not have a trigger type field, and the ready trigger, activation trigger, and maintenance trigger may be distinguished through the trigger_action field. That is, if the trigger_action field has a value corresponding to the preparation trigger, the receiver 300 may identify the received trigger as the preparation trigger. In addition, if the trigger_action field has a value corresponding to an activation trigger, the receiver 300 may identify the received trigger as an activation trigger. If the trigger_action field has a value corresponding to a maintenance trigger, the receiver 300 may identify the received trigger as a maintenance trigger.
  • the trigger data may not have a trigger type field, and a trigger_action field value corresponding to a maintenance trigger and a trigger_action field value corresponding to an activation trigger may be the same.
  • the activation trigger may be identified as an activation trigger or a maintenance trigger depending on whether the target TDO is activated. For example, if the target TDO of the received activation trigger is not yet activated, the receiver 300 may identify the received activation trigger as an activation trigger and activate the target TDO at the trigger time specified by the received activation trigger. On the other hand, if the target TDO of the received activation trigger is already activated, the receiver 300 may identify the received activation trigger as a maintenance trigger and maintain activation of the target TDO.
  • the trigger data may not have a trigger type field, and a trigger_action field value corresponding to a maintenance trigger and a trigger_action field value corresponding to an activation trigger may be the same.
  • the activation trigger may be identified as an activation trigger or a maintenance trigger depending on whether the trigger time has elapsed. For example, if the trigger time of the received activation trigger has not yet reached, the receiver 300 may identify the received activation trigger as an activation trigger and activate the target TDO at the trigger time specified by the received activation trigger. On the other hand, if the trigger time of the received activation trigger has already reached, the receiver 300 may identify the received activation trigger as a maintenance trigger. At this time, if the target TDO of the trigger is not yet activated, the receiver 300 may immediately activate the target TDO. If the target TDO of the received activation trigger is already activated, the receiver 300 may maintain activation of the target TDO.
  • the reference target trigger identifier field may indicate a trigger identifier (trigger_id) of an activation trigger associated with the preparation trigger or maintenance trigger.
  • the trigger including the reference target trigger identifier field (target_trigger_id_ref) is an activation trigger
  • the reference target trigger identifier field may indicate a trigger identifier (trigger_id) of a preparation trigger or a maintenance trigger.
  • the receiver 300 may refer to the activation trigger when processing the preparation trigger or the maintenance trigger.
  • the receiver 300 may refer to a preparation trigger or a maintenance trigger when processing an activation trigger. In this way, all of the metadata required or used to actually perform the trigger need not be included in the active trigger, but may be distributedly distributed through the preparation trigger. This allows the stream for activation triggers to be kept as compact as possible.
  • the receiver 300 may recognize another trigger associated with one trigger through the reference target trigger identifier field.
  • the receiver 300 may recognize another trigger associated with one trigger through the trigger id having the same value. For example, since the receiver 300 may identify the type of the trigger received through the trigger type field, the receiver 300 may recognize the ready trigger associated with the activation trigger through the trigger id of each trigger.
  • trigger action field in the preparation trigger according to an embodiment of the present invention.
  • a preparation trigger having a value of the trigger action field of 0x00 may indicate "reserved for future use”.
  • a preparation trigger having a value of the trigger action field of 0x01 may instruct the receiver 300 to prepare a content item for an activation trigger in advance.
  • the preparation may indicate a download.
  • the receiver 300 may pre-download the content item designated by the preparation trigger.
  • This content item may be obtained through a broadcasting network or may be received through an IP network.
  • the content to be downloaded in advance may be designated by the service identifier field and the content linkage field of the preparation trigger.
  • the list of contents to be downloaded in advance may be specified by the SMT and the NRT-IT, or may be specified by a descriptor in a trigger.
  • the location information of the content to be downloaded in advance may be specified by the SMT, the NRT-IT, and the FDT, or may be specified by a descriptor in a trigger. The specific method will be described later.
  • the preparation trigger having a value of the trigger action field of 0x02 may instruct the receiver 300 to preload the content item for the activation trigger.
  • the receiver 300 may recognize that an execution time of a trigger action indicated by the activation trigger is imminent and may load a necessary content item in advance.
  • the content to be loaded in advance may be designated by the service identifier field and the content linkage field of the preparation trigger.
  • the list of contents to be loaded in advance may be specified by the SMT and the NRT-IT, or may be specified by a descriptor in a trigger.
  • the information of the content to be loaded in advance may be specified by the SMT, the NRT-IT, and the FDT, or may be specified by a descriptor in a trigger. The specific method will be described later.
  • the preparation trigger having a value of the trigger action field of 0x03 may instruct the receiver 300 to preset the connection with the server.
  • the receiver 300 may preset the connection with the server designated by the preparation trigger.
  • the address of the server to connect to may be specified through an internet location descriptor in the trigger.
  • trigger action field in an activation trigger according to an embodiment of the present invention.
  • An activation trigger having a value of the trigger action field of 0x00 may indicate "reserved for future use”.
  • the activation trigger having a value of the trigger action field of 0x01 may instruct the receiver 300 to execute a target TDO of the activation trigger.
  • the receiver 300 may immediately execute the target TDO upon receiving an activation trigger having a value of the trigger action field of 0x00.
  • the receiver 300 indicates to the user that the target TDO can be executed upon receiving an activation trigger having a value of the trigger action field of 0x00, and receives a target TDO execution command from the user. You can run
  • the activation trigger having a value of the trigger action field of 0x02 may instruct the receiver 300 to terminate the target TDO of the activation trigger.
  • the receiver 300 may return a resource while terminating the target TDO according to the implementation of the receiver, or may not return a resource. If no resources are returned, rerunning within a short period can speed up execution.
  • the activation trigger having a value of the trigger action field of 0x03 may instruct the receiver 300 to inform the user that the target TDO of the activation trigger can be executed.
  • the receiver 300 may perform such a guide only once or may periodically guide it with a period such as 5 minutes.
  • the activation trigger having a value of the trigger action field of 0x04 may instruct the receiver 300 to suspend the target TDO of the activation trigger.
  • the receiver 300 may stop the operation of the target TDO and leave the target TDO in a standby state.
  • the receiver 300 may hide all of the UI of the target TDO. Suspend is different from terminate, and a TDO suspended by a separate trigger or user command may be executed again or terminated.
  • the activation trigger with a value of the trigger action field of 0x05 may instruct the receiver 300 to wake up the suspended target TDO specified by the activation trigger.
  • the trigger instructing to wake up the stopped target TDO may be the same as the trigger instructing to execute the target TDO.
  • the activation trigger having a value of the trigger action field of 0x06 may instruct the receiver 300 to hide the target TDO of the activation trigger.
  • the receiver 300 receives an activation trigger having a value of the trigger action field of 0x06, the receiver 300 hides from the screen while maintaining the operation of the target TDO.
  • the activation trigger having a value of the trigger action field of 0x07 may instruct the receiver 300 to show the target TDO of the activation trigger.
  • the receiver 300 receives an activation trigger having a value of the trigger action field of 0x07, the receiver 300 keeps the operation of the target TDO to be displayed on the screen.
  • the receiver 300 informs the user that when performing the action specified by the preparation trigger, activation (execution, abort, termination, target TDO of the target TDO specified by the preparation trigger may be performed.
  • activation execution, abort, termination, target TDO of the target TDO specified by the preparation trigger
  • the necessary information for the notification, wake up, display the target TDO, etc. can be obtained from the received NRT-IT and the activation information can be stored in local memory along with the target TDO while saving the target TDO.
  • the receiver 300 may obtain information for activation of the target TDO from the received NRT-IT and store the activation information in the local memory together with the target TDO.
  • Receiving the activation trigger the receiver 300 may obtain activation information for the target TDO designated by the activation trigger from the local memory and activate the target TDO designated by the activation trigger with reference to the activation information.
  • the receiver 300 receiving an activation trigger is obtained from an NRT-IT that has received information for activation of a target TDO, and refers to the target TDO designated by the activation trigger with reference to the activation information. Can be activated.
  • trigger action field in the maintenance trigger according to an embodiment of the present invention.
  • a maintenance trigger having a value of the trigger action field of 0x00 may indicate "reserved for future use”.
  • the maintenance trigger having the value of the trigger action field of 0x01 may instruct the receiver 300 to immediately execute the target TDO of the maintenance trigger.
  • the receiver 300 may immediately execute the target TDO if the target TDO is not executed when the maintenance trigger having the value of the trigger action field is 0x01, and maintain the execution of the target TDO if the target TDO has already been executed. .
  • the receiver 300 may immediately indicate to the user that the target TDO can be executed, and execute the target TDO with an additional condition of receiving the target TDO execution command from the user. If the TDO can be used continuously within a certain time window, this action allows the TDO to be executed and used immediately.
  • the maintenance trigger having a value of the trigger action field of 0x02 may instruct the receiver 300 to be ready to launch the target TDO of the maintenance trigger.
  • the preparation of the target TDO is performed immediately if the preparation of the target TDO has not yet been performed, and the preparation of the target TDO is performed if the target TDO has already been performed. You can stay ready.
  • the maintenance trigger having a value of the trigger action field of 0x03 may indicate to the user that the receiver 300 notifies the user that the target TDO of the maintenance trigger can be executed.
  • the receiver 300 receives the maintenance trigger having the value of the trigger action field of 0x03, the receiver 300 immediately notifies the user that the target TDO can be executed if the user has not yet informed the target TDO can be executed, and indicates that the target TDO can be executed. Keep a notification that you can run the target TDO if you have already informed the user.
  • the receiver 300 may perform such guidance only once, or may periodically guide with a period such as 5 minutes.
  • the maintenance trigger having the value of the trigger action field of 0x04 may instruct the receiver 300 to return all resources related to the target TDO of the maintenance trigger.
  • the receiver 300 receives a hold trigger having a value of 0x04 in the trigger action field, the receiver 300 immediately returns the resource if all resources related to the target TDO of the hold trigger have not been returned yet, and the return of the resource is already performed. Maintain the return of the resource, if performed. In this way, if the designated TDO is not scheduled to be used for a while, this trigger causes the receiver to return all of the resources being used for the specified TDO so that other TDOs, etc. to be used later, are not impeded. If the corresponding TDO is running, the receiver 300 may terminate the target TDO and return a resource.
  • the maintenance trigger having a value of the trigger action field of 0x05 may instruct the receiver 300 to immediately terminate the target TDO of the maintenance trigger.
  • the receiver 300 may immediately terminate the target TDO when the target TDO is not terminated when the maintenance trigger having the value of the trigger action field is 0x05, and maintain the termination of the target TDO when the target TDO is already terminated.
  • the receiver 300 may return a resource while terminating the target TDO according to the implementation of the receiver, or may not return the resource. If no resources are returned, rerunning within a short period can speed up execution.
  • the retention trigger with a value of the trigger action field of 0x06 may instruct the receiver 300 to ignore the trigger specified by the retention trigger.
  • the maintenance trigger having a value of the trigger action field of 0x07 may instruct the receiver 300 to continue execution of the target TDO of the maintenance trigger.
  • the receiver 300 may maintain execution of the target TDO if the target TDO has already been executed and not execute the target TDO if the target TDO is not executed. have.
  • the receiver 300 maintains the target TDO specified by the preparation trigger (immediately execute, prepare, and execute the target TDO when performing the action specified by the preparation trigger, a resource).
  • the necessary information for return, exit, ignore, continue execution, etc. can be obtained from the received NRT-IT and the maintenance information can be stored in local memory with this target TDO while saving the target TDO.
  • the receiver 300 may obtain information for maintaining the target TDO from the received NRT-IT and store the maintenance information in the local memory together with the target TDO.
  • the receiver 300 may obtain maintenance information for the target TDO designated by the maintenance trigger from the local memory, and maintain the target TDO designated by the maintenance trigger with reference to the maintenance information.
  • the receiver 300 receiving the maintenance trigger is obtained from the NRT-IT receiving the information for maintenance of the target TDO, and with reference to this maintenance information, the target TDO specified by the maintenance trigger. Can be maintained.
  • the timing of delivery of the ready trigger can be significantly ahead of the timing of delivery of the activation trigger.
  • the ready trigger may provide approximate time information for future triggering points. Therefore, it may be considered that the time information of the preparation trigger is set to UTC time rather than referring to the PCR.
  • the trigger time of the preparation trigger may indicate any one of a start time, an end time, and a scheduled activation time.
  • the trigger time of the preparation trigger may indicate the start time of the action of the preparation trigger.
  • the trigger time may indicate the start time of the download.
  • the trigger time of the preparation trigger may indicate a deadline time at which the action of the preparation trigger should end.
  • the activation trigger associated with the preparation trigger may be normally processed until the action of the preparation trigger ends until the trigger time of the preparation trigger. Therefore, the receiver 300 starts the action of the preparation trigger so that the action of the preparation trigger can be terminated before the trigger time of the preparation trigger.
  • the trigger time of the preparation trigger may indicate a scheduled activation time. That is, the transmitter 200 may provide the receiver 300 with a predetermined approximate triggering time point of the activation trigger associated with the preparation trigger. In this case, the actual correct timing can be provided through the trigger time of the activation trigger.
  • the trigger time of the preparation trigger may indicate a time window of the preparation action to ensure timely activation of the target TDO specified by the preparation trigger, rather than providing an exact time of execution of the action of the preparation trigger.
  • the receiver 300 may immediately perform the preparation trigger.
  • the maintenance trigger may be delivered after the triggering time of the activation trigger. Since the retention trigger can be seen as providing a treatment for the trigger, the trigger time of the retention trigger may require a lower timing accuracy than the trigger time of the activation trigger. Therefore, it may be considered that the time information of the maintenance trigger is set to UTC time rather than referring to the PCR.
  • the trigger time of the maintenance trigger may indicate any one of a start time and an end time.
  • the trigger time of the maintenance trigger may indicate the time at which the action of the maintenance trigger can start. If the current system time is after the trigger time of the received hold trigger, the receiver 300 may immediately perform the action of the hold trigger. If a trigger time such as a start time is not specified in the maintenance trigger, the receiver 300 recognizes that the execution time has already passed and can immediately execute the action of the maintenance trigger.
  • the trigger time of the maintenance trigger may indicate an end time when the performance of the maintenance trigger is valid. In this case, if the current system time is after the trigger time of the received hold trigger, the trigger is invalid and the receiver 300 should not perform the designated action. If the end time is not specified, the receiver 300 may consider that the valid time of the trigger is designated as infinity.
  • the trigger time of the maintenance trigger may designate a time window in which an action of the maintenance trigger may be performed.
  • the following describes a content item designation method for a preparation trigger and an activation trigger according to various embodiments of the present disclosure.
  • the transmitter 200 may designate a content item for a preparation trigger and an activation trigger as an identifier for identifying a target TDO of the trigger.
  • the identifier for identifying the target TDO of the trigger may correspond to a combination of the service_id_ref field and the content_linkage field.
  • the transmitter 200 may provide the location information of the content item designated by the TDO identifier through the SMT, the NRT-IT, and the FDT.
  • the transmitter 200 provides information on a service channel corresponding to a service_id_ref field in a trigger through SMT. Information about this signaling channel may be provided through information on a destination address and a destination port in the SMT.
  • the transmitter 200 provides a list of content items belonging to a service corresponding to the service_id_ref field through the NRT-IT. The list of content items may be provided via a list of content_linkages in the NRT-IT.
  • the transmitter 200 provides an FDT including information on one or more files for each content item through a service channel corresponding to a service_id_ref field in a trigger. Information about each file may include TOI and Content-Location fields.
  • the transmitter 200 may designate a list of content items for a preparation trigger and an activation trigger in the form of a descriptor.
  • This content item descriptor may be included in the trigger_descriptor () field of the trigger.
  • the transmitter 200 may specify a list of content items for the preparation trigger and the activation trigger through the content item descriptor together with the target TDO identifier. Instead, the transmitter 200 may specify only the content item descriptor instead of the target TDO identifier. . An example of such a descriptor is described with reference to FIG. 52.
  • the content item descriptor includes a descriptor tag field (descriptor_tag), a descriptor length field (descriptor_length), a service count field (service_count), a service identifier field (service_id), a content item count field (content_item_count), and a content linkage. Contains a field (content_linkage).
  • the descriptor tag field descriptor_tag may be an 8-bit unsigned integer for distinguishing this descriptor as a content item descriptor.
  • the descriptor length field descriptor_length may be an 8-bit unsigned integer that defines the length from the field immediately following this field to the end of the content item descriptor.
  • the service count field indicates the number of services included in the content item descriptor.
  • the service identifier field indicates an identifier of a service included in the content item descriptor. Therefore, the content item descriptor may include a plurality of service identifier fields corresponding to the number corresponding to the service count field.
  • the content item count field content_item_count indicates the number of content items for a service corresponding to the service identifier field service_id.
  • the content linkage field (content_linkage) indicates an identifier of a content item. Accordingly, the content item descriptor may include as many content linkage fields as the number corresponding to the content item count field with respect to each service.
  • Such a method may be used when a content item used in a trigger is transmitted in an NRT form, and each content item may be uniquely identified by a combination of an NRT service ID and a content linkage value.
  • the transmitter 200 may provide the location information of the content item designated by the TDO identifier through the SMT, the NRT-IT, and the FDT.
  • the transmitter 200 may designate a list of content items for a preparation trigger and an activation trigger in the form of a descriptor.
  • the transmitter 200 may designate contents transmitted through a broadcasting network and an IP network as a content item for triggering using the internet location descriptor. This internet location descriptor may be included in the trigger_descriptor () field of the trigger.
  • the transmitter 200 may designate a list of content items for a preparation trigger and an activation trigger through an internet location descriptor together with a target TDO identifier, or only through an internet location descriptor instead of a target TDO identifier. .
  • An example of such an internet location descriptor will be described with reference to FIG. 53.
  • 53 shows the syntax of an internet location descriptor according to an embodiment of the present invention.
  • the Internet location descriptor includes a descriptor tag field (descriptor_tag), a descriptor length field (descriptor_length), a URL count field (URL_count), a URL length field (URL_length), and a URL () field.
  • descriptor tag field descriptor_tag may be an 8-bit unsigned integer to distinguish this descriptor as an internet location descriptor. For example, this field may have a value of 0xC9.
  • the descriptor length field descriptor_length may be an 8-bit unsigned integer that defines the length from the field immediately following this field to the end of the internet location descriptor.
  • the URL count field URL_count may be a 5-bit unsigned integer representing the number of pairs of URL length fields and URL fields included in the Internet location descriptor. That is, the internet location descriptor includes a plurality of URL length fields corresponding to the number of URL count fields and a plurality of URL fields corresponding to the number of URL count fields.
  • the URL length field URL_length is an 8-bit unsigned integer that indicates the length of the URL () field immediately following this field.
  • the URL () field is a character string representing a Uniform Reference Locator (URL). If the URL () field indicates a relative URL or absolute tag URI, the URL may be viewed as content transmitted only through FLUTE of NRT. In other cases, the URL may be viewed as content transmitted through a broadcast network, as content transmitted through an IP network, or as content transmitted through both a broadcast network and an IP network.
  • URL Uniform Reference Locator
  • FIG. 54 is a flowchart illustrating a trigger transmission method according to another embodiment of the present invention.
  • the transmitter 200 transmits the preparation trigger at the transmission timing of the preparation trigger (S6001) (S6003), transmits the activation trigger at the transmission timing of the activation trigger (S6005) (S6007), and at the transmission timing of the holding trigger (S6009).
  • the maintenance trigger is transmitted (S6011).
  • Triggers can be sent via PSIP tables or synchronized data streams.
  • Trigger transmission through the PSIP table can be seen through FIGS. 37, 41, and 42.
  • the trigger may be delivered by being included in a stream of 0x1FF, which is a PSIP Base PID.
  • the table ID of the trigger table may be uniquely assigned to distinguish it from other tables.
  • the trigger may be delivered through a stream corresponding to a PID assigned and identified through a Master Guide Table. In this case, all tables in the stream can be considered as trigger tables.
  • Trigger transmission based on a synchronized data stream can be seen through FIGS. 38, 39, and 40. Since the synchronized data stream provides accurate synchronization with other streams through the PTS, trigger transmission based on the synchronized data stream may provide higher timing accuracy than trigger transmission through the PSIP table.
  • the preparation trigger, activation trigger and maintenance trigger may be included and delivered in one stream.
  • the transmitter 200 may transmit a preparation trigger through a PSIP table and transmit an activation trigger and a maintenance trigger through a synchronized data stream.
  • the preparation trigger may be provided a considerable time before the time at which the activation trigger should be performed.
  • the time point at which the preparation trigger is provided may be several hours before or several days or weeks before the time at which the activation trigger should be performed.
  • the preparation trigger may be necessary so that the receiver 300 may pre-download the content item related to the activation trigger in advance through a broadcasting network or an IP network. Due to the characteristics of the preparation trigger, unlike the activation trigger, the preparation trigger may not require timing accuracy in a scene unit.
  • the transmitter 200 may separately transmit the preparation trigger to a separate table through the existing PSIP signaling stream.
  • the table containing the preparation trigger may be delivered through the PSIP stream including only the preparation trigger, and a separate table id may be assigned to the preparation trigger.
  • the transmitter 200 may transmit a preparation trigger and a maintenance trigger in the form of a PSIP table, and may transmit an activation trigger based on synchronized data streaming. Since the maintenance trigger plays a role of instructing or guiding a receiver 300 that misses a trigger time corresponding to the trigger, it may not be required to be performed accurately at a specific time. Thus, the retention trigger may require a lower timing accuracy than the activation trigger. Therefore, a method of transmitting a maintenance trigger together with a preparation trigger separately from an activation trigger may be considered. In this case, the transmitter 200 may bundle and prepare the preparation trigger and the maintenance trigger in one table. In addition, the transmitter 200 may allocate different table IDs to the table for the preparation trigger and the table for the maintenance trigger, and transmit the preparation trigger and the maintenance trigger through two separate tables.
  • 55 is a flowchart illustrating a method of operating a receiver according to an embodiment of the present invention.
  • the receiver 300 receives a trigger (S6101).
  • the receiver 300 may receive a trigger in a manner as shown in FIGS. 36 to 42.
  • the receiver 300 checks the type of the received trigger (S6103).
  • the receiver 300 may check the type of the received trigger in the manner described above. For example, the receiver 300 may determine the type of trigger through one or more of a trigger type field (trigge_type) and a trigger action field (trigger_action) in the trigger. In addition, the receiver 300 may check the type of trigger depending on whether the target TDO is activated or whether the trigger time has elapsed.
  • the receiver 300 processes the received ready trigger (S6107).
  • the processing of the preparation trigger of the receiver 300 has been described with reference to the trigger action field of the preparation trigger.
  • the state of the TDO may change through the processing of the preparation trigger.
  • the receiver 300 identifies the location information of the content item through the SMT, the NRT-IT, and the FDT.
  • the content item can be downloaded via.
  • the receiver 200 may obtain channel information corresponding to a service identifier in the preparation trigger from the SMT.
  • the channel information may include an IP address and a port number.
  • the receiver 200 may obtain a list of content linkages belonging to the service corresponding to the service identifier in the preparation trigger from the NRT_IT.
  • the receiver 200 may recognize the content linkage field in the trigger or the content linkage field in the content_items_descriptor () field in the trigger or the plurality of content_linkage fields corresponding to the service identifier in the NRT_IT as an identifier of a content item to be downloaded.
  • the receiver 200 may recognize content locations corresponding to content identifiers in the NRT_IT or content identifiers in the trigger from the FLUTE FDT received through the IP address and the port number of the SMT. If the NRT_IT has internet location information of the content item, the receiver 200 may also grasp the location information of the content item through the NRT_IT.
  • the receiver 300 identifies the location information of the content item to download from the Internet location descriptor in the preparation trigger, and identifies the content item through the determined location information. You can download it.
  • the receiver 300 processes the received activation trigger (S6111).
  • the processing of the activation trigger of the receiver 300 has been described with reference to the trigger action field of the activation trigger.
  • the state of the TDO may change.
  • the receiver 300 processes the received maintenance trigger (S6115).
  • 57 is a TDO state transition diagram illustrating how a receiver processes a trigger according to an embodiment of the present invention.
  • the target TDO may be in a released state ST110 such as a non-ready state, a ready state ST120, and an active state ( ST130), either in a suspended state ST140.
  • a released state ST110 such as a non-ready state, a ready state ST120, and an active state ( ST130), either in a suspended state ST140.
  • the receiver 300 If the receiver 300 receives the preparation trigger and the target TDO of the preparation trigger is in the released state (ST110), the receiver 300 prepares the target TDO and places the state of the target TDO in the preparation state (ST120) (S6201). ).
  • the receiver 300 If the receiver 300 receives an end trigger having a value of the trigger action field of 0x02 and the target TDO of this end trigger is in the ready state (ST120), the receiver 300 terminates this target TDO to release the state of the target TDO. Leave it to the state ST110 (S6203).
  • the receiver 300 If the receiver 300 receives an execution trigger with a value of 0x01 in the trigger action field and the target TDO of this execution trigger is in the ready state (ST120), the receiver 300 executes this target TDO to activate the state of the target TDO. Leave it to the state ST130 (S6205).
  • the receiver 300 If the receiver 300 receives a hold trigger with a value of the trigger action field of 0x01 and the target TDO of this hold trigger is in the active state ST120, the receiver 300 sets the state of this target TDO to the active state ST130. Hold (S6206).
  • the receiver 300 If the receiver 300 receives an interrupt trigger with a value of 0x04 in the trigger action field and the target TDO of this interrupt trigger is in the active state (ST130), the receiver 300 interrupts the target TDO by stopping the target TDO. Leave it to the state ST140 (S6207).
  • the receiver 300 If the receiver 300 receives a separate trigger, such as a wake up trigger or an execution trigger, and the target TDO of this separate trigger is in the suspended state (ST140), the receiver 300 executes the target TDO again to execute the target TDO.
  • the state is left as the active state ST130 (S6209).
  • the receiver 300 receives an end trigger having a value of the trigger action field of 0x02 and the target TDO of this end trigger is in the interrupted state (ST140), the receiver 300 terminates this target TDO to release the state of the target TDO. It is placed in the state ST110 (S6211).
  • the receiver 300 may terminate the target TDO and leave the state of the target TDO in the released state (ST110).
  • the receiver 300 If the receiver 300 receives an execution trigger having a value of the trigger action field of 0x01 and the target TDO of this execution trigger is in the released state (ST110), the receiver 300 executes this target TDO to activate the state of the target TDO. It puts in the state ST130 (S6213).
  • the receiver 300 receives an end trigger having a value of the trigger action field of 0x02 and the target TDO of this end trigger is in the active state ST130, the receiver 300 terminates this target TDO to release the state of the target TDO. It is placed in the state ST110 (S6215).
  • the above-described trigger reception method and transmission method according to the present invention may be stored in a computer-readable recording medium that is produced as a program for execution on a computer, and examples of the computer-readable recording medium include ROM, RAM, CD. ROMs, magnetic tapes, floppy disks, optical data storage devices, and the like, as well as those implemented in the form of carrier waves (eg, transmission over the Internet).
  • the computer readable recording medium can be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion. And functional programs, codes and code segments for implementing the method can be easily deduced by programmers in the art to which the present invention belongs.

Abstract

방송 수신기는 패킷화된 스트림을 수신한다. 방송 수신기는 패킷화된 스트림의 헤더로부터 표시 시간 정보를 추출하고, 패킷화된 스트림의 페이로드로부터 타겟 오브젝트 식별자를 포함하는 트리거 정보를 추출한다. 방송 수신기는 트리거 정보의 종류를 인식한다. 트리거 정보가 준비 트리거인 경우에, 방송 수신기는 타겟 오브젝트 식별자에 속한 파일의 위치 정보를 획득한다. 방송 수신기는 획득한 위치 정보를 통해 추출한 표시 시간 정보에 해당하는 시간에서 타겟 오브젝트 식별자에 속한 파일을 다운로드한다.

Description

방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
본 발명은 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치에 관한 것이다.
디지털 텔레비전(DTV)은 텔레비전(TV)의 고유 기능인 영상, 음성과 더불어 다양한 서비스를 제공할 수 있게 되었다. 예를 들어 방송 정보(Electronic Program Guide: EPG) 등을 사용자에게 제공할 수 있고, 2개 이상의 채널로부터 수신되는 방송 서비스를 동시에 제공할 수 있다. 특히 수신 시스템이 대용량의 저장 장치를 구비하고, 양방향 통신이 가능한 인터넷이나 데이터 통신 채널과 연결되면서 방송 신호를 이용하여 제공할 수 있는 서비스는 상당히 많아졌다. 또한, 이와 같이 방송 신호를 이용한 서비스가 다양해짐에 따라 방송 신호를 이용한 서비스들을 정확하게 구동할 필요성이 증대되었다.
본 발명의 목적은, 비실시간 서비스를 수신하여 처리하는 방법 및 비실시간 서비스 전송 방법을 제공함에 있다.
또한, 비실시간 서비스를 통해 다운로드된 컨텐츠를 실시간 방송 서비스와 연동하는 방법 및 그 수신 장치를 제공함에 있다.
본 발명의 다른 목적은 기존의 수신기에 영향을 주지 않으면서도 비실시간 서비스와 실시간 방송 서비스를 연동하기 위한 전송 방법 및 그 수신 장치를 제공함에 있다.
본 발명의 한 실시예에 따른 방송 수신 장치의 방송 수신 방법은 제1 패킷화된 스트림을 수신하는 단계; 상기 제1 패킷화된 스트림의 헤더로부터 표시 시간 정보를 추출하는 단계; 상기 제1 패킷화된 스트림의 페이로드로부터 타겟 오브젝트 식별자를 포함하는 트리거 정보를 추출하는 단계; 상기 트리거 정보의 종류를 인식하는 단계; 상기 트리거 정보가 준비 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 해제 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 준비하여 상기 오브젝트의 상태를 준비 상태로 천이시키는 단계; 상기 트리거 정보가 실행 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 준비 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 실행하여 상기 오브젝트의 상태를 활동 상태로 천이시키는 단계; 및 상기 트리거 정보가 중단 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 활동 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 중단하여 상기 오브젝트의 상태를 중단 상태로 천이시키는 단계를 포함한다.
본 발명의 또 다른 실시예에 따른 방송 서비스 수신 장치는 제1 패킷화된 스트림을 수신하는 수신부; 상기 제1 패킷화된 스트림의 헤더로부터 표시 시간 정보를 추출하고, 상기 제1 패킷화된 스트림의 페이로드로부터 타겟 오브젝트 식별자 필드와 트리거 액션 필드를 포함하는 트리거 정보를 추출하는 트리거 처리부; 및 상기 제1 패킷화된 스트림의 헤더로부터 상기 표시 시간 정보가 추출되지 않으면, 상기 상기 타겟 오브젝트 식별자 필드에 해당하는 오브젝트에 관하여 상기 트리거 액션 필드에 해당하는 액션을 즉시 수행하는 서비스 매니저를 포함한다.
본 발명의 또 다른 실시예에 따른 방송 서비스 수신 장치는 제1 패킷화된 스트림을 수신하는 단계; 상기 제1 패킷화된 스트림의 헤더로부터 표시 시간 정보를 추출하는 단계; 상기 제1 패킷화된 스트림의 페이로드로부터 타겟 오브젝트 식별자를 포함하는 트리거 정보를 추출하는 단계; 상기 트리거 정보의 종류를 인식하는 단계; 상기 트리거 정보가 준비 트리거인 경우에, 상기 타겟 오브젝트 식별자에 속한 파일의 위치 정보를 획득하는 단계; 및 현재 시간이 상기 표시 시간 정보에 도달하면, 상기 위치 정보를 통해 상기 타겟 오브젝트 식별자에 속한 파일을 다운로드하는 단계를 포함한다.
본 발명의 일 실시예에 따르면, 비실시간 서비스를 통해 다운로드된 컨텐츠와 실시간 방송 서비스가 연계될 수 있다.
또한 본 발명의 일 실시예에 따르면, 기존의 수신기에 영향을 주지 않으면서도 비실시간 서비스와 실시간 방송 서비스를 연계할 수 있다.
그리고, 본 발명의 일 실시예에 따르면, 방송 서비스를 정확한 타이밍에 제공할 수 있다.
도 1은 RT 서비스와 NRT 서비스를 제공하는 개념을 나타내는 도면이다.
도 2는 본 발명의 일 실시예에 따른 NRT 서비스의 구조를 설명하기 위한 도면이다.
도 3은 본 발명의 일 실시예에 따라 구성한 NRT 서비스에 대한 프로토콜 스택을 도시한 것이다.
도 4는 본 발명의 다른 일 실시예에 따라 구성한 NRT 서비스에 대한 프로토콜 스택을 도시한 것이다.
도 5는 본 발명의 일 실시 예에 따라 구성한 TVCT 테이블 섹션(VCT)의 비트스트림 섹션을 도시한 것이다.
도 6과 도 7은 본 발명의 실시예에 따른 service_type 필드의 값을 정의한 예를 나타낸 도면이다.
도 8은 NRT 서비스의 어플리케이션을 식별하기 위한 DST 테이블 섹션(data_service_table_section) 및 DST 섹션에 포함된 data_service_table_bytes의 비트스트림 신택스를 도시한 것이다.
도 9는 본 발명에 따른 수신 시스템에서, 데이터 방송 스트림을 전달하기 위한 ATSC A/90 규격과 IP 멀티캐스트 스트림(Multicast stream)을 전송하는 ATSC A/92 규격을 활용하여 NRT 서비스를 수신하여 서비스하는 방법을 설명하기 위한 도면이다.
도 10 및 도 11은 본 발명의 다른 일 실시예에 따라 DSM-CC 어드레서블 섹션 데이터를 이용하여 NRT 서비스를 수신하는 방법을 설명하기 위한 도면이다.
도 11에서는 다른 일 실시예로서, VCT를 이용하여 DSM-CC 어드레서블 섹션 데이터를 시그널링 하는 방법을 나타낸다.
도 12 및 도 13은 본 발명의 일 실시 예에 따라 구성한 NST의 비트스트림 신택스를 도시한 것이다.
도 14는 본 발명의 일 실시 예에 따라 구성한 NRT_component_descriptor(MH_component_descriptor)의 비트 스트림 신택스를 도시한 것이다.
도 15는 본 발명의 일 실시 예에 따라 구성한 NRT_component_data가 속한 NRT 컴포넌트 디스크립터의 비트 스트림 신택스를 도시한 것이다.
도 16은 본 발명의 일 실시 예에 따라 구성한 NRT 어플리케이션을 시그널링 하기 위한 NRT-IT 섹션의 비트스트림 신택스를 도시한 것이다.
도 17은 본 발명에 따른 NCT섹션(NRT_content_table_section)에 대한 비트 스트림 신택스 구조의 일 실시예를 보인 도면이다.
도 18은 NRT 서비스 데이터에 대한 시그널링 정보를 제공하는 SMT 섹션의 비트 스트림 신택스 구조에 대한 일 실시예를 보이고 있다.
도 19는 본 발명의 일 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것이고, 도 20은 본 발명의 다른 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것이다.
도 20은 본 발명의 다른 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것이다.
도 21은 본 발명의 일 실시예에 따른 수신기의 동작 방법을 나타낸 흐름도이다.
도 22 및 도 23은 NRT 서비스를 위한 NRT 컨텐트를 수신하여 저장 및 재생할 수 있는 수신 시스템의 일 실시예와 다른 일 실시예이다.
도 24는 본 발명의 일 실시예에 따라 수신기가 NRT 서비스를 수신하여 제공하는 방법을 설명하기 위한 흐름도이다.
도 25는 본 발명의 일 실시 예에 따라 구성한 트리거의 비트스트림 신택스를 도시한 것이다.
도 26은 본 발명의 일 실시예에 따라 트리거가 포함된 동기화된 데이터 스트리밍 방식에 따른 PES의 구조를 도시한 도면이다.
도 27은 본 발명의 일 실시예에 따라 트리거를 전송하기 위한 PES 페이로드의 동기화된 데이터 패킷 구조(synchrozied data packet structure)를 비트스트림 신택스로 도시한 것이다.
도 28은 DST상의 tap()에 포함될 수 있는 content type descriptor 구조의 일 실시예를 도시한 것이다.
도 29는 PMT의 신택스와 서비스 식별자 디스크립터의 일 실시예를 도시하고 있다.
도 30은 본 발명의 일 실시예에 따른 트리거 스트림 디스크립터를 도시한 도면이다.
도 31은 AIT테이블의 일 실시예를 도시한 도면이다.
도 32는 STT테이블의 일 실시예를 도시한 도면이다.
도 33은 본 발명의 일 실시예에 따른 TDO 및 트리거를 송신하기 위한 송신기를 개략적으로 나타낸 블록도이다.
도 34는 본 발명의 일 실시예에 따른 TDO 및 트리거를 수신하기 위한 수신기(300)를 개략적으로 나타낸 블록도이다.
도 35는 본 발명의 일 실시예에 의한 트리거 전송 방법을 개략적으로 나타낸 흐름도이다.
도 36은 본 발명의 일 실시예에 따른 수신기(300)의 동작을 개략적으로 나타낸 흐름도이다.
도 37은 본 발명의 일 실시예에 따른 트리거 수신 방법 중, 트리거 테이블을 이용하여 수신하는 방법을 나타낸 흐름도이다.
도 38은 본 발명의 일 실시예에 따라 DST를 이용하여 트리거 시그널링 정보 및 트리거를 전송하는 경우 수신기(300)의 동작을 나타낸 흐름도이다.
도 39는 본 발명의 일 실시예에 따라 트리거 스트림 디스크립터를 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
도 40은 본 발명의 일 실시예에 따라 스트림 타입을 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
도 41은 본 발명의 일 실시예에 따라 AIT를 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
도 42는 본 발명의 일 실시예에 따라 STT를 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
도 43은 본 발명의 한 실시예에 따른 타이밍 다이어그램을 보여준다.
도 44는 본 발명의 한 실시예에 따른 활성화 트리거 데이터 전송 방법을 보여주는 흐름도이다.
도 45는 본 발명의 또 다른 실시예에 따른 타이밍 다이어그램을 보여준다.
도 46은 본 발명의 한 실시예에 따른 유지 트리거 데이터 전송 방법을 보여주는 흐름도이다.
도 47은 본 발명의 한 실시예에 따른 유지 트리거 수신 방법을 설명한다.
도 48은 본 발명의 한 실시예에 따른 타이밍 다이어그램을 보여준다.
도 49는 본 발명의 한 실시예에 따른 준비 트리거 수신 방법을 보여주는 흐름도이다.
도 50은 본 발명의 또 다른 실시예에 따른 준비 트리거 수신 방법을 보여주는 흐름도이다.
도 51은 본 발명의 또 다른 실시예에 따라 구성한 트리거의 비트스트림 신택스를 도시한 것이다.
도 52는 본 발명의 한 실시예에 따른 컨텐트 아이템 디스크립터의 신택스를 보여준다.
도 53은 본 발명의 한 실시예에 따른 인터넷 위치 디스크립터의 신택스를 보여준다.
도 54는 본 발명의 또 다른 실시예에 따른 트리거 전송 방법을 도시한 흐름도이다.
도 55은 본 발명의 실시예에 따른 수신기의 동작 방법을 보여주는 흐름도이다.
도 56은 본 발명의 실시예에 따른 수신기가 컨텐트 아이템의 위치 정보를 파악하는 방법을 보여준다.
도 57은 본 발명의 실시예에 따른 수신기가 트리거를 처리하는 방법을 보여주는 TDO 상태 천이도이다.
이하 의 목적을 구체적으로 실현할 수 있는 본 발명의 바람직한 실시예를 첨부한 도면을 참조하여 설명한다. 이때 도면에 도시되고 또 이것에 의해서 설명되는 본 발명의 구성과 작용은 적어도 하나의 실시예로서 설명되는 것이며, 이것에 의해서 본 발명의 기술적 사상과 그 핵심 구성 및 작용이 제한되지는 않는다.
본 발명에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 발명에서 사용되는 용어는 단순한 용어의 명칭이 아닌 그 용어가 가지는 의미와 본 발명의 전반에 걸친 내용을 토대로 정의되어야 함을 밝혀두고자 한다.
한편, 본 발명에서 사용하는 용어 중 real time (RT) service는, 말 그대로 실시간 서비스를 의미한다. 즉, 시간에 구속받는 서비스이다. 이에 반해, non-real time (NRT) service는 RT 서비스 이외의 비실시간 서비스를 의미한다. 즉, 비실시간 서비스는 시간에 구속받지 않는 서비스이다. 그리고 NRT 서비스를 위한 데이터를 NRT 서비스 데이터라고 할 수 있다.
본 발명에 따른 방송 수신기는 지상파, 케이블, 인터넷 등과 같은 매체를 통해 비실시간(NRT) 서비스를 수신할 수 있다.
NRT 서비스는 방송 수신기의 저장 매체에 저장된 후, 기 설정된 시간이나 유저의 요청에 따라 디스플레이 장치에 표시될 수 있다. NRT 서비스는 파일 형태로 수신되어 저장 매체에 저장되는 것을 일 실시예로 한다. 저장 매체는 방송 수신기의 내부에 장착된 내장 HDD인 것을 일 실시예로 한다. 또 다른 예로, 저장 매체는 방송 수신 시스템의 외부에 연결된 USB(Universal Serial Bus) 메모리, 외장 HDD 등이 될 수도 있다.
NRT서비스를 구성하는 파일들을 수신하여 저장 매체에 저장하고, 유저에게 서비스하기 위해서는 시그널링 정보가 필요하다. 본 발명은 이를 NRT 서비스 시그널링 정보 또는 NRT 서비스 시그널링 데이터라고 할 수 있다.
본 발명에 따른 NRT 서비스는 NRT 서비스 시그널링 데이터를 포함한 IP 데이터그램을 얻는 방식에 따라 Fixed NRT 서비스와 Mobile NRT 서비스로 구분할 수 있다. 특히 Fixed NRT 서비스는 고정형 방송 수신기로 제공되고, Mobile NRT 서비스는 이동형 방송 수신기로 제공된다.
도 1은 RT 서비스와 NRT 서비스를 제공하는 개념을 개시한다.
방송국은 기존 방식에 따라 즉, 현재의 지상파 방송(또는 모바일 방송)과 같이 RT 서비스를 송신한다. 이때, 방송국은 RT 서비스를 송신하고 그 과정에서 남는 대역폭을 이용하거나 또는 전용 대역폭을 이용하여 NRT 서비스를 제공할 수 있다. 즉, RT 서비스와 NRT 서비스는 동일 채널 또는 다른 채널을 통해 전송된다. 따라서 방송 수신기에서 RT 서비스와 NRT 서비스를 구분하고, 구분된 NRT 서비스를 저장한 후 필요시에 유저에게 제공하기 위해 NRT 서비스 시그널링 정보(또는 NRT 서비스 시그널링 데이터)가 요구된다. NRT 서비스 시그널링 정보(또는 NRT 서비스 시그널링 데이터)는 뒤에서 상세히 설명하기로 한다.
예를 들어, 방송국에서는 방송 서비스 데이터를 실시간으로 송신하고, 뉴스 클립, 날씨 정보, 광고, Push VOD 등을 비실시간으로 송신할 수 있다. 또한 NRT 서비스는 뉴스 클립, 날씨 정보, 광고, Push VOD 뿐만 아니라, 실시간 방송 스트림 중 특정 장면들, 특정 프로그램의 상세 정보, 미리보기 등이 될 수도 있다.
종래의 방송 수신기(즉, legacy device)는 실시간 서비스를 수신하여 처리할 수는 있으나, 비실시간 서비스를 수신하여 처리할 수는 없다. 즉, 종래의 방송 수신기(즉, legacy device)는 실시간 서비스를 전송하는 채널에 포함된 NRT 스트림에 의해 그 동작이 영향을 받지 않는 것이 원칙이다. 다시 말해, 종래의 방송 수신기는 NRT 서비스를 수신하여도 적절하게 처리할 수 있는 수단이 구비되지 않아 수신된 NRT 서비스를 처리할 수 없다.
반면, 본 발명에 따른 방송 수신기(즉, NRT device)는 RT 서비스와 결합된 NRT 서비스를 수신하여 적절하게 처리할 수 있으므로, 시청자에게 종래 방송 수신기에 비해 다양한 기능을 제공할 수 있다.
도 2는 본 발명의 일 실시예에 따른 NRT 서비스의 구조를 설명하기 위한 도면이다.
본 발명에 따른 하나의 NRT 서비스는 도 2에서와 같이 하나 이상의 컨텐트 아이템(또는 컨텐트 또는 NRT 컨텐트라 함)를 포함하고, 하나의 컨텐트 아이템은 하나 이상의 파일을 포함하는 것을 일 실시예로 한다. 본 발명에서 파일과 오브젝트는 동일한 의미로 사용될 수 있다.
컨텐트 아이템은 독립적으로 재생이 가능한 최소 단위이다. 예를 들어, 비실시간으로 제공되는 뉴스가 있고, 뉴스에는 경제 뉴스, 정치 뉴스, 생활뉴스가 포함된다고 할 때, 뉴스는 NRT 서비스라 할 수 있고, 경제 뉴스, 정치 뉴스, 생활 뉴스 각각은 컨텐트 아이템이라 할 수 있다. 그리고, 경제 뉴스, 정치 뉴스, 생활 뉴스 각각은 하나 이상의 파일로 구성될 수 있다.
이때 NRT 서비스는 RT 서비스와 동일한 방송 채널 또는 전용 방송 채널을 통해 MPEG-2 트랜스포트 스트림(TS) 패킷 형태로 전송될 수 있다. 이 경우 NRT 서비스를 식별하기 위하여 유일한 PID가 NRT 서비스 데이터의 TS 패킷에 할당되어 전송될 수 있다. 본 발명은 IP 기반의 NRT 서비스 데이터가 MPEG-2 TS 패킷화되어 전송되는 것을 일 실시예로 한다.
이때, NRT 서비스 데이터를 수신하는데 필요한 NRT 서비스 시그널링 데이터는 NRT 서비스 시그널링 채널을 통해 전송된다. NRT 서비스 시그널링 채널은 IP 계층 상에서 특정 IP 스트림을 통하여 전송되는데, 이때 이 특정 IP 스트림도 MPEG-2 TS 패킷화되어 전송될 수 있다. NRT 서비스 시그널링 채널로 전송되는 NRT 서비스 시그널링 데이터는 NRT 서비스 맵 테이블(Service Map Table, SMT), NRT 서비스 테이블(NRT Service Table, NST), NRT 컨텐트 테이블(NRT Content Table, NCT) 및 NRT 정보 테이블(NRT Information Table, NRT-IT), 텍스트 프래그먼트 테이블(TFT)중 적어도 하나를 포함할 수 있다. NST 또는 SMT는 IP 레이어에서 구동하는 적어도 하나의 NRT 서비스 또는 NRT 서비스를 구성하는 컨텐트 아이템 또는 파일들의 접속 정보를 제공하는 것을 일 실시예로 한다. NRT-IT 또는 NCT는 NRT 서비스를 구성하는 컨텐트 아이템 또는 파일들의 상세 정보를 제공하는 것을 일 실시예로 한다.
또한, SMT(또는 NST) 및 NRT-IT(또는 NCT)를 포함할 수 있는 NRT 서비스 시그널링 데이터는 MPEG2 TS상의 PSIP 테이블에 포함되거나, 가상 채널(Virtual Channel)내의 IP 레이어상의 NRT 서비스 시그널링 채널을 통해 전송될 수도 있다. 그리고, 하나의 가상 채널을 통해 복수의 NRT 서비스 데이터가 제공될 수 있다.
비실시간 정보 테이블(NRT-IT)은 수신 장치에 저장되도록 다운로드될 수 있는 콘텐트를 기술하는 정보를 포함한다. NRT-IT에 제공되는 정보는, 콘텐트의 타이틀(예를 들어, 다운로드될 수 있는 프로그램의 이름), 콘텐트가 다운로드될 수 있는 시간, 및 콘텐트 권고, 캡션 서비스의 이용가능성, 콘텐트 식별, 기타 메타데이터와 같은 정보를 포함할 수 있다.
또한, 텍스트 프래그먼트 테이블(TFT)은 콘텐트 항목이나 서비스에 대한 상세 기술 정보를 제공하기 위한 테이블이다. TFT는 다수의 언어를 지원하는 데이터 구조를 포함하고, 이에 따라 서로 다른 여러 언어들로 된 상세 기술들(각 스트링은 하나의 언어에 대응함)을 나타낼 수 있다. 텍스트 프래그먼트 테이블은 table_id 값(TBD)을 갖는 개인 섹션(private sections)에 포함되며, TFT_id에 의해 구별될 수 있다. TFT 섹션은 서비스 시그널링 채널 내에서 IP 패킷들에 포함되며, 이 채널은 IANA에 의해 멀티캐스트 IP 어드레스(224.0.23.60)와 포트(4937)를 할당받은 채널일 수 있다.
우선, 수신기는 예를 들어, SMT 내 service_category 필드를 참조하여 해당 서비스가 NRT 서비스인지 여부를 식별할 수 있다. 그리고 수신기는 SMT로부터 NRT 서비스 식별자 정보(NRT_service_id) 필드를 통해 NRT 서비스를 유일하게 식별할 수 있다.
한편, NRT 서비스는 복수의 컨텐트 아이템을 포함할 수 있다. 수신기는 각각의 NRT 컨텐트 아이템을 NCT 또는 NRT-IT내의 content_id 필드를 통해 식별할 수 있다. 그리고, NRT 컨텐트 아이템과 NRT 서비스는 NCT의 NRT_channel_id 필드와 상술한 NRT_service_id 필드를 일치시킴으로써 연결될 수 있다.
한편, NRT 서비스는 FLUTE 세션을 통해 전송되고, 수신기는 상기 FLUTE 세션으로부터 FDT 정보를 추출할 수 있다. 그리고 상기 추출된 FDT 정보 내 content_id는 NCT 또는 OMA-BCAST SG의 컨텐트 식별자(content_id)와 매핑하여 사용자 등에 의해 선택된 NRT 서비스 컨텐트를 확인하여 수신할 수 있다. 상기 매핑 방법에 대해 간략하게 설명하면 예를 들어, 수신기는 NRT 컨텐트 아이템을 구성하는 각 파일을 FLUTE 세션 내에서의 FDT 내에 명시된 TOI 및 Content-Location 필드를 이용하여 식별하며, 상기 각 TOI 또는 Content-Location과 컨텐트 아이템은 FDT에서의 content_ID 필드를 NCT의 컨텐트 식별자(content_id) 필드 또는 OMA BCAST SG의 컨텐트 식별자(content_id) 필드와 매핑하고, NRT 서비스 컨텐트를 확인하여 수신할 수 있다.
도 3은 본 발명의 일 실시예에 따라 구성한 NRT 서비스에 대한 프로토콜 스택을 도시한 것이다.
본 발명에서는 Fixed NRT 서비스를 위해, 파일 형태의 NRT 서비스를 IP 계층에서 IP 패킷화한 후 특정 가상(Virtual) 채널을 통해 MPEG-2 TS 형태로 전송하는 것을 일 실시예로 한다.
본 발명에서는 MPEG-2 기반의 PSI(Program Specific Information) 또는 PSIP(Program and System Information Protocol) 테이블 예를 들어, 가상 채널 테이블(VCT)를 통하여 가상 채널(Virtual channel) 내, NRT 서비스의 존재 여부 및 NRT 서비스의 식별(Identification) 정보를 시그널링하는 것을 일 실시예로 한다.
본 발명은 IP 기반의 NRT 서비스의 접속 정보를 시그널링하는 NRT 서비스 시그널링 데이터를 전송하는 NRT 서비스 시그널링 채널을 IP 계층에서 특정 IP 스트림으로 IP 패킷화한 후 MPEG-2 TS 형태로 전송하는 것을 일 실시예로 한다.
즉, 방송국에서는 도 3에서와 같이 파일 전송 프로토콜(File Transfer Protocol) 방식에 따라 NRT 컨텐트 아이템 또는 파일들을 패킷화하고, 패킷화된 NRT 컨텐트 아이템 또는 파일들을 ALC 또는 LCT(Asynchronous Layered Coding 또는 Layered Coding Transport) 방식에 따라 패킷화한다. 그리고, 패킷화된 ALC 또는 LCT 데이터는 다시 UDP 방식에 따라 패킷화되며, 패킷화된 UDP 데이터는 다시 IP 방식에 따라 패킷화되어 IP 데이터가 된다. 여기서, IP 데이터는 FLUTE (File Delivery over Unidirectional Transport) 세션에 대한 정보를 포함하는 FDT(File Description Table)를 포함할 수 있다. 패킷화된 IP 데이터를 본 발명에서는 설명의 편의를 위해 IP 데이터그램이라 할 수 있다.
또한, 본 발명에서는 NRT 서비스의 IP 데이터그램들을 어드레서블 섹션 구조로 인캡슐레이션하고, 다시 MPEG-2 TS 포맷으로 패킷화하는 것을 일 실시예로 한다. 즉, 하나의 어드레서블 섹션 구조는 하나의 IP 데이터그램에 섹션 헤더와 CRC 첵섬(checksum)이 추가적으로 더해지는 형태를 가지게 된다. 이러한 어드레서블 섹션 구조의 형태는 프라이빗 데이터(private data) 전송을 위한 DSM-CC(Digital Storage Media Command and Control) 섹션 포맷에 부합되는 구조로 될 수 있다. 따라서 어드레서블 섹션은 DSM-CC어드레서블 섹션이라고 할 수 있다.
한편, NRT 컨텐트/파일들을 수신하기 위해 필요한 SMT(또는 NST) 및 NRT-IT(또는 NCT) 중 적어도 하나를 포함하는 NRT 서비스 시그널링 데이터는 IP 레이어 상의 NRT 서비스 시그널링 채널을 통해 전송될 수 있다. 따라서, NRT 서비스 시그널링 데이터는 IP 레이어 상의 NRT 서비스 시그널링 채널을 통해 전송하기 위해 IP 방식에 따라 패킷화될 수 있다. NRT 서비스 시그널링 채널은 Well-known IP address를 가지는 IP 데이터그램에 인캡슐레이션되어 멀티캐스트(Multicast)되는 것을 일 실시예로 한다.
또한, 일 실시예에 따르면 NRT 서비스 시그널링 데이터는 PSI(Program Specific Information) 또는 PSIP(Program and System Infromation Protocol) 테이블 섹션 데이터에 포함되어 전송될 수 있다. 그리고, PSI테이블은 일 실시예로, PMT(Program Map Table), PAT(Program Association Table) 등을 포함할 수 있으며, PSIP테이블은 일 실시예로, VCT(Virtual Channel Table), TVCT(Terrestrial Virtual Channel Table), CVCT(Cable Virtual Channel Table), STT(System Time Table), RRT(Rating Region Table), ETT(Extended Text Table), DCCT(Direct Channel Change Table), DCCSCT(Direct Channel Change Selection Code Table), EIT(Event Information Table), 및 MGT(Master Guide Table)를 포함할 수 있다.
한편, 이와 같은 NRT 서비스를 불법 유통 및 복제로부터 보호하기 위해 방송 서비스의 디지털 저작권 관리 및 암호화를 위한 데이터로서 오픈 모바일 연합(Open Mobile Allience, OMA)에서 제안된 BCAST DRM(BroadCast Services Enalbler Suite Digital Rights Management)이 사용될 수 있다.
그리고, 상술한 PSI(Program Specific Information), PSIP(Program and System Information Protocol) 테이블 섹션 데이터, DSM-CC 어드레서블 섹션 데이터 및 OMA BCAST DRM 데이터를 184 바이트 단위로 분할한 후, 각184 바이트에 4바이트의 MPEG 헤더를 부가하면, 188 바이트의 MPEG-2 TS 패킷을 만들 수 있다. 이때, MPEG 헤더의 PID에 할당되는 값은 NRT 서비스와 NRT 서비스 시그널링 채널을 전송하는 TS 패킷을 식별할 수 있는 유일한 값일 수 있다.
MPEG-2 TS 패킷들은 물리 계층(physical layer)에서 기 정해진 전송 방식 예를 들면, 8-VSB 전송 방식으로 변조되어 수신 시스템으로 전송될 수 있다.
한편, 도 4는 본 발명의 다른 일 실시예에 따라 구성한 NRT 서비스에 대한 프로토콜 스택을 도시한 것이다.
도 4는 모바일 NRT 서비스를 제공하기 위한 프로토콜 스택의 일 예를 보이고 있다. 도 4는 IP 계층과 물리 계층 사이에 적응 계층(Adaption Layer)을 포함시켜, MPEG-2 TS 포맷을 사용하지 않으면서 모바일 서비스 데이터의 IP 데이터그램과 시그널링 정보의 IP 데이터그램을 전송할 수 있도록 하는데 있다.
즉, 방송국에서는 도 4에서 파일 전송 프로토콜(File Transfer Protocol) 방식에 따라 NRT 컨텐트/파일들을 패킷화하고, 이를 다시 ALC/LCT(Asynchronous Layered Coding/Layered Coding Transport) 방식에 따라 패킷화한다. 상기 패킷화된 ALC/LCT 데이터는 다시 UDP 방식에 따라 패킷화되며, 상기 패킷화된 ALC/LCT/UDP 데이터는다시 IP 방식에 따라 패킷화되어 ALC/LCT/UDP/IP 데이터가 된다. 상기 패킷화된 ALC/LCT/UDP/IP 데이터를 본 발명에서는 설명의 편의를 위해 IP 데이터그램이라 한다. 이때 OMA BCAST SG 정보도 상기 NRT 컨텐트/파일과 동일한 과정을 거쳐 IP 데이터그램을 구성할 수 있다.
또한 상기 NRT 컨텐트/파일들을 수신하기 위해 필요한 NRT 서비스 시그널링 정보(예를 들어, SMT)는 서비스 시그널링 채널을 통해 전송되는데, 상기 서비스 시그널링 채널은 UDP(User Datagram protocol) 방식에 따라 패킷화되고, 상기 패킷화된 UDP 데이터는 다시 IP 방식에 따라 패킷화되어 UDP/IP 데이터가 된다. 상기 UDP/IP 데이터도 본 발명에서는 설명의 편의를 위해 IP 데이터그램이라 한다. 이때 상기 서비스 시그널링 채널은 Well-known IP desinationaddress와 well-known desination UDP port number를 가지는 IP 데이터그램에 인캡슐레이션되어 멀티캐스트(Multicast)되는 것을 일 실시예로 한다.
그리고, 서비스 보호를 위한 OMA BCAST DRM은 UDP 헤더, IP 헤더가 순차적으로 더해져 하나의 IP 데이터그램을 구성한다.
적응 계층에서 상기 NRT 서비스, NRT 서비스 시그널링 채널, 모바일 서비스 데이터의 IP 데이터그램들을 모아 RS 프레임을 생성한다. 상기 RS 프레임에 OMA BCAST SG의 IP 데이터그램도 포함될 수 있다.
상기 RS 프레임에서 컬럼의 길이(즉, 로우의 개수)는 187 바이트로 정해지며, 로우의 길이(즉, 컬럼의 개수)는 N바이트이고, 상기 N은 전송 파라미터(또는 TPC 데이터)와 같은 시그널링 정보에 따라 달라질 수 있다.
상기 RS 프레임은 모바일 물리 계층(mobile physical layer)에서 기 정해진 전송 방식 예를 들면, VSB 전송 방식으로 변조되어 수신 시스템으로 전송된다.
한편, 본 발명에서는 NRT 서비스의 전송 여부를 PSI/PSIP 테이블을 통해 시그널링하는 것을 일 실시예로 한다. 일 예로, NRT 서비스의 전송 여부를 가상 채널 테이블(VCT) 또는 지역 가상 채널 테이블(TVCT)에 시그널링하는 것을 일 실시예로 한다.
도 5는 본 발명의 일 실시 예에 따라 구성한 TVCT 테이블 섹션(VCT)의 비트스트림 섹션을 도시한 것이다.
도 5를 참조하면, TVCT 테이블 섹션은 MPEG-2 프라이빗 섹션의 테이블 형태를 가지는 것을 일 예로 하여 설명하나, 반드시 이에 한정되는 것으로 아니다.
오디오/비디오에 관한 패켓 식별(PID)정보는 상기 오디오/비디오의 VCT, PID를 파싱하여 TVCT를 통해 전송된고 오디오/비디오에 관한 패킷 식별(PID)정보를 알 수 있다.
따라서, TVCT 테이블 섹션은 헤더, 바디와 트레일러로 구분할 수 있고, 헤더 부분은 table_id 필드에서 protocol_version 필드까지이며, transport_stream_id 필드는 16비트 필드로서, 다중화(multiplex)를 위해 0의 PID 값에 의해 정의되는 PAT(program association table) 내의 MPEG-2 전송 스트림 ID를 나타낸다. 바디 부분은 num_channels_in_section 필드는 8비트 필드로서, VCT 섹션 내의 가상 채널(virtual channel)들의 개수를 상술한다. 마지막으로 트레일러 부분은 CRC_32 필드를 포함한다.
먼저, 헤더 부분을 설명하면 다음과 같다.
table_id 필드(8비트)는 0xC8로 설정되어, 해당 테이블 섹션이 TVCT를 구성하는 테이블 섹션임을 식별한다.
section_syntax_indicator 필드(1비트)는 1로 설정되면, 상기 섹션이 일반적인 섹션 신택스를 따름을 나타낸다.
private_indicator 필드(1비트)는 1로 설정되어 있다.
section_length 필드(12비트)는 section_length 필드 바로 다음에서부터 상기 섹션의 마지막까지 이 섹션에 남아 있는 바이트들의 개수를 상술한다. 상기 section_length 필드의 값은 1021 보다 클 수 없다.
table_id_extension 필드(16비트)는 0x000으로 설정되어 있다.
version_number 필드(5비트)는 0의 값을 가질 수 있으며 VCT의 버전넘버를 의미한다.
current_next_indicator 필드(1비트)는 1로 설정되어 있으면 해당 테이블 섹션은 현재 적용 가능함을 나타낸다.
section_number 필드(8비트)는, TVCT 섹션들 중 해당 테이블 섹션의 넘버를 지시한다. TVCT의 제 1 섹션은 section_number는 0x00으로 설정되어야 한다.
last_section_number 필드(8비트)는, TVCT 섹션들 중 가장 마지막 및 가장 높은 넘버의 테이블 섹션을 의미한다.
protocol_version 필드(8비트)는, 현재 프로토콜에서 정의된 것보다 다르게 구조화된 파라미터들을 전달하는 이 테이블 타입의 허락하는 함수이다. 현재, protocol_version의 단 하나의 유효값은 0이다. 0이 아닌protocol_version은 구조적으로 다른 테이블을 인식하기 위해 상기 표준의 미래 버전에 사용될 수 있다.
다음으로 바디(body) 부분을 설명한다.
num_channels_in_section 필드 (8비트)는 상기 VCT 섹션의 가상 채널들의 넘버를 지정한다. 상기 넘버는 테이블 섹션 길이에 따라 제한된다.
short_name 필드(16비트)는, 1에서 7까지 연속된 16비트의 코드 값으로 상기 가상 채널의 이름(name)을 표현한다.
major_channel_number 필드(10비트)는, "for" loop의 반복에 정의된 가상채널과 연관된 메이저 채널 넘버(major channel number)를 표현한다. 각 가상 채널은 메이저 채널 넘버 및 마이너 채널 넘버 (minor channelnumber)와 연관되어야 한다. 마이너 채널 넘버와 함께 메이저 채널 넘버는 사용자의 가상 채널의 참조 넘버로 역할한다.
minor_channel_number 필드(10비트)는, '0'에서 '999'까지의 범위 내 마이너(minor) 또는 서브(sub-) 채널 넘버를 표현한다. major_channel_number와 함께 상기 필드는 minor_channel_number가 넘버의 제2 또는 오른쪽 부분을 나타내는 2부의 채널 넘버로 수행한다. minor_channel_number는 service_type이 아날로그 텔레비전일 경우에 0으로 설정되어야한다. service_type이 ATSC_digital_television이나 ATSC_audio_only일 경우에 '1'에서 '99'까지의 범위 내 마이너 넘버를 사용한다. minor_channel_number의 값은 TVCT에서 major_channel_number과 minor_channel_number이 중복되지 않게 한다.
modulation_mode 필드(8비트)는 가상채널과 연관된 캐리어(carrier)를 위한 변조 모드(modulation mode)를 나타낸다.
carrier_frequnecy 필드(32비트)는 권장 값이 0이다. 캐리어 주파수를 식별하는 상기 필드의 사용은 허용되지만 하지 않는 게 바람직하다.
channel_TSID 필드(16비트)는'0x0000'에서 '0xFFFF'까지의 범위 내 가상 채널에 의해 참조되는 MPEG-2 프로그램을 싣고 있는 전송 스트림과 연관된 MPEG-2 전송 스트림 ID를 표현하는 부호 없는 정수 필드다.
program_number 필드(16비트)는, MPEG-2 PAT(program association table)과 TS PMT(program map table)에 정의되는 가상 채널과 연관되는 부호 없는 정수 넘버를 식별한다. 아날로그 서비스에 해당하는 가상 채널은 program_number가 '0xFFFF'로 정한다.
ETM_location 필드(2비트)는, ETM(extended text message)의 존재(existence) 유무와 위치(location)를 설명한다.
access_controlled 필드(1비트)는, 설정되면 가상 채널과 연관된 이벤트들은 액세스(access)가 제어됨을 지시한다. 상기 플래그가 0으로 설정되면, 이벤트 액세스는 제한되지 않는다.
hidden 필드(1비트)는, 설정되면 가상 채널은 가상 채널 넘버의 직접 엔트리에 의한 사용자가 접근할 수 없음을 지시한다. 히든 가상 채널(hidden virtual channel)은 사용자가 채널을 서핑하는 경우에 생략되고 정의되지 않거나 직접 채널 엔트리에 액세스할 경우에 나타난다. 히든 채널(hidden channel)의 전형적인 애플리케이션은 테스트 신호 및 NVOD 서비스이다. 히든 채널 및 그 이벤트들은 hide_guide 비트의 상태에 따라 EPG 디스플레이에 나타난다.
hidden_guide 필드는, 히든 채널을 위해 0으로 설정되면, 가상 채널과 그 이벤트들은 EPG 디스플레이에서 나타날 수도 있다. 상기 비트는 히든 비트 세트가 없는 채널에는 무시하므로 비 히든 채널들 및 그 이벤트들은 hide_guide 비트의 상태에 상관없이 EPG 디스플레이에 항상 포함된다. hidden_guide 비트 세트가 '1'로 설정된 히든 채널의 전형적인 애플리케이션은 애플리케인션 레벨 포인터를 통해 얻기 쉬운 테스트 신호 및 서비스이다.
service_type 필드(6비트)는, 가상 채널에서 전송되는 서비스의 타입을 나타낸다. 도 6과 도 7은 본 발명의 실시예에 따른 service_type 필드의 값을 정의한 예를 나타낸 도면이다. 본 발명의 일 실시 예에서, 도 6에 표시된 service_type의 값 '0x04'는 service_type이 ATSC_data_only_service라는 것과 가상 채널을 통해 NRT 서비스가 전송될 수 있다는 것을 의미한다. 본 발명의 다른 실시 예에서, 도 7에 표시된 service_type의 값'0x08'은 service_type이 ATSC_nrt_service라는 것과 가상 채널은 ATSC 기준에 부합한 NRT 서비스를 제공한다는 것을 의미한다.
source_id 필드(16비트)는, 가상 채널과 연관된 프로그램의 소스를 나타낸다.
descriptors_length 필드는 뒤따르는 가상 채널을 위한 디스크립터의 전체 길이(바이트 단위)를 나타낸다.
descriptor() 필드는 0개 이상의 디스크립터를 포함한다.
additional_descriptors_length 필드는 뒤따르는 VCT 디스크립터 리스트의 전체 길이(바이트 단위)를 나타낸다.
마지막으로 트레일러 부분, CRC_32 필드는 32비트 필드로서, 전체 STT 섹션을 프로세싱한 후 MPEG-2 시스템에 정의된 디코더(decoder)의 레지스터(register)들로부터 제로 출력(zero output)을 보장(ensure)하는 CRC(cyclic redundancy check) 값을 포함한다.
도 8은 NRT 서비스의 어플리케이션을 식별하기 위한 DST 테이블 섹션(data_service_table_section) 및 DST 섹션에 포함된 data_service_table_bytes의 비트스트림 신택스를 도시한 것이다. 방송국은 도 8에 도시된 DST 테이블 섹션을 통하여 ASTC규격에 부합하는 NRT 서비스 데이터 또는 NRT 서비스 시그널링 데이터를 전송할 수 있다.
이하 data_service_table_section 구조를 포함하는 필드들의 시맨틱스의 일 실시예는 다음과 같다.
table_id 필드(8비트)는 해당 테이블 섹션의 타입 식별을 위한 필드로서, 본 필드를 통해 해당 테이블 섹션이 DST를 구성하는 테이블 섹션임을 알 수 있다. 예를 들어, 수신기는 본 필드의 값이 0XCF를 가지면 해당 테이블 섹션이 DST를 구성하는 테이블 섹션임을 식별할 수 있다.
section_syntax_indicator 필드(1비트)는 DST의 섹션 형식을 정의하는 지시자로서, 섹션 형식은 예를 들어, MPEG의 short-form 신택스(0) 등이 될 수 있다.
private_indicator 필드(1비트)는 해당 섹션의 형태가 프라이빗 섹션 형태를 따르는지 여부를 나타내며 '1'로 설정될 수 있다.
private_section_length 필드(12비트)는 해당 필드 이후의 나머지 테이블 섹션 길이를 나타낸다. 또한 이 필드의 값은 '0xFFD'를 넘지 않는다.
table_id_extension 필드(16비트)는 테이블에 종속적이고, 남은 필드들의 범위를 제공하는 table_id 필드의 논리적인 부분이 될 수 있다.
version_number 필드(5비트)는 DST의 버전 넘버를 나타낸다.
current_next_indicator 필드(1비트)는 전송된 DST 테이블 섹션이 현재 적용 가능한지 여부를 지시한다. 이 필드 값이 0이면, 아직 테이블이 존재 하지 않고 다음 테이블에 유효함을 의미한다.
section_number 필드(8비트)는 해당 테이블 섹션이 DST 테이블을 구성하는 섹션들 내 섹션 넘버를 나타낸다. DST의 첫 섹션의 section_number는 '0x00'으로 설정된다. section_number는 DST의 섹션이 늘어갈때마다 하나씩 증가한다.
last_section_number 필드(8비트)는 DST 테이블을 구성하는 마지막 섹션 번호를 나타낸다. (가장 높은 section_number)
data_service_table_bytes는 DST를 구성하는 데이터 블록을 나타내며, 자세한 구조는 후술한다.
CRC_32 필드는 32비트 필드로서, 전체 DST 섹션을 프로세싱한 후 MPEG-2 시스템에 정의된 디코더(decoder)의 레지스터(register)들로부터 제로 출력(zero output)을 보장(ensure)하는 CRC(cyclic redundancy check) 값을 포함한다.
한편, 상술한 data_service_table_bytes 구조를 포함하는 필드들의 시맨틱스의 일 실시예를 정의하면 아래와 같다.
sdf_protocol_version 필드 (8비트)는, Service Description Framework 프로토콜의 버전을 설명한다.
application_count_in_section 필드 (8비트)는, DST 섹션 내 리스트 된 어플리케이션들의 수를 설명한다.
compatibility_descriptor() 필드는, 해당 구조가 DSM-CC 호환성 디스크립터를 포함함을 나타낸다. 그 목적은 해당 데이터 서비스를 사용하기 위해 그 능력을 판단하기 위해 수신 플랫폼에서 어플리케이션의 호환성 요구사항들을 시그널링하기 위함이다.
app_id_byte_length 필드 (16비트)는, 어플리케이션을 식별하는데 사용되는 바이트들의 개수를 설명한다.
app_id_description 필드 (16비트)는, 다음 application identification bytes의 포맷과 시맨틱스를 설명할 수 있다. 예를 들어, app_id_description 필드의 값은 다음의 표 1과 같이 정의할 수 있다.
표 1
Figure PCTKR2012000511-appb-T000001
app_id_byte 필드 (8비트)는, 어플리케이션 식별자의 바이트를 표현한다.
tap_count 필드 (8비트)는, 해당 어플리케이션에 의한 사용되는 Tap() 구조들의 개수를 설명한다.
protocol_encapsulation 필드 (8비트)는, Tap() 필드에 의해 참조되는 특정 데이터 엘리먼트를 전송하기 위해 사용되는 프로토콜 인캡슐레이션의 타입을 설명한다. protocol_encapsulation 필드의 값은 다음과 같은 표 2와 같이 정의되어 사용될 수 있다.
표 2
Figure PCTKR2012000511-appb-T000002
action_type 필드 (7비트)는, Tap() 필드에 의해 참조되는 데이터의 속성을 나타낼 수 있다.
resource_location 필드 (1비트)는, 다음 Tap 구조 내 리스트 된 association_tag 값과 매칭되는 association_tag 필드의 위치를 설명한다. 해당 필드가 '0'으로 설정되면 매칭되는 association_tag는 현재 MPEG-2 프로그램의 PMT 내 존재한다. 이와 달리, '1'로 설정되면 매칭되는 association_tag는 해당 데이터 서비스의 Network Resources Table 내 DSM-CC Resource Descriptor에 존재한다.
Tap() 필드는, 하위 계층의 통신 채널에 포함된 어플리케이션 단계의 데이터 엘리먼트를 찾기 위한 정보를 포함할 수 있다. Tap() 필드 내의 association_tag 필드에는 어플리케이션 단계의 데이터 엘리먼트간의 대응관계 정보가 포함될 수 있다. 하나의 Tap 구조 내의 association_tag 필드의 값은 현재 PMT 내에 포함된 하나의 association tag 디스크립터의 association_tag 필드의 값에 대응한다. 예를 들어, Tap()필드는 하기의 표 3과 같은 필드들을 포함한 특정 구조를 포함할 수 있다.
표 3
Figure PCTKR2012000511-appb-T000003
tap_id 필드 (16비트)는 데이터 엘리먼트들을 식별하기 위해 어플리케이션에 의해 사용된다. tap_id의 값은 DST 내 Tap()와 관련된 app_id_byte필드들의 값에 의해 범위가 정해진다. tap_id 값은 데이터 서비스 프로바이더에 의해 선택된다. 또한, tap_id 값은 데이터 엘리먼트를 다루기 위한 어플리케이션에서 사용될 수 있다.
Use 필드 (16비트)는, association_tag에 의해 참조되는 통신 채널을 특정하기 위해 사용된다.
association_tag 필드 (16비트)는, Network Resource Table 내 리스트 된 DSM-CC 리소스 디스크립터나 또는 PMT 내에 리스트 된 데이터 엘리먼트리 스트림 중 어느 하나를 유일하게 식별한다. 해당 필드의 값은 데이터 서비스의 PMT 내 association_tag_descriptor의 association_tag 값과 일치할 수 있다.
Selector() 필드는, association_tag 필드에 의해 참조되는 통신 채널 또는 데이터 엘리먼트리 스트림 내에 이용 가능한 특정 데이터 엘리먼트를 설명한다. 또한, selector 구조는 해당 데이터 엘리먼트를 위해 요구되는 프로토콜을 지시할 수 있다.
tap_info_length 필드 (16비트)는, 해당 필드 다음 필드의 디스크립터들의 바이트의 수를 설명할 수 있다.
descriptor() 필드는, 해당 디스크립터 포맷에 따른 디스크립터 정보를 포함할 수 있다.
app_info_length 필드 (8비트)는, 해당 필드 다음의 디스크립터들의 바이트 수를 설명한다.
descriptor() 필드는, 해당 디스크립터 포맷에 따른 디스크립터 정보를 포함할 수 있다.
app_data_length 필드 (16비트)는, app_data_byte 필드들의 바이트 단위의 길이를 설명한다.
app_data_byte (8비트)는, 어플리케이션과 관련된 입력 파라미터들과 다른 프라이빗 데이터 필드들을 1바이트로 표현한다.
service_info_length 필드 (8비트)는, 다음 디스크립터들의 바이트 단위의 수를 설명한다.
descriptor() 필드는, 해당 디스크립터 포맷에 따른 디스크립터 정보를 포함할 수 있다.
service_private_data_length 필드 (16비트)는, 프라이빗 필드들의 바이트 단위의 길이를 설명한다.
service_private_data_byte 필드 (8비트)는, 프라이빗 필드를 1바이트로 표현한다.
도 9는 본 발명에 따른 수신 시스템에서, 데이터 방송 스트림을 전달하기 위한 ATSC A/90 규격과 IP 멀티캐스트 스트림(Multicast stream)을 전송하는 ATSC A/92 규격을 활용하여 NRT 서비스를 수신하여 서비스하는 방법을 설명하고 있다.
즉, 각 가상 채널을 구성하는 스트림의 정보는 VCT의 Service location descriptor나 PMT의 ES_loop에 시그널링 된다. 예를 들어, 도 7 또는 도 8에서와 같이 VCT의 서비스 타입(service type)이 0x02(즉, 디지털 A/V/Data)이거나 0x04(즉, Data only)인 경우, 또는 0x08(즉, NRT Only service)인 경우, 상기 가상 채널로 NRT 서비스 스트림이 전송될 수 있다. 이때 VCT의 service location descriptor(또는 PMT의 ES loop)에 포함된 stream_type 필드 값에 0x95(즉, DST 전송)가 할당되어 있으면 데이터 방송이 전송됨을 의미한다. 만일 stream_type 필드 값이 없거나, 0x95가 아니면 일반 A/V만 전송된다. 즉, 상기 service location desciptor에 포함된 stream_type 필드 값이 0x95를 나타내면, 이때의 Elementary_PID 필드 값은 DST(Data Service Table)의 PID 값이 된다. 따라서 상기 Elementary_PID를 통해 DST를 수신할 수 있다.
상기 DST를 통해 어플리케이션(Application)의 종류 및 이 채널을 통해 전송되는 데이터 방송 스트림의 상세 정보를 알 수 있다. 본 발명에서는 DST를 이용하여 NRT 어플리케이션(즉, NRT 서비스)를 식별하도록 한다.
즉, DST의 App_id_descrption 필드는 뒤이어 오는 application identification bytes의 포맷 및 해석을 규정한다. 본 발명은 NRT 어플리케이션을 식별하기 위해 상기 App_id_descrption 필드에 '0x0003'를 할당하는 것을 일 실시예로 한다. 상기 예시한 수치는 일 예에 불과하며, 상기 수치로 본 발명의 권리범위가 제한되는 것은 아니다.
만일, 상기 App_id_descrption 필드 값이 '0x0003'이면, 그 다음에 오는 Application_id_byte 값은 NRT 어플리케이션의 Service ID값이 된다. 상기 NRT 어플리케이션을 위한 서비스 아이디는 해당 서비스를 전 세계적으로 유일하게 식별하는 URI 값을 가질 수 있다.
상기와 같이 NRT 어플리케이션임을 식별한 이후에는 NRT 서비스 시그널링 채널의 IP 데이터그램으로부터 분할된 MPEG-2 TS 패킷의 PID를 Tap 정보를 통해 찾는다. 그러면, 상기 tap 정보를 통해 찾은 PID를 갖는 MPEG-2 TS패킷들로부터 NRT 서비스 시그널링 채널을 전송하는IP 데이터그램을 획득할 수 있으며, 상기 획득된 IP 데이터그램으로부터 NRT 서비스 시그널링 데이터를 획득할 수 있다. 이때 상기 NRT 서비스 시그널링 채널의 IP 접속정보는 잘 알려진 IP 접속 정보 즉, well-known IP address와 well-known UDP port number가 사용될 수 있다.
즉, 상기 DST에서 Protocol_encapsulation 필드 값이 0x04이면 비동기 IP 스트림이 전송되고, Selector_type필드 값이 0x0102이면 selector_bytes를 통해 destination address를 가리키는 device_id 값이 전달된다. 상기 selector_bytes 값을 정확히 해석하기 위해서 multiprotocol_encaplsulation_descriptor가 사용되며, device_id값 중에서 유효(valid)한 바이트의 개수를 시그널링해준다. 결국 Tap 정보를 통하여 해당 PID로 전송 되는 NRT 서비스 시그널링 채널의 IP Multicast address (혹은 address range)를 알 수 있게 된다.
따라서, 수신기는 상기 IP Multicast address (혹은 address range)에 접속하여 IP 스트림 즉, IP 패킷을 수신하고, 상기 수신된 IP 패킷으로부터 NRT 서비스 시그널링 데이터를 추출한다.
그리고, 수신기는 상기 추출된 NRT 서비스 시그널링 데이터를 기초로, NRT 서비스 데이터 즉, NRT 컨텐트 아이템/파일들을 수신하여 저장 매체에 저장하거나, 디스플레이 장치에 표시할 수 있다.
본 발명은 다른 실시예로, DST의 Stream Type 필드 값에 0x95 대신 새로운 값 예를 들어, 0x96을 사용하여 NRT서비스를 시그널링할 수 있다. 이는 기존 수신기가 데이터 방송 스트림의 존재 여부를 스트림 타입이 0x95인 스트림의 존재 여부로만 판단하여 동작할 경우, 새로운 어플리케이션인 NRT서비스에 대해 오동작할 우려가 있기 때문이다. 이러한 경우 스트림 타입을 새롭게 지정해 줌으로써 기존 수신기에서는 이를 무시하도록 하여 하위 호환성을 보장할 수 있을 것이다.
도 10 및 도 11은 본 발명의 다른 일 실시예에 따라 DSM-CC 어드레서블 섹션 데이터를 이용하여 NRT 서비스를 수신하는 방법을 설명하고 있다.
DST를 이용한 데이터 전송 방식은 모든 종류의 IP 데이터그램을 디지털 방송 스트림을 통하여 전송하기 위한 규격으로서, NRT 서비스에 대하여는 비효율적일 수 있다. 따라서, 도 10 과 도 11에서는 일 실시예로서, DSM-CC 어드레서블 섹션의 데이터를 통하여 NRT 서비스에 대한 IP 데이터그램의 IP 주소정보와 섹션 데이터를 포함하는 특정 스트림의 PID를 시그널링 하여 NRT 서비스를 수신하도록 하는 방법을 도시하고 있다.
도 10과 같이, 수신기는 VCT(또는 TVCT)의 서비스 타입(service type)이 0x08(즉, NRT Only service)인 경우, 상기 가상 채널로 NRT 서비스 스트림이 전송될 수 있다는 정보를 획득 할 수 있다. 즉, 수신기는 가상 채널의 PID와 채널 번호를 매핑하여 service_type 정보에 따라 NRT 서비스 존재 여부에 대한 정보를 획득 할 수 있다.
이때 VCT의 service location descriptor(또는 PMT의 ES loop)에 포함된 stream_type 필드 값에 0x0D가 할당되어 있으면 DSM-CC 스트림이 전송됨을 의미할 수 있다. 이때의 Elementary_PID 필드 값은 DSM-CC 어드레서블 섹션의 PID 값이 될 수 있다. 따라서 수신기는 Elementary_PID를 통해 NRT 서비스 데이터를 포함하는 DSM-CC 어드레서블 섹션을 수신할 수 있다.
즉, 수신기는 VCT 또는 PMT를 통해 DSM-CC 어드레서블 섹션의 PID를 획득할 수 있다. 여기서, 수신기는 해당 스트림의 PMT로부터 획득한 PID에 대응하는 NRT 서비스 시그널링 채널의 IP 주소 또는 NRT 서비스 데이터를 전송하기 위한 FLUTE 세션의 IP 주소를 포함하는 NRT_IP_address_list_descriptor_A() 필드를 획득할 수 있다.
그리고, 수신기는 NRT_IP_address_list_descriptor_A()필드로부터 획득한 IP 주소에 기초하여 IP 멀티캐스트 스트림 또는 IP 서브넷으로부터 DSM-CC 어드레서블 섹션 데이터를 수신할 수 있다. 수신기는 수신한 DSM-CC 어드레서블 섹션 데이터에서 상기 획득한 elementray_PID에 대응하는 PID가 존재하는 DSM-CC 어드레서블 섹션을 찾음으로써, 특정 NRT 서비스(예를 들어 A, B, 또는 C) 데이터를 포함하는 해당 IP 데이터그램을 획득할 수 있다.
도 11에서는 다른 일 실시예로서, VCT를 이용하여 DSM-CC 어드레서블 섹션 데이터를 시그널링 하는 방법을 나타낸다.
상술한 바와 마찬가지로, 수신기는 VCT에 명시된 서비스 타입(service_type)이 0X02, 0X04 또는 0X08인 경우 NRT 서비스 스트림이 전송될 수 있다는 정보를 획득할 수 있다. 그리고, 수신기는 DSM-CC 스트림을 수신하기 위하여 service_location_descriptor() 필드로부터 스트림 타입이 0X0D인 elementary_PID를 획득할 수 있다. 여기서, 수신기는 획득한 elementray_PID에 대응하는 NRT 서비스 시그널링 채널의 IP 주소 또는 NRT 서비스 데이터를 전송하기 위한 FLUTE 세션의 IP 주소를 포함하는 NRT_IP_address_list_descriptor_B() 필드를 VCT로부터 획득할 수 있다.
그리고, 수신기는 NRT_IP_address_list_descriptor_B()필드로부터 획득한 IP 주소에 기초하여 IP 멀티캐스트 스트림 또는 IP 서브넷으로부터 DSM-CC 어드레서블 섹션 데이터를 수신할 수 있다. 수신기는 수신한 DSM-CC 어드레서블 섹션 데이터에서 상기 획득한 elementray_PID에 대응하는 PID가 존재하는 DSM-CC 어드레서블 섹션을 파싱함으로써, 수신하고자 하는 특정 NRT 서비스(예를 들어 A, B, 또는 C) 데이터를 포함하는 IP 데이터그램을 획득할 수 있다.
이와 같은 NRT 서비스 시그널링 데이터 및 NRT 서비스 데이터 추출 과정을 예를 들어 설명하면 다음과 같다. 여기서는 VCT 내 service_type 필드 값에 0x08을 할당하여, 해당 가상 채널로 하나 이상의 NRT 서비스가 전송됨을 지시하는 것을 일 실시예로 한다.
즉, 수신기의 전원이 켜지고 디폴트 또는 사용자에 의한 채널이 튜너를 통해 선택되면, PSI/PSIP 섹션 핸들러는 상기 선택된 채널로 수신되는 방송 신호로부터 VCT와 PMT를 획득한다. 그리고 PSI/PSIP 섹션 핸들러는 상기 획득된 VCT를 파싱하여 NRT 서비스가 있는지를 확인한다. 이는 상기 VCT의 가상 채널 루프 내 service_type 필드 값을 확인하여 알 수 있다. 예를 들어, 상기 service_type 필드 값이 0x08이 아니면 해당 가상 채널은 NRT 서비스를 전송하지 않는다. 이때 상기 가상 채널은 기존 서비스(즉, legacy ATSC 서비스)를 전송하므로, 수신기는 상기 가상 채널에 포함된 정보에 따라 적절한 동작을 수행한다.
그리고, 역다중화기는 서비스 매니저의 제어에 의해 service_type 필드 값이 0x08이면, 해당 가상 채널은 NRT 서비스를 전송한다. 이 경우 상기 VCT의 가상 채널 루프 내 service location descriptor를 파싱하여 DST의 PID를 추출한다. 그리고 추출된 PID를 이용하여 DST를 수신한다.
그리고, 수신기는 상기 수신된 DST로부터 선택된 채널을 통해 제공되는 해당 서비스가 NRT 서비스인지를 확인한다.
상기 NRT 서비스는 App_id_descrption 필드 값으로부터 확인할 수 있다.
본 발명은 NRT 어플리케이션(즉, NRT 서비스)을 식별하기 위해 상기 App_id_descrption 필드에 '0x0003'를 할당하는 것을 일 실시예로 한다. 상기 예시한 수치는 일 예에 불과하며, 상기 수치로 본 발명의 권리범위가 제한되는 것은 아니다.
만일 상기 DST 내 App_id_descrption 필드 값이 '0x0003'이면, 그 다음에 오는 Application_ id_byte 값은 NRT 어플리케이션(즉, NRT 서비스)의 Service ID값이 된다. 그러므로, 서비스 매니저 또는 PSI/PSIP섹션 핸들러는 상기와 같이 NRT 어플리케이션(즉, NRT 서비스)임을 식별한 이후에 NRT 서비스 시그널링 채널의 IP 데이터그램으로부터 분할된 MPEG-2 TS 패킷의 PID를 찾기 위해 Tap을 추출한다. 이어 상기 추출된 Tap의 association_tag를 포함하는 스트림 PID를 PMT로부터 추출한다.
그리고, 어드레서블 섹션 핸들러는 상기 추출된 스트림 PID에 해당하는 MPEG-2 TS 패킷들을 수신하여 디캡슐레이션 즉, MPEG-2 헤더를 제거하여 DSM-CC 어드레서블 섹션을 복원할 수 있다.
이후, 수신기는 상기 DSM-CC 어드레서블 섹션으로부터 섹션 헤더와 CRC 첵섬을 제거하여 NRT 서비스 시그널링 채널을 전송하는 IP 데이터그램을 복원(recover)하고 복원된 IP 데이터그램으로부터 NRT 서비스 시그널링 데이터를 획득한다. 여기서, 상기 NRT 서비스 시그널링 채널을 전송하는 IP 데이터그램의 접속 정보는 well-known 데스티네이션(destination) IP 어드레스와 well-known 데스티네이션 (destination) UDP 포트 번호인 것을 일 실시예로 한다.
즉, 상기 DST에서 Protocol_encapsulation 필드 값이 0x04이면 비동기 IP 스트림이 전송되고, Selector_type필드 값이 0x0102이면 selector_bytes를 통해 destination address를 가리키는 device_id 값이 전달된다. 상기 selector_bytes값을 정확히 해석하기 위해서 multiprotocol_encaplsulation_descriptor가 사용되며, device_id값 중에서 유효(valid)한 바이트의 개수를 시그널링해준다. 결국 Tap 정보를 통하여 해당 PID로 전송되는 NRT서비스 시그널링 채널의 IP Multicast address (혹은 address range)를 알 수 있게 된다.
따라서, 수신기는 상기 IP Multicast address (혹은 address range)에 접속하여 IP 스트림 즉, IP 패킷을 수신하고, 상기 수신된 IP 패킷으로부터 NRT 서비스 시그널링 데이터를 추출한다.
수신기는 상기 추출된 NRT 서비스 시그널링 데이터를 기초로, NRT 서비스 데이터 즉, NRT 컨텐트 아이템/파일들을 수신하여 저장 매체에 저장하거나, 디스플레이 장치에 표시할 수 있다.
한편, 본 발명의 일 실시예에 따르면 상술한 NRT 서비스는 DCD(Dynamic Content Delivery) 서비스를 통해 제공될 수 있다. DCD 서비스는 수신기로 전송하는 컨텐츠를 주기적으로 또는 사용자가 원할 때 전송하는 서비스로서, 이 때의 컨텐츠는 수신기의 정보에 따라 서버세어 선택된 것을 의미한다. DCD 서비스는 컨텐츠 전달을 위한 통신 수단을 점대점(point-to-point) 방식과 브로드캐스트(broadcast) 방식을 지원하며, 본 발명은 상술한 NRT 서비스를 DCD서비스의 브로드캐스트 방식 중 하나인 OMA BCAST방식으로 전송하는 것을 일 실시예로 한다.
이와 같은 OMA BCAST방식의 DCD 서비스를 통해 NRT 서비스 데이터를 전송할 수 있다. 이 경우, 수신기는 NRT 서비스를 수신하기 위한 DCD 채널 정보를 획득하고, DCD 채널 정보에 기초하여 해당 DCD 채널을 통해 NRT 서비스를 수신할 수 있다.
그리고, 이와 같은 DCD 채널 정보는 상술한 NST에 포함되어 전송될 수 있다. 예를 들어, 수신기는 NST를 수신하고, DCD 부트스트랩(bootstrap)을 수행하여 DCD 채널 정보를 획득할 수 있다.
또한, 상술한 NST는 DCD 채널 정보의 시그널링을 위해 DCD 관리자 채널(Administrative channel)을 통해 수신할 수 있는 DCD 채널 메타데이터를 포함할 수 있다. 따라서, 수신기는 NST를 통해 NRT 서비스를 수신할 수 있는 채널에 대한 정보와 메타데이터를 획득할 수 있다.
따라서, NST에 DCD 채널 정보를 포함하여 전송하는 경우, 상술한 NRT 서비스 시그널링 데이터의 전송 과정 없이 NST를 통하여 DCD 채널에 접속하고, NRT 서비스를 수신할 수 있다.
이와 같이, 본 발명의 일 실시예에 따라 NST에 NRT 서비스를 수신할 수 있는 채널의 메타데이터가 포함되는 경우에는 몇 가지 장점이 있다.
먼저, 상술한 가상 채널의 서비스 타입에 기초하여 NRT 서비스 시그널링 데이터를 수신하는 과정 없이, NST에서 바로 NRT 서비스를 수신할 수 있는 채널 메타데이터를 수신함으로써 서비스 접근 속도를 높일 수 있다.
또한, 브로드캐스트(broadcast)환경에서 채널 변경 사항에 대한 업데이트 시그널링을 실시간으로 수행할 수 있다.
그리고, OMA BCAST SG에 포함되는 접속 정보를 NST를 참조함으로써 획득할 수 있게 된다. 예를 들어, 수신기는 NST에 포함된 DCD 채널 정보에 기초하여 DCD 채널 메타데이터를 수신하고, NST에서 획득한 NRT 서비스 시그널링 데이터와 DCD 채널 메타데이터에 기초하여 NRT 서비스를 수신하기 위한 접속 정보를 획득할 수 있다.
마지막으로, NST에 다른 가상 채널에 연계된 NRT 서비스의 목록을 포함하여 전송할 수 있다. 따라서, 이 경우 NRT 서비스의 목록 정보는 PSI또는 PSIP 계층이 아닌 IP계층을 통해 특정 NRT 서비스 시그널링 채널을 통해 전송될 수 있다. 따라서, 이 경우에는 PSI 또는 PSIP과의 하위 호환성이 보존될 수 있다.
한편, 상술한 바와 같이 DCD 채널 메타데이터를 포함하는 DCD 채널 정보는 OMA BCAST의 SG의 접속 정보에 포함될 수 있으며, 상기 접속 정보는 NST에 포함된 NRT 서비스 정보에 대응될 수 있다. 좀 더 구체적으로, 수신기는 OMA BCAST SG의 접속 정보(Access fragment)로부터 NST에 포함된 NRT 서비스 정보를 획득할 수 있다. 따라서, 수신기는 획득한 NRT 서비스 정보에 대응하는 NST를 수신하여 NRT 서비스를 수신하기 위한 정보를 획득할 수 있다.
한편, 이와 같은 DCD 채널을 통해 전송되는 NRT 서비스는 서비스 카테고리를 별도 할당하여 구분할 수 있다. 예를 들어, DCD 채널을 통해 전송되는 NRT 서비스의 서비스 카테고리는 0X0F로 식별될 수 있다.
도 12 및 도 13은 본 발명의 일 실시 예에 따라 구성한 NST의 비트스트림 신택스를 도시한 것이다.
여기서, 해당 신택스는 이해를 돕기 위하여 MPEG-2 프라이빗 섹션(Private section) 형태로 작성되었으나, 해당 데이터의 포맷은 어떠한 형태가 되어도 무방하다. 예를 들어, SDP(Session Description Protocol)의 형태로 표현하여 SAP(Session Announcement Protocol)을 통하여 시그널링하는 등의 다른 방법도 사용할 수 있다.
NST는 NST가 전송되는 가상 채널(virtual channel) 내의 서비스 정보 및 IP 접속 정보를 기술하며, 각 서비스가 속하는 NRT 브로드캐스트 스트림(Broadcast stream)의 인식자인 NRT_service_id를 이용, 해당 서비스의 NRT 브로드캐스트 스트림 정보 또한 제공한다. 그리고 본 실시 예에 따른 NST는 하나의 가상 채널 내의 각 고정 NRT 서비스의 서술(Description) 정보를 포함하며, 서술자(Descriptor) 영역에 기타 부가 정보들이 포함될 수 있다.
table_id 필드(8비트)는 해당 테이블 섹션의 타입 식별을 위한 필드로서, 본 필드를 통해 해당 테이블 섹션이 NST를 구성하는 테이블 섹션임을 알 수 있다.
section_syntax_indicator 필드(1비트)는 NST의 섹션 형식을 정의하는 지시자로서, 섹션 형식은 예를 들어, MPEG의 short-form 신택스(0) 등이 될 수 있다.
private_indicator 필드(1비트)는 해당 섹션의 형태가 프라이빗 섹션 형태를 따르는지 여부를 나타내며 '1'로 설정되어 있다.
section_length 필드(12비트)는 해당 필드 이후의 나머지 테이블 섹션 길이를 나타낸다. 또한 이 필드의 값은 '0xFFD'를 넘지 않는다.
table_id_extension 필드(16비트)는 테이블에 종속적이고, 남은 필드들의 범위를 제공하는 table_id 필드의 논리적인 부분이 된다. 여기서, table_id_extension 필드는 NST_protocol_version 필드를 포함한다.
NST_protocol_version 필드(8비트)는 현재 프로토콜 내에서 정의된 것들과 다른 구조를 가지는 파라미터들이 전송되는 NST를 알려주기 위한 프로토콜 버전을 알려준다. 현재, 이 필드 값은 0이다. 나중에 0이 아닌 값으로 필드값이 지정되면 다른 구조를 갖는 테이블을 위해서다.
version_number 필드(5비트)는 NST의 버전 넘버를 나타낸다.
current_next_indicator 필드(1비트)는 전송된 NST 테이블 섹션이 현재 적용 가능한지 여부를 지시한다. 이 필드 값이 0이면, 아직 테이블이 존재 하지 않고 다음 테이블에 유효함을 의미한다.
section_number 필드(8비트)는 해당 테이블 섹션이 NST 테이블을 구성하는 섹션들 내 섹션 넘버를 나타낸다.
NRT Service Table (NST)의 첫 섹션의 section_number는 '0x00'으로 설정된다. section_number는 NRT 서비스 테이블(Service Table)의 섹션이 늘어갈때마다 하나씩 증가한다.
last_section_number 필드(8비트)는 NST 테이블을 구성하는 마지막 섹션 번호를 나타낸다. (가장 높은 section_number)
carrier_frequency 필드(32비트)는, 채널에 대응하는 전송 주파수를 알려준다.
channel_TSID 필드(16비트)는 해당 NST 섹션이 전송되고 있는 방송 스트림의 고유한 채널 식별자(Identifier)를 의미한다.
program_number 필드(16비트)는, 가상 채널과 연관된 프로램의 번호를 나타낸다.
source_id 필드(16비트)는, 가상 채널과 연관된 프로그램의 소스를 나타낸다.
num_NRT_services 필드(8비트)는 NST 섹션 내의 NRT 서비스의 수를 나타낸다.
한편, 본 실시 예에 따른 NST는, for loop를 사용하여 복수의 고정 NRT 서비스에 대한 정보를 제공한다. 이하 각 고정 NRT 서비스에 대해 다음과 동일한 필드 정보를 제공할 수 있다.
NRT_service_status 필드(2비트)는 해당 모바일 서비스의 상태를 식별한다. 여기서, MSB는 해당 모바일 서비스가 액티브(1)인지 아니면 인액티브(0)인지 지시하고, LSB는 해당 모바일 서비스가 히든(1)인지 아닌지(0)를 지시한다. 여기서, 상기 모바일 서비스가 NRT 서비스라면, 해당 NRT 서비스의 상태를 식별할 것이다. 히든 서비스는 주로 독점 어플리케이션을 위해 사용되고, 일반 수신기는 이를 무시한다.
SP_indicator 필드(1비트)는, 해당 모바일 서비스의 의미 있는 프리젠테이션을 제공하기 위해 필요한 컴포넌트들 중 적어도 하나에 적용되는 서비스 프로텍션이 설정되었으면 이를 나타내기 위한 필드이다.
CP_indicator 필드(1비트)는 해당 NRT 서비스의 컨텐트 보호(content protection) 여부를 나타낸다. 만일 CP_indicator 필드 값이 1이면, 컨텐트 보호가 해당 NRT 서비스의 의미 있는 프리젠테이션을 제공하기 위해 요구되는 콤포넌트들 중 적어도 하나에 적용됨을 의미할 수 있다.
NRT_service_id 필드(16비트)는, 해당 NRT 브로드캐스트의 범위 내의 해당 NRT 서비스를 유일하게 식별하는 지시자이다. 상기 NRT_service_id는 해당 서비스를 통틀어 변하지 않는다. 여기서, 혼동을 피하기 위해 서비스가 종료되면, 상기 서비스를 위한 NRT_service_id는 적절한 시간이 경과한 후까지 다른 서비스를 위하여 사용되지 않을 수 있다.
Short_NRT_service_name 필드(8*8비트)는 상기 NRT 서비스의 숏 네임(short name) 을 표시한다. 상기 NRT 서비스의 short name이 없으면, 상기 필드는 널 값(예, 0x00)으로 채워질 수 있다.
NRT_service_category 필드(6비트)는, 해당 NRT 서비스 내에 전송되는 서비스의 타입을 식별한다.
num_components 필드(5비트)는 상기 NRT서비스에 포함되는 IP 스트림 콤포넌트들의 개수를 표시한다.
IP_version_flag 필드(1비트)는 '0'로 설정된 경우에는 source_IP_address 필드, NRT_service_destination_IP_address 필드 및 component_destination_IP_address 필드가 IPv4 어드레스임을 지시하고, '1'으로 설정된 경우에는 source_IP_address 필드, NRT_service_destination_IP_address 필드, component_destination_IP_address 필드가 IPv6 어드레스임을 지시한다.
source_IP_address_flag 필드(1비트)는 플래그가 설정되면, 해당 NRT 서비스를 위한 소스 IP 어드레스 값이 소스 특정 멀티캐스트를 지시하기 위해 존재함을 지시한다.
NRT_service_destination_IP_address_flag 필드(1비트)는 플래그가 '1' 설정되면, 해당 NRT 서비스의 콤포넌트들을 위한 디폴트 IP 어드레스를 제공하기 위한 NRT_service_destination_IP_address 필드가 존재함을 지시한다.
source_IP_address 필드(128비트)는 source_IP_address_flag가 1로 설정되면 해당 필드는 존재하지만, source_IP_address_flag가 0으로 설정되면 해당 필드는 존재하지 않을 것이다. 만약 해당 필드가 존재한다면, 해당 필드는 해당 NRT 서비스의 컴포넌트들을 전송하는 모든 IP 데이터그램들의 소스 IP 어드레스를 포함할 것이다. 해당 필드의 128 비트의 롱 어드레스의 제한적인 사용은 비록 현재 IPv6의 사용이 정의되지 않았지만 향후 IPv6의 사용을 가능하도록 하기 위함이다. Source_IP_address는 FLUTE 세션의 모든 채널을 전송하는 동일한 서버의 소스 IP 어드레스(source IP address)가 된다.
NRT_service_destination_IP_address 필드(128비트)는 source_IP_address_flag가 1로 설정되면 해당 source_IP_address 필드는 존재하지만, source_IP_address_flag가 0으로 설정되면 해당 source_IP_address 필드는 존재하지 않을 것이다. 만약 해당 source_IP_address 필드가 존재하지 않는다면, component_destination_IP_address 필드는 num_components 루프 내에 각 컴포넌트를 위해 존재할 것이다. 해당 source_IP_address 필드의 128 비트의 롱 어드레스의 제한적인 사용은 비록 현재 IPv6의 사용이 정의되지 않았지만 향후 IPv6의 사용을 가능하도록 하기 위함이다. NRT_service_destination_IP_Address는 이 FLUTE 세션의 세션 레벨의 목적 IP 어드레스(destination IP address)가 있으면 시그널링 된다.
한편, 본 실시 예에 따른 NST는, for loop를 사용하여 복수의 컴포넌트에 대한 정보를 제공한다. essential_component_indicator 필드(1비트)는, 해당 필드의 값이 1로 설정되어 있으면 해당 컴포넌트는 NRT서비스를 위한 필수 컴포넌트 임을 지시한다. 그렇지 않으면, 해당 컴포넌트는 선택적인 컴포넌트임을 나타낸다.
port_num_count 필드(6비트)는 해당 UDP/IP 스트림 컴포넌트와 관련된 UDP 포트들의 넘버를 지시한다. 목적 UDP포트 넘버들의 값은 component_destination_UDP_port_num 필드 값으로부터 시작해서 하나씩 증가한다.
component_destination_IP_address_flag 필드(1비트)는 1로 설정되어 있으면 해당 컴포넌트를 위해 component_destination_IP_address 필드가 존재함을 나타내는 플래그이다.
component_destination_IP_address 필드(128비트)는 component_destination_IP_address_flag가 1로 설정되면 해당 필드는 존재하지만, component_destination_IP_address_flag가 0으로 설정되면 해당 필드는 존재하지 않을 것이다. 만약 해당 필드가 존재한다면, 해당 필드는 해당 NRT 서비스의 컴포넌트들을 전송하는 모든 IP 데이터그램들의 소스 IP 어드레스를 포함할 것이다. 해당 필드의 128 비트의 롱 어드레스의 제한적인 사용은 비록 현재 IPv6의 사용이 정의되지 않았지만 향후 IPv6의 사용을 가능하도록 하기 위함이다.
component_destination_UDP_port_num 필드(16비트)는 해당 UDP/IP 스트림 컴포넌트를 위한 목적 UDP 포트 넘버를 나타낸다.
num_component_level_descriptors 필드(4비트)는, 해당 IP 스트림 컴포넌트를 위한 추가 정보를 제공하는 서술자들의 수를 제공한다.
component_level_descriptors 필드는, 해당 IP 스트림 컴포넌트를 위한 추가 정보를 제공하는 하나 또는 그 이상의 디스크립터들을 식별한다.
num_NRT_service_level_descriptors 필드(4비트)는 해당 서비스를 위한 NRT 서비스 레벨 디스크립터들의 수를 나타낸다.
NRT_service_level_descriptor()은 해당 NRT 서비스를 위한 추가적인 정보를 제공하는 없거나 하나 이상의 서술자들을 식별한다. 여기에서, NRT 서비스에 대한 구체적인 서비스 타입을 알려줄 수 있다. 상기 구체적인 서비스 타입에는 예를 들어, 웹 컨텐츠를 제공하는 포털 서비스, 푸쉬 VOD, A/V 다운로드 등이 있을 수 있다.
num_virtual_channel_level_descriptors 필드(4비트)는 해당 가상 채널을 위한 가상 채널 레벨 서술자들의 수를 설명한다.
virtual_channel_level_descriptor()은 해당 NST가 서술하는 가상 채널에 대한 추가 정보를 제공하는 서술자를 나타낸다.
한편, NRT 서비스는 FLUTE를 통해 전송되며 NST 테이블 상의 접속 정보는 다음과 같이 FLUTE 세션 정보와 연결된다.
Source_IP_address는 FLUTE 세션(session)의 모든 채널을 전송하는 동일한 서버의 source IP 주소가 된다.
NRT_service_destination_IP_Address는 이 FLUTE 세션의 세션 레벨의 destination IP address가 있을 경우 시그널링된다.
Component는 FLUTE 세션 내의 채널에 매핑될 수 있으며 각 채널별로(세션 단위로 시그널링된 IP address와 다른) 별도의 destination IP address를 component_destination_IP_address를 통해 시그널링 할 수 있다.
또한, component_destination_UDP_port_num를 통해 destination port number를 시그널링하고 port_num_count를 통해 component_destination_UDP_port_num로부터 시작하는 목적 포트의 개수를 추가로 지정할 수 있다.
포트를 복수 개로 지정함으로써 하나의 목적 IP 어드레스에 대해 복수 개의 채널을 구성할 수도 있다. 여기서 하나의 컴포넌트는 복수 개의 채널을 지정할 수 있다. 그러나 일반적으로 목적 IP 어드레스를 통해 채널을 구별하는 것이 바람직하다. 여기서, 하나의 채널은 하나의 컴포넌트로 매핑된다고 볼 수 있다.
NRT 서비스를 위한 컨텐트 아이템들/파일들은 FLUTE를 통해 전송되며, NST 테이블 상의 접속 정보를 이용하여 해당 FLUTE 세션 정보를 시그널링한다.
도 14는 본 발명의 일 실시 예에 따라 구성한 NRT_component_descriptor(MH_component_descriptor)의 비트 스트림 신택스를 도시한 것이다.
NRT_component_descriptor()는 NST 내 각 NRT 서비스의 각 컴포넌트의 컴포넌트 디스크립터 루프 내에 나타날 것이다. 그리고 해당 디스크립터 내 모든 파라미터들은 NRT 서비스의 컴포넌트들을 위해 사용되는 파라미터들에 상응한다.
이하 도 14의 NRT_component_descriptor를 통해 전송되는 각 필드 정보에 대해 기술하면 다음과 같다.
component_type 필드(7비트)는 컴포넌트의 인코딩 포맷을 식별한다. 상기 식별 값은 RTP/AVP 스트림의 payload_type을 위해 할당된 값들 중의 하나일 수 있다. 또한, 식별 값은 96에서 127까지의 범위 내 다이내믹 밸류(dynamic value)일 수 있다. RTP를 거쳐 전송되는 미디어를 구성하는 컴포넌트들을 위해 본 필드의 값들은 해당 컴포넌트를 전송하는 IP 스트림의 RTP 헤더 내 payload_type 내 값들과 일치한다.
43에서 71까지의 범위 내 component_type 필드의 추가 값은 표준의 미래 버전에서 정의된다. NRT 서비스 스트림을 FLUTE 기반으로 전송할 경우에 FLUTE 세션에 대해 필요한 아래에 기술할 파라미터들을 추가로 시그널링하기 위하여 ATSC에서 FLUTE 컴포넌트를 위해 정의한 component_type인 38을 사용할 수도 있고, 아직 할당되지 않은 값인 43을 새로이 NRT 전송을 위한 component_type으로 정의하 여 쓸 수도 있다.
num_STKM_streams 필드(8비트)는, 해당 컴포넌트와 관련된 STKM 스트림들의 넘버를 식별한다.
STKM_stream_id 필드(8비트)는, 얻어진 해당 보호된 컴포넌트를 디크립트하기 위해 키들을 있는 STKM 스트림을 식별한다. 여기서, 상기 STKM 스트림을 위한 상기 컴포넌트 디스크립터 내에 STKM_stream_id 필드를 참조한다.
NRT_component_data(component_type) 필드는, 해당 컴포넌트를 표현하기 위해 필요한 인코딩 파라미터들 및 다른 파라미터들 중 적어도 하나를 제공한다. 여기서, NRT_component_data 엘리먼트의 구조는 component_type 필드의 값에 의해 결정된다.
FLUTE 세션들의 FDT(File Delivery Table)는 모든 컨텐트 아이템들의 아이템 리스트들을 전달하는데 사용되고, 상기 아이템들을 획득하는데 관련된 아이템들의 사이즈, 데이터 타입과 다른 정보들을 제공한다.
따라서, 본 발명은 NRT-IT를 사용해 구성된 SG로부터 선택된 컨텐트를 수신하기 위해 NST를 사용하여 해당 컨텐트를 전송하는 FLUTE 세션에 접속하기 위한 정보를 획득한다. 그리고, 본 발명은 해당 FLUTE 세션을 통해 전송되는 파일에 대한 정보를 NRT-IT의 컨텐트 아이템의 정보와 함께 맵핑한다. 이 경우에는, 선택된 컨텐트 아이템을 포함한 서비스의 식별은 상기 NST의 NRT_service_id를 통해 해결된다.
NRT 서비스는 FLUTE를 통해 전송되며 NST 테이블 상의 접속 정보는 다음과 같이 FLUTE 세션 정보와 연결된다.
Source_IP_address는 FLUTE 세션의 모든 채널을 전송하는 동일한 서버의 source IP 주소가 된다.
NRT_service_destination_IP_Address는 이 FLUTE 세션의 세션 레벨의 destination IP address가 있을 경우 시그널링된다.
Component는 FLUTE 세션 내의 채널에 매핑될 수 있으며 각 채널별로 (세션 단위로 시그널링된 IP 어드레스와 다른) 별도의 destination IP address를 component_destination_IP_address를 통해 시그널링 할 수 있다. 또한, component_destination_UDP_port_num을 통해 destination port number를 시그널링하고 port_num_count를 통해 component_destination_UDP_port_num로 부터 시작하는 목적 포트의 개수를 추가로 지정할 수 있다.
포트를 복수 개로 지정함으로써 하나의 destination IP address에 대하여 복수 개의 채널을 구성할 수도 있으며 이와 동일한 경우 하나의 Component가 복수 개의 채널을 지정하게 된다. 그러나 일반적으로 Destination IP address를 통해 채널을 구별하는 것을 권장하며 이 경우 하나의 채널은 하나의 component로 매핑된다고 볼 수 있다.
세션을 구성하는 컴포넌트의 추가적인 속성(attribute)을 시그널링하기 위하여 component_attribute_byte를 사용할 수 있다. FLUTE 세션을 시그널링하기 위하여 필요한 추가적인 파라미터들을 이를 통해 시그널링할 수 있다.
이와 관련하여, FLUTE 세션을 시그널링하기 위해서는 파라미터들이 필요하고, 이러한 파라미터들에는 반드시 필요한 필수 파라미터들과 해당 FLUTE 세션과 관련되어 선택적으로 필요한 파라미터들이 있다. 우선, 필수 파라미터들에는 소스 IP 어드레스(source IP address), 세션 내 채널의 수(The number of channels in the session), 세션 내 각 채널을 위한 목적 IP 어드레스와 포트 넘버(The destination IP address and port number for each channel in the session), 세션의 TSI(The Transport Session Identifier (TSI) of the session) 및 세션의 시작 시간과 종료 시간(The start time and end time of the session) 파라미터가 포함되고, 해당 세션과 관련하여 선택적으로 필요한 파라미터에는, FEC 오브젝트 트랜스미션 정보(FEC Object Transmission Information), 관심 있는 파일들을 포함한 세션의 첫번째 수신 정보(Some information that tells receiver in the firstplace, that the session contains files that are of interest) 및 대역폭 상세(Bandwidth specification) 파라미터가 포함된다.
이 중 세션의 채널의 개수는 명시적으로 제공될 수도 있고, 세션을 구성하는 스트림의 개수를 합산하여 구할 수도 있다. 상기 파라미터들 중에서 NST 및 component_descriptor를 통해 세션의 시작 시간 및 종료 시간(start time and end time of the session), 소스 IP 어드레스(source IP address), 세션 내 각 체널의 목적 IP 어드레스 및 포트 넘버(destination IP address and port number for each channel in the session), 세션의 TSI(Transport Session Identifier(TSI) of the session) 및 세션 내 채널의 개수(number of channels in the session) 파라미터들이 시그널링될 수 있다.
도 15는 본 발명의 일 실시 예에 따라 구성한 NRT_component_data가 속한 NRT 컴포넌트 디스크립터의 비트 스트림 신택스를 도시한 것이다.
하나의 NRT 서비스는 멀티플 FLUTE 세션들에 포함될 수 있다. 각 세션은 세션을 위해 사용되는 IP 어드레스들과 포트들에 의존하는 하나 또는 그 이상의 NRT 컴포넌트 디스크립터들을 이용하여 시그널링 될 수 있다.
이하 NRT_component_data의 각 필드에 대해 상세하게 설명하면, 다음과 같다.
TSI 필드(16비트)는 FLUTE 세션의 TSI를 나타낸다.
session_start_time 필드는 FLUTE 세션이 시작하는 시각을 지시한다. 만약 해당 필드의 값이 모두 0이면, 세션은 이미 시작된 것으로 해석될 수 있다.
session_end_time 필드는 FLUTE 세션이 종료되는 시각을 지시한다. 만약 해당 필드의 값이 모두 0이면, 세션은 무한정 계속되는 것으로 해석될 수 있다.
tias_bandwidth_indicator 필드(1비트)는 TIAS(Transport Independent Application Specific) 대역폭 정보를 포함하는 플래그들을 지시한다. 만약 TIAS 대역폭 필드가 존재하는 것으로 지시하려면 해당 비트는 1로 설정되고, TIAS 대역폭 필드가 존재하지 않는 것으로 지시하려면 해당 비트는 0으로 설정되어야 한다.
as_bandwidth_indicator 필드(1비트)는 AS(Application Specific) 대역폭 정보를 포함하는 플래그들이다. 만약 AS 대역폭 필드가 존재하는 것으로 지시하려면 해당 비트는 1로 설정되어야 하고, AS 대역폭 필드가 존재하지 않는 것으로 지시하려면 해당 비트는 0으로 설정되어야 한다.
FEC_OTI_indicator 필드(1비트)는 FEC 오브젝트 트랜스미션 정보(OTI) 정보가 제공되는지 여부를 나타낸다.
tias_bandwidth 필드는 TIAS 최대 대역폭을 나타낸다.
as_bandwidth 필드는 AS 최대 대역폭의 값을 갖는다.
FEC_encoding_id 필드는 해당 FLUTE 세션 내에서 사용된 FEC 인코딩 ID를 나타낸다.
FEC_instance_id 필드는 해당 FLUTE 세션 내에서 사용된 FEC 인스턴스 ID를 나타낸다.
상기와 동일한 파라미터들을 FLUTE 컴포넌트 데이터 바이트들(FLUTE component data bytes)을 통해 시그널링함으로써 FULTE 세션을 수신하기 위해 꼭 필요한 정보들은 모두 제공할 수 있으며, 이 세션을 통해 FDT를 수신하여 이를 통해 FLUTE 세션을 통해 전달되는 모든 파일들에 대한 정보를 획득하여 이 파일들을 수신하는 방법이 사용될 수 있다.
이 FLUTE 컴포넌트 디스크립터(FLUTE component descriptor)는 NST의 Component_level_descriptor 루프를 통해 전달될 수 있다. FLUTE 채널이 복수 개일 경우에는 세션 레벨의 파라미터들인 TSI, session_start_time, session_end_Time 등은 한 번만 시그널링 되어야 하므로 여러 개의 채널의 컴포넌트 중에서 하나의 컴포넌트에서만 FLUTE 컴포넌트 디스크립터를 Component_level_descriptor 루프를 통해 전송할 수도 있다.
도 16은 본 발명의 일 실시 예에 따라 구성한 NRT 어플리케이션을 시그널링 하기 위한 NRT-IT 섹션의 비트스트림 신택스를 도시한 것이다.
NRT-IT에서 제공되는 정보는 컨텐트의 제목(예를 들어, 다운로드 가능한 프로그램의 이름), 다운로드 가능한 시간 및 정보 예컨대, 컨텐트 권고(content advisories), 캡션 서비스의 가용성(availability), 컨텐트 식별 및 다른 메타데이터를 포함한다. 컨텐트의 하나의 아이템은 하나 이상의 파일로 구성될 수도 있다. 예를 들어, 오디오/비디오 클립은 화면 디스플레이하는 데 사용할 수 있는 JPEG 축소 이미지(thumbnail image)로 재생할 수 있다.
NRT-IT의 인스턴스(instance)는 임의로 정의된 기간에 해당하는 데이타를 포함할수 있고 또는 지정된 시간에서 시작되고 무기한 미래에 끝나는 NRT 컨텐트를 서술할 수도 있다. 각 NRT-IT는 시작시간 및 무기한일 수 있는 지속기간을 나타낸다. 각 NRT-IT 인스턴스는 무려 256 섹션들로 분할될 수 있다. 각 섹션은 다수의 컨텐트 아이템의 정보를 포함하지만 특정 컨텐트 아이템의 정보는 분할될 수 없고 두 개 이상의 섹션들 안에 저장될 수 없다.
하나 이상의 NRT-IT 인스턴스가 걸리는 기간에 비해 연장된 다운로드 가능한 컨텐트 아이템은 이 NRT-IT 중에 첫 번째만 서술된다. 컨텐트 아이템 서술은 가용성 순서로 NRT_information_table_section()에 저장된다. 따라서, last_section_number의 값이 0보다 클 경우에(NRT-IT가 다수의 섹션에 전송됐음을 의미함), 첫 번째 섹션이 아닌 특정한 섹션의 모든 컨텐트 아이템 서술은 다음 섹션의 컨텐트 아이템 서술의 첫 가용성과 같거나 높은 첫 가용성을 지닐 것이다.
각 NRT-IT는 상기 기간 동안 특정 가상 채널에서 유효한 service_id의 특정 값과 관련된 NRT 서비스를식별한다.
table_id 필드(8비트)는 해당 테이블 섹션이 NRT-IT을 구성하는 테이블 섹션임을 식별하기 위해 0xTBD로 설정된다.
service_id 필드(16비트)는, 상기 섹션에서 기술하는 컨텐트 아이템을 보여주는 NRT 서비스와 관련된service_id 필드를 설명한다.
NRT_IT_version_number 필드(5비트)는 service_id, current_next_indicator, protocol_version 및time_span_start 필드에 대한 공통적인 값을 가진 하나 이상의 NRT_content_table_section()에 세트로 정의된다. NRT-IT 인스턴스의 버전 넘버를 식별한다. 버전 넘버는 NRT-IT 인스턴스의 필드가 변화할 경우에 1 modulo 32만큼 증가한다.
current_next_indicator 필드(1비트)는 1로 설정되어 있으면 해당 테이블 섹션은 현재 적용 가능함을 나타낸다.
protocol_version 필드(8비트)는 0으로 설정된다. protocol_version의 기능은 미래에 현재 프로토콜에 정의된 것보다 구조적으로 다를 수 있는 파라미터를 가진 테이블 유형을 허용한다. 현재는 protocol_version의 유일한 유효값은 0이다. protocol_version에서 0이 아닌 값은 구조적으로 다른 테이블을 인식하는 표준의 미래 버전으로 사용된다.
time_span_start 필드(32비트)는 00:00:00 UTC, January 6, 1980부터 GPS 초의 수로 표현된 NRT-IT의 인스턴스 기간의 시작을 보여준다. time_span_start의 하루 중 시간은 시간의 분 00에 맞춰야 한다. time_span_start의 값 0은 부정과거에서 시작된 NRT-IT 인스턴스의 기간을 보여준다. time_span의 값은 복수섹션된 NRT-IT 인스턴스의 각 섹션마다 같다. time_span_start 및 time_span_length의 값은 지정된 기간에서 IP 서브넷의 다른 NRT-IT 인스턴스와 중복되지 않게 설정된다.
time_span_length 필드(11비트)는 NRT-IT의 상기 인스턴스가 커버한 time_span_start에서 인식된 시간에 시작된 분의 수를 식별한다. 한번 설정된 경우에, 부여된 time_span_start의 값에서 time_span_length의 값은 변경되지 않는다. time_span_length의 값이 0일 경우에 NRT-IT 인스턴스가 무기한 미래에서 time_span_start에서 시작된 모든 시간을 커버한다. time_span_start의 값이 0일 경우에, time_span_length는 의미가 없다.
time_span_start의 값은 복수섹션된 NRT-IT 인스턴스의 각 섹션마다 같다. time_span_start 및 time_span_length의 값은 지정된 기간에서 IP 서브넷의 다른 NRT-IT 인스턴스와 중복되지 않게 설정된다.
num_items_in_section 필드(8비트)는 NRT-IT 섹션에서 서술된 컨텐트 아이템의 수를 나타낸다.
content_linkage 필드(16비트)는 0x0001에서 0xFFFF까지의 범위 내 컨텐트의 식별번호를 나타낸다. 값 0x0000은 사용되지 않는다. content_linkage는 두개의 결합(linkage) 기능: NRT 서비스와 관련된 FLUTE FDT의 하나 이상의 파일을 NRT-IT의 메타데이터를 결합 및 TF_id (identifier for Text Fragement in Text FragmentTable)도 형성한다. content_linkage 필드의 값은 컨텐트 아이템과 관련된 각 파일의 FLUTE FDT에서 FDTCotent-Linkage 엘리먼트의 값 또는 File-Content-Linkage 엘리먼트의 값에 해당한다. 우선순위 규칙은 FLUTE FDT 내 해당 컨텐트 결합 엘리먼트(content linkage element)를 포함한 각 content_linkage 값을 매칭할 경우에 적용된다.
TF_availiable 플래그(boolean flag)는 Text Fragment가 서비스 시그널링 채널의 Text Frangment Table에서 존재하면 '1'로 설정된다. 만일 Text Fragment가 상기 컨텐트 아이템를 위한 서비스 시그널링 채널에 포함되지 않으면, 상기 TF_availiable 필드의 값은 '0'으로 설정된다.
low_lantency 플래그(boolean flag)는 '1'로 설정될 경우에 사용자가 기다릴때 회수가 시도해야하는 충분히 낮은 지연시간의 현재 디지털 전송에서 컨텐트가 유효한다. 만일, '0'으로 설정될 경우에는 회수 지연시간이 더 길고 사용자 인터페이스는 사용자에게 나중에 보기를 제안한다.
playback_length_in_seconds (20비트)는 컨텐트의 재생시간을 초로 나타내는 정수이다. 텍스트 및/또는 정지영상을 포함하는 컨텐트는 값 '0'으로 나타난다. 오디오 또는 오디오/비디오 컨텐트를 포함하는 컨텐트는 playback_length_in_seconds는 오디오 또는 오디오/비디오 컨텐트의 재생시간을 나타낸다.
content_length_included 플래그(boolean flag)는 '1'로 설정될 경우에 content_length 필드는 'for' 루프의 반복에서 존재하는 것을 나타낸다. 만일 '0'으로 설정될 경우에는 content_length 필드는 'for' 루프의 반복에서 존재하지 않는 것을 나타낸다.
playback_delay_included 플래그(boolean flag)는 '1'로 설정될 경우에 playback_delay 필드는 'for' 루프의 반복에서 존재하는 것을 나타낸다. 만일 '0'으로 설정될 경우에는 playback_delay 필드는 'for' 루프의 반복에서 존재하지 않는 것을 나타낸다.
expiration_included 플래그(boolean flag)는 '1'로 설정될 경우에 expiration 필드는 'for' 루프의 반복에서존재하는 것을 나타낸다. 만일 '0'으로 설정될 경우에는 expiration 필드는 'for' 루프의 반복에서 존재하지 않는 것을 나타낸다.
duration (12비트)필드는 1에서 2880까지의 범위 내 참조된 컨텐트 아이템을 포함하는 카루젤(carousel)의 예정된 사이클 시간을 분으로 나타낸다. 수신기는 참조된 컨텐트를 캡처하는 시간량을 결정하는 기간 한도(duration parameter)를 사용한다.
playback_delay (20비트)는 들어오는 스트림을 버퍼링하는 동안, 관련된 컨텐트에서 재생하기 전에 첫번째 바이트의 수신 다음의 초의 수로 표현된다. 값 0은 재생이 즉시 시작된 것을 나타낸다. playback_delay가 설정되지않을 경우에는 수신기는 완전한 파일 또는 재생하기 전의 파일을 회수한다.
expiration 필드(32 비트)는 00:00:00 UTC, January 6, 1980부터 GPS 초의 수로 표현된 만료 시간 (expirationtime)을 나타낸다. 만료 후에는, 컨텐트는 메모리에서 삭제된다. 만료 시간이 설정되지 않았을 경우에는 수신기는 메모리 리소스를 관리하는 자사 선택 방법을 사용한다.
content_name_length_ 필드(8비트)는 content_name_text의 길이(바이트 단위)를 나타낸다.
content_name_text() 필드는 복수 스트링 구조의 체재에서 컨텐트 아이템 제목을 나타낸다.
content_descriptors_length 필드(12비트)는 켄텐트 레벨에 대한 추가적인 정보를 제공하는 content_descriptor의 전체길이(바이트 단위)를 나타낸다.
content_descriptor는 각 컨텐트 아이템에 별도로 적용되는 디스크립터이다.
descriptor_length (10비트)는 디스크립터의 전체 길이(바이트 단위)를 나타낸다.
descriptor는 현재 NRT-IT 섹션에서 서술된 모든 컨텐트 아이템에 일반적으로 적용되는 디스크립터이다.
도 17은 본 발명에 따른 NCT섹션(NRT_content_table_section)에 대한 비트 스트림 신택스 구조의 일 실시예를 보인 도면이다. 상기 NCT 섹션의 각 필드의 상세한 설명은 다음과 같다.
도 17에서 table_id 필드(8비트)는 테이블의 식별자로서, NCT를 식별하는 식별자가 설정될 수 있다.
section_syntax_indicator 필드(1비트)는 NCT의 섹션 형식을 정의하는 지시자이다.
private_indicator 필드(1비트)는 NCT가 private section을 따르는지 여부를 나타내낸다.
section_length 필드(12비트)는 NST의 섹션 길이를 나타낸다.
NRT_channel_id 필드(16 비트)는 NCT에서 기술하는 컨텐트를 포함하는 NRT 서비스를 유일하게 식별할 수 있는 값을 표시한다.
version_number 필드(5비트)는 NCT의 버전 번호를 나타낸다.
current_next_indicator 필드(1비트)는 해당 NCT 섹션이 포함하는 정보가 현재 적용 가능한 정보인지, 미래 적용 가능한 정보인지를 나타낸다.
section_number 필드(8비트)는 현재 NCT 섹션의 섹션 번호를 나타낸다.
last_section_number 필드(8비트)는 NCT의 마지막 섹션 번호를 나타낸다.
protocol_version 필드(8비트)는 현재 프로토콜 내에서 정의된 것들과 다른 구조를 가지는 파라미터들을 전송하는 NCT를 허용하기 위한 프로토콜 버전을 알려준다(An 8-bit unsigned integer field whose function is toallow, in the future, this NRT Content Table to carry parameters that may be structured differently than those defined in the current protocol. At present, the value for the protocol_version shall be zero. Non-zero values of protocol_version may be used by a future version of this standard to indicate structurally different tables.)
num_contents_in_section 필드(8비트)는 이 NCT에서 기술하는 컨텐트의 개수를 표시한다. 이때 상기 컨텐트의 개수는 source_id로 특정(specify)된 가상 채널을 통해 전송되는 컨텐트(또는 파일)의 개수를 나타낸다.
이후 상기 num_contents_in_section 필드 값에 해당하는 컨텐트 개수만큼 'for' 루프(또는 컨텐트 루프라 함)가 수행되어 각 컨텐트별로 해당 컨텐트의 상세 정보를 제공한다.
content_version 필드(32비트)는 특정 content_id 값을 갖는 content (또는 file)에 대한 version 번호를 표시한다. 즉, 수신기가 이전에 수신하여 저장한 컨텐트의 content_id가 0x0010이라 하고, 동일한 content, 즉 content_id 값이 0x0010인 컨텐트가 전송되었다고 가정하자. 이때 상기 content_version필드 값이 변경되면, 상기 NCT를 통해 새롭게 announce 된 컨텐트를 수신하여 이전에 저장된 컨텐트를 업데이트하거나, 재배치(replace) 하도록 한다. 본 실시 예에서는 상기 content_version 필드 값이 release의 version을 나타내는 일련 번호를 의미하나 실제로 published (released) time을 직접 표현할 수도 있다. 이때, 상기 content_version필드로 publish time이 표현하기 힘들 경우에 published (released) time을 표현할 수 있는 새로운 필드를 사용할 수도 있다.
content_id 필드(16비트)는 상기 컨텐트(또는 파일)를 유일하게 식별할 수 있는 식별자를 표시한다.
content_available_start_time 필드(32비트)와 content_available_end_time 필드(32비트)는 상기 컨텐트를 전송하는 FLUTE 세션의 시작 시간과 종료 시간을 표시한다.
ETM_location 필드(2비트)는, ETM(extended text message)의 존재(existence) 유무와 위치(location)를 설명한다.
content_length_in_seconds 필드(30비트)는 상기 컨텐트(또는 파일)이 A/V 파일인 경우에 해당 컨텐트의 실제 재생 시간을 초 단위로 나타낸다.
content_size필드(48비트)는 상기 컨텐트(또는 파일)의 크기를 바이트 단위로 나타낸다.
content_delivery_bit_rate 필드(32비트)는 상기 컨텐트(또는 파일)을 전송하는 전송 속도(bit rate)를 표시하며, target bit rate를 의미한다. 즉, service provider 또는 방송국이 해당 content를 전송할 때 얼마만큼의 밴드폭(bandwidth)을 할당(allocate)할지를 표시한다. 따라서 수신기에서 content_size 및 content_delivery_bit_rate를 이용하면, 해당 컨텐트(또는 파일)을 수신하는데 소요되는 최소 시간(minimumtime)을 알 수 있다. 즉, 컨텐트를 수신하는데 걸리는 시간을 추정(estimation)하여 사용자에게 해당 정보를 제공할 수 있다. 그리고 최소 수신 소요 시간은 (conent_size * 8) / (content_delivery_bit_rate) 를 계산하여 얻어지며, 단위는 초 (seconds)이다.
content_title_length 필드(8비트)는 content_title_text()의 길이를 바이트 단위로 나타낸다. 이 필드를 이용하면, 수신기는 정확하게 content_title_text () 정보를 획득하기 위해 몇 바이트의 데이터를 읽어야 할 지를 알 수 있다.
content_title_text() 필드는 멀티플 스트링 구조 포맷으로 컨텐트 타이틀을 표시한다(content title in the format of a multiple string structure).
즉, 수신기에서는 상기 NCT를 이용하여 NRT 컨텐트/파일의 구성 정보를 획득하고, 획득한 NRT 컨텐트/파일의 구성 정보를 기초로 NRT 컨텐트/파일에 대한 가이드를 제공할 수 있다. 그리고 이 가이드로부터 선택된 컨텐트/파일을 전송하는 FLUTE 세션의 접속 정보를 NST로부터 획득하고, 획득한 FLUTE 세션 접속 정보를 이용하여 상기 선택된 컨텐트를 수신할 수 있다.
한편, 본 발명은 NRT 서비스를 구성하는 컨텐트/파일들의 렌더링(rendering)에 필수적인 컨테이너 정보, 인코딩 정보, 미디어 오브젝트의 디코딩 파라미터를 상기 NCT에 포함하여 전송할 수 있다. 따라서 수신 시스템에서는 각 컨텐트별로 해당 컨텐트의 렌더링(rendering)에 필수적인 컨테이너 정보, 인코딩 정보, 미디어 오브젝트의 디코딩 파라미터를 추출하여 해당 컨텐트의 렌더링에 이용할 수 있게 된다.
도 18은 NRT 서비스 데이터에 대한 시그널링 정보를 제공하는 SMT 섹션의 비트 스트림 신택스 구조에 대한 일 실시예를 보이고 있다.
여기서, 해당 신택스는 이해를 돕기 위하여 MPEG-2 프라이빗 섹션(Private section) 형태로 작성되었으나, 해당 데이터의 포맷은 어떠한 형태가 되어도 무방하다.
상기 SMT는 SMT가 전송되는 앙상블(Ensemble) 내의 모바일 서비스의 시그널링 정보(또는 NRT 서비스의 시그널링정보) 및 IP 접속 정보를 기술한다. 상기 SMT는 또한 각 서비스가 속하는 방송 스트림(Broadcast stream)의 인식자인 Transport_Stream_ID를 이용, 해당 서비스의 방송 스트림 정보를 제공한다. 그리고 본 발명의 실시예에따른 SMT는 하나의 앙상블 내의 각 모바일 서비스(또는 NRT 서비스)의 서술(Description) 정보를 포함하며, 디스크립터(Descriptor) 영역에 기타 부가 정보들이 포함될 수 있다.
상술한 바와 같이, SMT 섹션은 RS 프레임 내의 IP 스트림 형태로 포함되어 전송될 수 있다. 이 경우, 후술할 수신기의 RS 프레임 디코더들은 입력된 RS 프레임을 디코딩하고, 디코딩된 RS 프레임은 해당 RS 프레임 핸들러로 출력한다. 그리고 각 RS 프레임 핸들러는 입력된 RS 프레임을 로우(row) 단위로 구분하여 M/H TP를 구성하여 M/H TP 핸들러로 출력한다.
한편, SMT를 통해 전송될 수 있는 필드들의 예를 들면 다음과 같다.
table_id 필드(8비트)는 테이블의 타입을 구분시키기 위한 필드로서, 이를 통해 본 테이블 섹션이 SMT 내 테이블 섹션임을 알 수 있다(table_id: An 8-bit unsigned integer number that indicates the type of table section being defined in Service Map Table (SMT)).
section_syntax_indicator 필드(1비트)는 SMT의 섹션 형식을 정의하는 지시자로서, 섹션 형식은 예를 들어, MPEG의 short-form 신택스('0') 등이 될 수 있다(section_syntax_indicator: This 1-bit field shall be setto '0' to always indicate that this table is derived from the "short" form of the MPEG-2 privatesection table).
private_indicator 필드(1비트)는 SMT가 프라이빗 섹션을 따르는지 여부를 나타낸다(private_indicator: This1-bit field shall be set to '1').
section_length 필드(12비트)는 해당 필드 이후의 나머지 SMT의 섹션 길이를 나타낸다(section_length: A 12-bit field. It specifies the number of remaining bytes this table section immediately following this field. The value in this field shall not exceed 4093 (0xFFD)).
table_id_extension 필드(16비트)는 테이블 종속적이고, 남은 필드들의 범위를 제공하는 table_id 필드의 논리적인 부분이 된다(table_id_extension: This is a 16-bit field and is table-dependent. It shall be considered to be logically part of the table_id field providing the scope for the remaining fields).
여기서, table_id_extension 필드는 SMT_protocol_version 필드를 포함한다.
SMT_protocol_version 필드(8비트)는 현재 프로토콜 내에서 정의된 것들과 다른 구조를 가지는 파라미터들이 전송하는 SMT를 허락하기 위한 프로토콜 버전을 알려준다(SMT_protocol_version: An 8-bit unsigned integer field whose function is to allow, in the future, this SMT to carry parameters that may be structured differently than those defined in the current protocol. At present, the value for the SMT_protocol_version shall be zero. Non-zero values of SMT_protocol_version may be used by a future version of this standard to indicate structurally different tables).
ensemble_id 필드(8비트)는 해당 앙상블과 관련된 ID값으로, '0x00'에서 '0x3F'의 값들이 할당될 수 있다. 본 필드의 값은 TPC 데이터의 parade_id로부터 도출되는 것이 바람직하다. 만약 해당 앙상블이 프라이머리 RS 프레임을 통해 전송될 경우에는 가장 상위 비트(MSB)는 '0'으로 설정되며, 나머지 7비트는 해당 퍼레이드의 parade_id의 값으로 이용한다. 한편, 만약 해당 앙상블이 세컨더리 RS 프레임을 통해 전송될 경우에는 가장 상위 비트(MSB)는 '1'로 설정되며, 나머지 7비트는 해당 퍼레이드의 parade_id의 값으로 이용한다(ensemble_id: This 8-bit unsigned integer field in the range 0x00 to 0x3F shall be the Ensemble ID associated with this Ensemble. The value of this field shall be derived from the parade_id carried from the baseband processor of physical layer subsystem, by using the parade_id of the associated Parade for the least significant 7 bits, and using '0' for the most significant bit when the Ensemble is carried over the Primary RS frame, and using '1' for the most significant bit when the Ensemble is carried over the Secondary RS frame.).
version_number 필드(5비트) 는 SMT의 버전 번호를 나타낸다. current_next_indicator 필드(1비트)는 전송된 SMT 테이블 섹션이 현재 적용 가능한지 여부를 지시한다 (current_next_indicator: A one-bit indicator, which when set to '1' shall indicate that the Service Map Table sent is currently applicable. When the bit is set to '0', it shall indicate that the table sent is not yet applicable and will be the next table to become valid. This standard imposes no requirement that "next" tables (those with current_next_indicator set to '0') must be sent. An update to the currently applicable table shall be signaled by incrementing the version_number field).
section_number 필드(8비트)는 현재 SMT 섹션의 번호를 표시한다 (section_number: This 8-bit field shall give the section number of this NRT Service Signaling table section. The section_number of the first section in an NRT Service Signaling table shall be 0x00. The section_number shall be incremented by 1 with each additional section in the NRT Service Signaling table).
last_section_number 필드(8비트)는 SMT 테이블을 구성하는 마지막 섹션 번호를 나타낸다.
(last_section_number: This 8-bit field shall give the number of the last section (i.e., the section with the highest section_number) of the Service Signaling table of which this section is a part).
num_services 필드(8비트)는 SMT 섹션 내의 서비스의 개수를 지시한다. (num_services: This 8 bit field specifies the number of services in this SMT section.). 상기 SMT가 포함되는 앙상블로 적어도 하나의 모바일 서비스만 포함되어 수신될 수도 있고, 적어도 하나의 NRT 서비스만 포함되어 수신될 수도 있으며, 모바일 서비스와 NRT 서비스가 모두 포함되어 수신될 수도 있다. 만일 상기 SMT가 포함되는 앙상블로 NRT 서비스들만 포함되어 전송된다면, 상기 SMT에 포함되는 NRT 서비스의 개수를 지시할 수 있다
이후 상기 num_services필드 값에 해당하는 서비스 개수만큼 'for' 루프(또는 서비스 루프라 함)가 수행되어 복수의 서비스에 대한 시그널링 정보를 제공한다. 즉, 상기 SMT 섹션에 포함되는 서비스별로 해당 서비스의 시그널링 정보를 표시한다. 여기서, 서비스는 모바일 서비스일 수도 있고, NRT 서비스일 수도 있다. 이때 각 서비스에 대해 다음과 같은 필드 정보를 제공할 수 있다.
service_id 필드(16 비트)는 해당 서비스를 유일하게 식별할 수 있는 값을 표시한다(A 16-bit unsigned integer number that shall uniquely identify this service within the scope of this SMT section.). 하나의 서비스의 service_id 필드 값은 그 서비스가 유지되는 동안 변하지 않는다. 이때 혼란을 피하기 위해서, 만
일 어떤 서비스가 종료되면 그 서비스의 service_id 필드 값은 일정 시간이 경과할 때까지 사용하지 않을 수 있다(The 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 service_id for the service should not be used for another service until after a suitable interval of time has elapsed.). 여기서, 상기 서비스가 NRT 서비스라면, 상기 service_id는 상기 NRT 서비스를 식별할 것이다
Multi_ensemble_service 필드(2비트)는 해당 서비스가 하나 이상의 앙상블을 통해 전송되는지 여부를 식별한다.
또한, 해당 필드는 단지 서비스가 해당 앙상블을 통해 전송되는 서비스의 부분으로서 표현되는지 여부를 식별한다. 즉, 상기 서비스가 NRT 서비스라면, 상기 필드는 NRT 서비스가 하나 이상의 앙상블을 통해 전송되는지 여부를 식별한다(multi_ensemble_service: A two-bit enumerated field that shall identify whether the Service is carried across more than one Ensemble. Also, this field shall identify whether or not the Service can be rendered only with the portion of Service carried through this Ensemble.).
service_status 필드(2비트)는 해당 서비스의 상태를 식별한다. 여기서, MSB는 해당 서비스가 액티브('1')인지 아니면 인액티브('0')인지 지시하고, LSB는 해당 서비스가 히든('1')인지 아닌지('0')를 지시한다. 여기서, 상기 서비스가 NRT 서비스라면, 상기 service_status 필드의 MSB는 해당 NRT 서비스가 액티브('1')인지 아니면 인액티브('0')인지 지시하고, LSB는 해당 NRT 서비스가 히든('1')인지 아닌지('0')를 지시한다.
SP_indicator 필드(1비트)는 해당 서비스의 서비스 보호(service protection) 여부를 나타낸다. 만일 SP_indicator 필드 값이 1이면, 서비스 보호가 해당 서비스의 의미 있는 프리젠테이션을 제공하기 위해 요구되는 콤포넌트들 중 적어도 하나에 적용된다(A 1-bit field that indicates, when set to 1, service protection is applied to at least one of the components needed to provide a meaningful presentation of this Service).
short_service_name_length 필드 (3비트)는 short_service_name 필드에 서술되는 숏 서비스 네임의 길이를 바이트 단위로 표시한다.
short_service_name 필드는 해당 서비스의 숏 네임을 나타낸다(short_service_name: The short name of the Service, each character of which shall be encoded per UTF-8 [29]. When there is an odd number of bytes in the short name, the second byte of the last of the byte pair per the pair count indicated by the short_service_name_length field shall contain 0x00). 예를 들어, 서비스가 모바일 서비스이면 모바일 서비스의 숏 네임을, NRT 서비스이면 NRT 서비스의 숏 네임을 표시한다.
service_category 필드(6비트)는, 해당 서비스의 타입 카테고리를 식별한다. 해당 필드의 값이 "informative only" 지시하는 값으로 설정되면, 해당 필드의 값은 상기 서비스의 카테고리에 대한 인포머티브 디스크립션으로 다루어진다. 그리고 수신기는 수신되는 서비스의 실제 카테고리를 식별하기 위해 SMT의 component_level_descriptors() 필드를 검사하는 것이 요구된다. 비디오 및/또는 오디오 콤포넌트를 가진 서비스들을 위해 그것들은 NTP 타임 베이스 콤포넌트를 가진다.
특히, 본 발명과 관련하여, service_category 필드의 값이 예를 들어, '0x0E' 값을 가진 경우에는 해당 서비스는 NRT 서비스임을 지시한다. 이 경우, SMT 섹션에서 현재 서술하는 서비스의 시그널링 정보는 NRT 서비스의 시그널링 정보임을 알 수 있다.
num_components 필드(5비트)는 해당 서비스 내 IP 스트림 콤포넌트의 개수를 표시한다(num_components: This 5-bit field specifies the number of IP stream components in this Service).
IP_version_flag 필드(1비트)는 '1'로 설정된 경우에는 source_IP_address 필드, service_destination_IP_address 필드 및 component_destination_IP_address 필드가 IPv6 어드레스임을 지시하고, '0'으로 설정된 경우에는 source_IP_address 필드, service_destination_IP_address 필드, component_destination_IP_address 필드가 IPv4 어드레스임을 지시한다(IP_version_flag: A 1-bit indicator, which when set to '0' shall indicate that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses. The value of '1' for this field is reserved for possible future indication that source_IP_address, service_destination_IP_address, and component_destination_IP_address fields are for IPv6. Use of IPv6 addressing is not currently defined).
source_IP_address_flag 필드(1비트)가 설정된 경우에는 해당 서비스를 위한 소스 IP 어드레스 값이 소스 특정 멀티캐스트를 지시하기 위해 존재함을 지시하는 플래그이다(source_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set, that a source IP address value for this Service is present to indicate a source specific multicast).
service_destination_IP_address_flag 필드(1비트)가 설정된 경우에는 해당 IP 스트림 콤포넌트가 service_destination_IP_address와는 다른 target IP 어드레스를 갖는 IP 데이터그램을 통해 전송됨을 지시한다. 따라서 본 플래그가 설정된 경우에는 수신 시스템은 해당 IP 스트림 콤포넌트에 접근하기 위해서
component_destination_IP_address을 destination_IP_address로 사용하고, num_channels 루프 내의 service_destination_IP_address 필드를 무시한다(service_destination_IP_address_flag: A 1-bit Boolean flag that indicates, when set to '1', that a service_destination_IP_address value is present, to serve as the default IP address for the components of this Service).
source_IP_address 필드(32 또는 128비트)는 source_IP_address_flag가 '1'로 설정된 경우에는 해석될 필요가 있지만, source_IP_address_flag가 '0'로 설정되지 않은 경우에는 해석될 필요가 없다.
source_IP_address_flag가 '1'로 설정되고 IP_version_flag 필드가 '0'으로 설정된 경우, 본 필드는 해당 가상 채널의 소스를 나타내는 32비트 IPv4 어드레스를 지시한다. 만약 IP_version_flag 필드가 '1'로 설정된 경우에는 본 필드는 해당 가상 채널의 소스를 나타내는 32비트 IPv6 어드레스를 지시한다(source_IP_address: This field shall be present if the source_IP_address_flag is set to '1' and shall not be present if the source_IP_address_flag is set to '0'. If present, this field shall contain the source IP address of all the IP datagrams carrying the components of this 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).
만일 상기 서비스가 NRT 서비스이면, 상기 Source_IP_address 필드는 FLUTE 세션의 모든 채널을 전송하는 동일한 서버의 소스 IP 어드레스(source IP address)가 된다.
service_destination_IP_address 필드(32 또는 128비트)는 service_destination_IP_address_flag 가 '1'로 설정된 경우에는 해석될 필요가 있지만, service_destination_IP_address_flag 가 '0'으로 설정된 경우에는 해석될 필요가 없다. service_destination_IP_address_flag 가 '1'로 설정되고, IP_version_flag 필드가 '0'으로 설정된 경우, 본 필드는 해당 가상 채널에 대한 32비트 데스트네이션 IPv4 어드레스를 나타낸다.
service_destination_IP_address_flag 가 '1'로 설정되고, IP_version_flag 필드가 '1'로 설정된 경우, 본 필드는 해당 가상 채널에 대한 64비트 데스트네이션 IPv6 어드레스를 나타낸다. 만약 해당 service_destination_IP_address를 해석할 수 없다면, num_components 루프 내의 component_destination_IP_address 필드가 해석되어야 하고, 수신 시스템은 IP 스트림 콤포넌트에 접근하기 위해서, component_destination_IP_address를사용해야한다(service_destination_IP_address: This field shall be present if the service_destination_IP_address_flag is set to '1' and shall not be present if the service_destination_IP_address_flag is set to '0'. If this 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). 만일 상기 서비 스가 NRT 서비스이면, 상기 service_destination_IP_Address 필드는 이 FLUTE 세션의 세션 레벨의 데스트네이 션 IP 어드레스(destination IP address)가 있으면 시그널링 된다.
한편, 본 실시 예에 따른 SMT는, for loop를 사용하여 복수의 콤포넌트에 대한 정보를 제공한다.
이후 상기 num_components 필드 값에 해당하는 콤포넌트 개수만큼 'for' 루프(또는 콤포넌트 루프라 함)가 수행되어 복수의 콤포넌트에 대한 접속 정보를 제공한다. 즉, 해당 서비스에 포함되는 각 콤포넌트의 접속 정보를 제공한다. 이때 각 콤포넌트에 대해 다음과 같은 필드 정보를 제공할 수 있다. 여기서, 하나의 콤포넌트는 하나 의 FLUTE 세션에 대응되는 것을 일 실시예로 한다.
essential_component_indicator 필드(1비트)는, '1'로 설정되어 있으면 해당 콤포넌트는 모바일 서비스를 위한 필수 콤포넌트 임을 지시한다. 그렇지 않으면, 해당 콤포넌트는 선택적인 콤포넌트임을 지시한다 (essential_component_indicator: A one-bit indicator which, when set to '1' shall indicate that this component is an essential component for the service. Otherwise, this field indicates that this component is an optional component).
component_destination_IP_address_flag 필드(1비트)는 '1'로 설정되어 있으면 해당 콤포넌트를 위해 component_destination_IP_address 필드가 존재함을 지사하는 플래그이다 (component_destination_IP_address_flag: A 1-bit Boolean flag that shall indicate, when set to '1' that the component_destination_IP_address is present for this component).
port_num_count 필드(6비트)는 해당 UDP/IP 스트림 콤포넌트와 관련된 UDP 포트의 넘버를 지시한다. 데스트네이션 UDP 포트 넘버 값은 destination_UDP_port_num 필드 값으로부터 시작해서 1씩 증가한다. RTP 스트림을 위해서는, 데스트네이션 UDP 포트 넘버는 destination_UDP_port_num 필드 값으로부터 시작해서 2씩 증가하며, 이는 RTP 스트림과 관련된 RTCP 스트림을 포함하기 위해서이다(port_num_count: This field shall indicate the number of destination UDP ports associated with this UDP/IP stream component. The values of the destination UDP port numbers shall start from the component_destination_UDP_port_num field and shall be incremented by one, except in the case of RTP streams, when the destination UDP port numbers shall start from the component_estination_UPD_port_num field and shall be incremented by two, to allow for the RTCP streams associated with the RTP streams).
destination_UDP_port_num 필드(16비트)는 해당 IP 스트림 콤포넌트를 위한 데스트네이션 UDP 포트 넘버를 나타낸다. RTP 스트림을 위해서는 destination_UDP_port_num의 값은 짝수이고, 다음 높은 값은 관련된 RTCP 스트림의 데스트네이션 UDP 포트 넘버를 나타낸다(component_destination_UDP_port_num: A 16-bit unsigned integer field, that represents the destination UDP port number for this UDP/IP stream component. For RTP streams, the value of component_estination_UDP_port_num shall be even, and the next higher value shall represent the destination UDP port number of the associated RTCP stream).
component_destination_IP_address 필드(32 또는 128비트)는 IP_version_flag 필드가 '0'으로 설정된 경우에는 본 필드는 해당 IP 스트림 콤포넌트를 위한 32비트 데스트네이션 IPv4 어드레스를 지시한다. 그리고 IP_version_flag 필드가 '1'로 설정된 경우에는 본 필드는 해당 IP 스트림 콤포넌트를 위한 128비트 데스트네이션 IPv6 어드레스를 지시한다(component_destination_IP_address: This field shall be present if the component_destination_IP_address_flag is set to '1' and shall not be present if the component_destination_IP_address_flag is set to '0'. When this field is present, the destination address of the IP datagrams carrying this component of the M/H 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 M/H_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).
num_component_level_descriptors 필드(4비트)는 콤포넌트 레벨의 추가 정보를 제공하는 디스크립터의 개수를 표시한다.
상기 num_component_level_descriptors 필드 값에 해당하는 개수만큼 상기 콤포넌트 루프에 component_level_descriptor()들이 포함되어, 상기 콤포넌트에 대한 부가 정보를 제공한다.
num_service_level_descriptors 필드(4비트)는 해당 서비스 레벨의 추가 정보를 제공하는 디스크립터의 개수를 표시한다.
상기 num_service_level_descriptors 필드 값에 해당하는 개수만큼 상기 서비스 루프에 service_level_descriptor()들이 포함되어, 상기 서비스에 대한 부가 정보를 제공한다. 상기 서비스가 모바일 서비스이면 모바일 서비스에 대한 부가 정보를 제공하고, NRT 서비스이면 NRT 서비스에 대한 부가 정보를 제공한다.
num_ensemble_level_descriptors 필드(4비트)는 앙상블 레벨의 추가 정보를 제공하는 디스크립터의 개수이다.
상기 num_ensemble_level_descriptors 필드 값에 해당하는 개수만큼 상기 앙상블 루프에 ensemble_level_descriptor()들이 포함되어, 상기 앙상블에 대한 부가 정보를 제공한다.
한편, 도 18의 SMT에서도 component_level_descriptors()로서 component_descriptor()가 제공될 수 있다.
상기 component_descriptor()는 SMT의 콤포넌트 레벨 디스크립터component_level_descriptors()의 하나로서 사용되며, 해당 콤포넌트의 부가적인 시그널링 정보를 서술한다.
따라서, 모바일 NRT 서비스에서도 해당 FULTE 세션을 수신하기 위하여 필요한 시그널링 정보들은 도 14의 콤포넌트 디스크립터를 사용하여 제공할 수 있다.
예를 들어, 도 14의 콤포넌트 디스크립터의 component_type 필드 값이 38이면 component_data(component_type) 필드는 도 15와 같은 FLUTE 파일 딜리버리를 위한 데이터를 제공한다. 도 14, 도 15의 각 필드의 설명은 앞에서 했으므로 여기서는 생략하기로 한다.
도 19는 본 발명의 일 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것이고, 도 20은 본 발명의 다른 실시 예에 따른 파일과 content_id의 매핑을 위한 FDT 스키마를 설명하기 위해 도시한 것으로, FDT 인스턴트 레벨 엔트리 파일 지정 방식을 표현한다. NRT 컨텐트는 복수의 파일이 있지만 각 파일에는 표시가 없기 때문에 NRT 컨텐트의 관련된 파일을 찾기가 어렵다. 따라서, 도 19 및 도 20은 각 파일 내 FDT에 content_id을 삽입하는 것을 도시한다.
이하에서 FDT 인스턴스 레벨은, FDT에서 선언된 모든 파일의 공통 속성을 정의할 필요가 있는 경우 그에 대한 정의 부분을 포함하는 레벨을 의미하고, FDT 파일 레벨은, 각 파일에 개별적인 속성에 대한 정의를 포함하는 레벨을 의미하는 것으로 사용될 수 있다.
수신기는 해당 채널을 통해 전송된 서비스가 SMT를 기반으로 한 NRT 서비스인지를 식별한다. 또한, 수신기는 해당 NRT 서비스의 컨텐트 아이템 및 파일을 식별한다.
앞 설명에서 언급되듯이, 수신기는 NRT 서비스 내에 파일 및 컨텐트 아이템을 식별할 수 있지만, 수신기는 컨텐트 아이템의 파일에 대한 정보가 없기 때문에 컨텐트 아이템의 파일과 매칭할 수가 없다. 따라서, 수신기는 수신된 NRT 서비스를 처리할 수 없다.
따라서, 본 발명은 컨텐트 아이템과 관련되어 있는지를 식별하는 방법을 제공할 수 있다. 다시 말해서, 해당 방법은 컨텐트 아이템에 무슨 파일이 존재하는지를 보여줄 것이다. 이 경우에는, 수신기는 수신된 NRT 서비스 적절히 처리할 수 있다. 따라서, 해당 방법은 NRT 서비스를 전송해 FLUTE 세션 내 FDT 정보를 기반으로 지정할 수 있다. 예를 들어, 컨텐트 아이템을 구축하는 각 파일은 FLUTE 세션에서 지정된 content-location 및 TOI 필드로 기반으로 식별된다. FDT 내에 content_id는 NCT의 컨텐트 식별자(content_id) 또는 OMB BCAST SG 내 컨텐트 프래그먼트의 컨텐트 식별자와 매칭된다.
도 19 내지 20을 참조할 때, 1번으로 표시된 부분은 FDT-Instance 레벨(level)에서 컨텐트 식별자를 선언하는 것으로, 여기에서 선언된 컨텐트 식별자는 해당 FDT-Instance 내에서 선언된 모든 파일(file)에 부여된다. 물론 파일 레벨(File level)에서 컨텐트 식별자를 새롭게 부여함으로써 이 정보를 오버라이드(override) 할 수도 있다. 혹은 특정 파일이 FDT-Instance 레벨에 정의된 컨텐트 아이템(content item)이 아닌 다른 컨텐트 아이템에도 속한다면 하기에 설명할 파일 레벨 content_id를 부여하는 것을 통해 이를 알려줄 수도 있다. 본 실시 예에서는 content_id를 16 비트를 사용해 표현한다.
2번으로 표시된 부분은 파일 레벨에서 content_id를 선언하는 것으로 FDT Instance 내에 포함된 파일이 서로 다른 컨텐트 아이템에 속할 경우 이 방법을 이용해 각 파일이 어느 컨텐트 아이템 및 컨텐트의 모든 파일이 어느엔트리(entry)에 속하는 지를 시그널링 한다.
3번은 각 파일에 대해 해당 파일이 엔트리 파일(entry file)인지 여부를 알려주기 위한 방법이다. 즉, 컨텐트 아이템을 구성하는 여러 개의 파일들 중에서 가장 먼저 재생하거나 컨텐트 아이템을 접근하기 위해 반드시 먼저 실행해야 하는 루트 파일(root file)에 해당하는 파일을 엔트리 파일이라고 하며 이러한 정보를 알려주기 위한 방법을 나타낸다. entry 속성(attribute)은 생략이 가능하며 기본 값은 false로 생략되어 있는 경우 해당 파일은 엔트리 파일이 아님을 의미한다."엔트리(entry)"는 파일을 실행하기 위해 처리해야 할 파일의 헤드를 말한다. 예를 들어, "index.html"는 "엔트리"일 수 있다. 따라서, 엔트리 파일은 "true"로 설정 될 수 있고 다른 파일은 "false"로 설정될 수 있다. 엔트리 파일을 통해서, 동일한 파일을 전송하는 중복은 효과적으로 제어될 수 있다. 일단 파일이 다운로드했으면, 엔트리 파일이 다른 참조를 위한 컨텐트의 파일을 지시하기 때문에 다른 또는 별도의 인스턴스에 다운로드 할 필요가 없다.
특정한 파일은 파일 레벨에 관련된 그룹에서 엔트리 여부를 시그널링해서 특정한 그룹에서 엔트리의 역할을 하지만 다른 그룹에서는 해당 역할이 실패할 수도 있다. FDT-instance 레벨에서 컨텐트 식별자를 부여할 경우의 엔트리 파일 여부를 알려주는 방법은 아래와 같은 두 가지 방법을 생각해 볼 수 있다.
1) 엔트리 파일에 해당되는 파일에 대하여 파일 레벨 컨텐트 식별자를 추가로 부여하고 이의 엔트리 속성을 true로 설정하는 방법: 이 경우 컨텐트 식별자가 FDT-Instance 레벨과 파일 레벨에 중복되는 단점이 있으나 가장 융통성 있는 구조를 가질 수 있다. 다시 말해서, File-level 및 FDT-instance 레벨 중에 하나가 content_id를 지정할 수 있지만 다른 content_id가 File-level 및 FDT-instance 레벨에서 함께 지정됐을 경우에는 File-level의 content_id가 우선권이 있다.
2) 도 20에 도시한 FDT 스키마(schema)의 또 다른 실시 예와 같이 FDT-instance 레벨의 컨텐트 식별자 정의에서 엔트리 파일의 역할을 수행하는 파일들을 직접 레퍼런스(reference) 해주는 방식을 생각할 수 있다. 이를 위해 도 20의 실시 예에서는 FDT-instance 레벨 컨텐트 식별자를 위해 FDT-Content-ID-Type을 별도로 정의하고 이를 2번으로 표시된 바와 같이 엔트리 파일의 컨텐트 로케이션(content location)을 포함할 수 있도록 확장하였다. 2번의 경우에는, 엔트리 레벨은 그것의 content_id로 정의된다. 예를 들어, 각 content_id에서 어느 엔트리 파일이 있는지를 보여준다.
이 방법의 경우 컨텐트 로케이션(content-location)을 중복해서 시그널링 하는 부분이 단점이 될 수 있으나 각 컨텐트 아이템별로 엔트리 파일 구성 정보를 바로 획득할 수 있다는 점이 장점이 될 수 있다.
도 21은 본 발명의 일 실시예에 따른 수신기의 동작 방법을 나타낸 흐름도이다.
도 21을 참조하면, 본 발명의 일 실시예에서는 수신기가 NRT 서비스 시그널링 채널을 통해 NRT 서비스 시그널링 데이터를 수신하고, 수신한 NRT 서비스 시그널링 데이터를 이용하여 NRT 가이드 정보를 표시하며, 선택된 NRT 컨텐트에 대한 NRT 서비스 데이터를 수신하여 NRT 서비스를 제공할 수 있다.
먼저, 수신기에 전원이 켜지면, 사용자에 의해 채널이 선택된다(S1000). 그리고, 선택된 채널에 따라 물리적 전송 채널을 튜닝한다.
이후, 튜닝된 물리적 전송 채널로 수신되는 방송 신호로부터 VCT와 PMT를 획득한다(S1010). 그리고 상기 획득된 TVCT(VCT)를 파싱하여 NRT 서비스가 있는지를 확인한다(S1020). 이는 상기 VCT의 가상 채널 루프 내 service_type 필드 값을 확인하여 알 수 있다. 예를 들어, service_type 필드의 값이 0x08인 경우, NRT 서비스가 있는지를 확인할 수 있다. 그리고, 0X08이 아닌 경우에는 해당 가상 채널은 NRT 서비스를 전송하지 않으므로, 가상 채널에 포함된 정보에 따라 일반 A/V 서비스 제공 등의 적절한 동작을 수행할 수 있다(S1111).
한편, NRT 서비스가 존재하는 것으로 판단된 경우, 해당 가상 채널은 NRT 서비스를 전송하므로, NRT 서비스 시그널링 채널 접속을 위한 잘 알려진 IP주소(Wellknown IP address)를 포함하는 스트림의 특정 PID(PID_NST)와 매칭되는 PID(PID=PID_NST)를 획득한다(S1030).
그리고, 수신기는 획득한 PID 값(PID_NST)으로부터, 이와 일치하는 PID값을 갖는 트랜스포트 패킷(Transport Packet, TP)을 수신한다(S1040).
이후, 수신기는 수신한 TP로부터 NRT 서비스 테이블(NST)를 포함하는 NRT 서비스 시그널링 데이터를 추출하거나, 수신한 TP로부터 상술한 NRT 서비스 시그널링 채널 접속을 위한 IP 주소를 추출하여, IP 계층을 통해 다른 형태로 전송되는 NRT 서비스 시그널링 데이터를 수신한다(S1050).
그리고, 수신기는 NST로부터 각 NRT 서비스 별로, NRT 서비스 데이터의 전송을 위한 채널 정보를 획득한다(S1060).
이후, 수신기는 NRT 서비스 시그널링 데이터로부터 상기 획득한 채널 정보의 식별자인 Channel_id 값과 일치하는 NRT_channel_id 필드의 값을 가지는 NRT 컨텐트 테이블(NCT)를 획득한다(S1070).
그리고, 수신기는 획득한 NCT의 각 필드로부터 각 NRT 서비스를 구성하는 NRT 컨텐트에 대한 컨텐트 정보를 획득한다(S1080). 컨텐트 정보는 예를 들어, 상술한 NCT의 실시 예에 따라, content_delevery_bit_rate, content_available_start_time, content_available_end_time 및 content_title_text() 필드 중 적어도 하나를 포함할 수 있다.
그리고, 수신기는 컨텐트 정보를 이용하여 NRT 가이드 정보를 표시한다(S1090). 사용자는 표시된 NRT 가이드 정보로부터 사용 또는 수신하고자 하는 NRT 컨텐트를 선택할 수 있다.
이후, 수신기는 선택된 NRT 컨텐트가 속한 NRT 서비스 접속정보를 NST로부터 획득한다(S1100). NRT 서비스 접속정보는 예를 들어, NRT 서비스 데이터를 수신하기 위한 채널 정보 또는 IP 주소 정보를 포함할 수 있다.
그리고, 수신기는 획득한 NRT 서비스 접속 정보를 이용하여, NRT 서비스를 전송하기 위한 채널 또는 서버에 접속하여 해당 NRT 컨텐트를 수신하며(S1110), 수신한 NRT 컨텐트에 따라 적절한 동작을 수행할 수 있다.
도 22 및 도 23은 NRT 서비스를 위한 NRT 컨텐트를 수신하여 저장 및 재생할 수 있는 수신 시스템의 일 실시예와 다른 일 실시예이다.
도 23의 수신기는 오퍼레이션 제어부(100), 베이스밴드 처리부(110), 서비스 역다중화기(120), 스트림 콤포넌트 핸들러(130), 미디어 핸들러(140), 파일 핸들러(150), 서비스 매니저(160), PVR 매니저(170), 제1 저장부(180), SG 핸들러(190), EPG 매니저(191), NRT 서비스 매니저(192), 어플리케이션 매니저(194), 미들웨어 엔진(193), 프리젠테이션 매니저(195), 및 UI(User Interface) 매니저(196)를 포함할 수 있다.
베이스밴드 처리부(110)는 튜너(111)와 복조기(112)를 포함할 수 있다. 서비스 역다중화기(120)는 MPEG-2 TP 핸들러(121), PSI/PSIP 핸들러(122), MPEG-2 TP 역다중화기(123), 디스크램블러(124), 및 제2 저장부(125)를 포함할 수 있다.
스트림 콤포넌트 핸들러(130)는 PES(Packetized Elementary Stream) 복호기(131), ES(Elementary Stream)복호기(132), PCR 핸들러(133), STC 핸들러(134), DSM-CC 어드레서블 섹션 핸들러(135), IP 데이터그램 핸들러(136), 디스크램블러(137), UDP 핸들러(138), 서비스 시그널링 섹션 핸들러(138-1), 및 CAS(Conditional Access System)(139)을 포함할 수 있다.
미디어 핸들러(140)는 A/V 복호기(141)를 포함할 수 있다. 상기 파일 핸들러(150)는 ALC/LCT 스트림 핸들러(151), 파일 재건(reconstruction) 버퍼(152), XML 파서(153), FDT 핸들러(154), 디콤프레서(155), 및 제3저장부(156), 및 파일 디코더(157)를 포함할 수 있다.
이와 같이 구성된 도 23에서, 튜너(111)는 예를 들면, 지상파를 통해 수신되는 방송 신호 중 원하는 채널의 방송 신호를 서비스 매니저(160)의 제어에 의해 튜닝하여 중간주파수(IF: Intermediate Frequency) 신호로 다운 컨버전하여 복조기(112)로 출력한다. 상기 튜너(111)는 실시간 스트림과 비실시간 스트림을 수신할 수 있다. 본발명에서 비실시간 스트림은 NRT 스트림이라 하기로 한다.
복조기(112)는 튜너(111)로부터 입력되는 통과대역의 디지털 IF 신호에 대해 자동 이득 제어, 반송파 복구 및 타이밍 복구 등을 수행하여 기저대역 신호로 변환하고, 채널 등화를 수행한다. 예를 들어, 상기 방송 신호가 VSB 변조 신호인 경우 VSB 복조 과정을 수행하여 자동 이득 제어, 반송파 복구 및 타이밍 복구 등을 수행한다.
복조기(112)에서 복조 및 채널 등화된 데이터는 MPEG-2 TS(Transport Stream) 패킷 형태로 상기 MPEG-2 TP 핸들러(121)로 출력된다.
MPEG-2 TP(Transport Stream Packet) 핸들러(121)는 MPEG-2 TP 버퍼와 MPEG-2 TP 파서로 구성되며, 복조기(112)의 출력을 일시 저장한 후 TS 헤더를 분석하여, 복조기(112)의 출력이 실시간용 A/V TS 패킷이거나, NRT TS 패킷이면 역다중화기(123)로 출력하고, PSI/PSIP 테이블용 TS 패킷이면 PSI/PSIP 핸들러(122)로 출력한다.
상기 PSI/PSIP 핸들러(122)는 PSI/PSIP 섹션 버퍼와 PSI/PSIP 파서로 구성되며, 상기 MPEG-2 TP 핸들러(121)에서 출력되는 TS 패킷을 일시 저장한 후 테이블 식별자 등을 참조하여 상기 TS 패킷의 페이로드에 포함된 PSI/PSIP 섹션 데이터로부터 해당 테이블을 복원하여 파싱한다. 이때 하나의 테이블이 하나의 섹션으로 구성되는지 복수개의 섹션으로 구성되는지는 해당 섹션 내 table_id 필드, section_number 필드, last_section_number 필드 등을 통해 알 수 있다. 그리고 동일한 테이블 식별자를 갖는 섹션들을 모으면 해당하는 테이블을 완성할 수 있다. 예를 들어, VCT에 할당된 테이블 식별자를 갖는 섹션들을 모으면 VCT를 완성할 수 있다. 그리고 상기 파싱된 각 테이블의 정보는 서비스 매니저(160)에 의해 수집되어 제1 저장부(180)에 저장한다. 본 발명에 따른 VCT, PAT, PMT, DST 등의 테이블 정보가 상기 과정을 거쳐 제1 저장부(180)에 저장된다. 상기 서비스 매니저(160)는 상기 테이블 정보를 서비스 맵 및 가이드 데이터 형태로 상기 제1 저장부(180)에 저장한다.
역다중화기(123)는 입력되는 TS 패킷이 리얼 타임의 A/V TS 패킷이면 오디오 TS 패킷과 비디오 TS 패킷으로 분리한 후 PES 디코더(131)로 출력하고, NRT TS 패킷이면 DSM-CC 핸들러(135)로 출력한다. 또한 역다중화기(123)는 PCR(Program Clock Reference)가 포함된 TS 패킷이면 PCR 핸들러(133)로 출력하고, CA(Conditional Access) 정보가 포함된 TS 패킷이면 CAS(139)로 출력한다. NRT TS 패킷은 NRT 서비스 데이터를 포함하는 TS 패킷과 NRT 서비스 시그널링 채널을 포함하는 TS 패킷으로 구분된다. 상기 NRT 서비스 데이터의 TS 패킷에는 상기 NRT 서비스를 식별하기 위하여 유일한 PID가 할당되며, 상기 NRT 서비스 시그널링 채널을 포함하는 TS 패킷의 PID는 DST와 PMT를 이용하여 추출한다.
역다중화기(123)는 입력되는 TS 패킷의 페이로드가 스크램블되어 있으면, 디스크램블러(124)로 출력하고, 상기 디스크램블러(124)는 상기 CAS(139)로부터 디스크램블에 필요한 정보(예, 스크램블에 이용된 제어 단어등)를 입력받아 상기 TS 패킷에 대해 디스크램블을 수행한다.
역다중화기(123)는 일시 녹화, 예약 녹화, 타임시프트 중 어느 하나의 요청에 의해 입력되는 리얼 타임의 A/V 패킷을 제2 저장부(125)에 저장한다. 상기 제2 저장부(125)는 대용량 저장 매체로서, 일 예로 HDD 등이 될 수 있다. 상기 제2 저장부(125)에서의 다운로드(즉, 저장) 및 업로드(즉, 재생)는 PVR 매니저(170)의 제어에 의해 이루어진다.
역다중화기(123)는 재생 요청에 따라 상기 제2 저장부(125)로부터 업로드된 A/V TS 패킷으로부터 오디오 TS 패킷과 비디오 TS 패킷으로 분리하여 PES 디코더(131)로 출력한다.
역다중화기(123)는 전술한 처리를 위해 서비스 매니저(160) 또는/및 PVR(Personal Vedeo Recorder) 매니저(170)의 제어를 받는다.
즉, 서비스 매니저(160)는 VCT 내 service_type 필드 값이 NRT 서비스가 전송됨을 지시하면, 상기 VCT의 가상 채널 루프에 포함되어 수신되는 NRT 서비스 디스크립터(NRT_service_descriptor())로부터 각 NRT 서비스의 식별 정보를 추출하여 저장하고, 상기 VCT의 service location descriptor(또는 PMT의 ES loop)로부터 DST의 PID를 추출하여 DST를 수신한다.
그리고, 상기 수신된 DST로부터 NRT 서비스를 식별하고, 식별된 NRT 서비스를 수신하기 위해 상기 NRT 서비스 시그널링 채널을 포함하는 MPEG-2 TS 패킷의 PID를 DST와 PMT를 이용하여 추출한다. 상기 추출된 PID는 역다중화기(123)로 출력한다. 상기 역다중화기(123)는 상기 서비스 매니저(160)에서 출력하는 PID에 해당하는 MPEG-2 TS 패킷들을 어드레서블 섹션 핸들러(135)로 출력한다.
상기 PCR은 A/V 디코더(141)에서 오디오 ES 및 비디오 ES의 타임 동기 등을 위해 사용되는 시간 기준값이다. 상기 PCR 핸들러(133)는 입력되는 TS 패킷의 페이로드에 포함된 PCR을 복원하여 STC 핸들러(134)로 출력한다. 상기 STC 핸들러(134)는 상기 PCR로부터 시스템의 기준 클럭이 되는 STC(System Time Clock)를 복원하여 A/V 디코더(141)로 출력한다.
상기 PES 디코더(131)는 PES 버퍼와 PES 핸들러로 구성되며, 오디오 TS 패킷과 비디오 TS 패킷을 일시 저장한 후 각 TS 패킷으로부터 TS 헤더를 제거하여 오디오 PES와 비디오 PES로 복원한다. 상기 복원된 오디오 PES와 비디오 PES는 ES 디코더(132)로 출력된다. 상기 ES 디코더(132)는 ES 버퍼와 ES 핸들러로 구성되며, 오디오 PES와 비디오 PES로부터 각 PES 헤더를 제거하여 순수한 데이타인 오디오 ES와 비디오 ES로 복원한다. 상기 복원된 오디오 ES와 비디오 ES는 상기 A/V 디코더(141)로 출력된다.
A/V 디코더(141)는 각각의 디코딩 알고리즘으로 상기 오디오 ES와 비디오 ES를 디코딩하여 압축 이전의 상태로 복원한 후 프리젠테이션 매니저(195)로 출력한다. 이때 상기 STC에 따라 오디오 ES와 비디오 ES의 디코딩시 타임 동기가 이루어진다. 일 예로, 오디오 디코딩 알고리즘은 AC-3 디코딩 알고리즘, MPEG 2 audio 디코딩 알고리즘, MPEG 4 audio 디코딩 알고리즘, AAC 디코딩 알고리즘, AAC+ 디코딩 알고리즘, HE AAC 디코딩 알고리즘, AAC SBR 디코딩 알고리즘, MPEG surround 디코딩 알고리즘, BSAC 디코딩 알고리즘중 적어도 하나를 적용하고, 비디오 디코딩 알고리즘은 MPEG 2 video 디코딩 알고리즘, MPEG 4 video 디코딩 알고리즘, H.264 디코딩 알고리즘, SVC 디코딩 알고리즘, VC-1 디코딩 알고리즘 중 적어도 하나를 적용할 수 있다.
CAS(139)는 CA 스트림 버퍼와 CA 스트림 핸들러로 구성되며, 상기 MPEG-2 TP 핸들러(121)에서 출력되는 TS 패킷 또는 UDP 데이터그램 핸들러(138)에서 복원되어 출력되는 서비스 보호 데이터를 일시 저장한 후 상기 저장된 TS 패킷 또는 서비스 보호 데이터로부터 디스크램블에 필요한 정보(예를 들어, 스크램블에 사용된 제어 단어 등)를 복원한다. 즉, 상기 TS 패킷의 페이로드에 포함된 EMM(Entitlement Management Message), ECM(Entitlement Control Message) 등을 추출하고, 추출된 EMM, ECM 등을 분석하여 디스크램블에 필요한 정보를 획득한다. 상기 ECM은 스크램블에 사용된 제어 단어(CW)를 포함할 수 있다. 이때 상기 제어 단어는 인증키로 암호화되어 있을 수 있다. 상기 EMM은 해당 데이터의 인증키와 자격 정보를 포함할 수 있다. 상기 CAS(139)에서 획득한 디스크램블에 필요한 정보는 디스크램블러(124,137)로 출력된다.
DSM-CC 섹션 핸들러(135)는 DSM-CC 섹션 버퍼와 DSM-CC 섹션 파서로 구성되며, 상기 역다중화기(123)에서 출력되는 TS 패킷을 일시 저장한 후 상기 TS 패킷의 페이로드에 포함된 어드레서블 섹션을 복원하고, 상기 어드레서블 섹션의 헤더와 CRC 첵섬(checksum)을 제거하여 IP 데이터그램을 복원한 후 IP 데이터그램 핸들러(136)로 출력한다.
IP 데이터그램 핸들러(136)는 IP 데이터그램 버퍼와 IP 데이터그램 파서로 구성되며, 상기 DSM-CC 섹션 핸들러(135)로부터 전달받은 IP 데이터그램을 버퍼링한 후, 버퍼링된 IP 데이터그램의 헤더를 추출하고 분석하여 상기 IP 데이터그램의 페이로드로부터 UDP 데이터그램을 복원한 후 UDP 데이터그램 핸들러(138)로 출력한다.
이때 상기 IP 데이터그램이 스크램블되어 있다면, 상기 스크램블된 UDP 데이터그램은 디스크램블러(137)에서 디스크램블된 후 UDP 데이터그램 핸들러(138)로 출력된다. 일 예로, 상기 디스크램블러(137)는 상기 CAS(139)로부터 디스크램블에 필요한 정보(예, 스크램블에 이용된 제어 단어 등)를 입력받아 상기 UDP 데이터그램에 대해 디스크램블을 수행한 후 UDP 데이터그램 핸들러(138)로 출력한다.
상기 UDP 데이터그램 핸들러(138)는 UDP 데이터그램 버퍼와 UDP 데이터그램 파서로 구성되며, 상기 IP 데이터그램 핸들러(136) 또는 디스크램블러(137)로부터 출력되는 UDP 데이터그램을 버퍼링한 후, 버퍼링된 UDP 데이터그램의 헤더를 추출하고 분석하여 상기 UDP 데이터그램의 페이로드에 포함된 데이터를 복원한다. 이때 복원된 데이터가 서비스 프로텍션 데이터이면 CAS(139)로 출력하고, NRT 서비스 시그널링 데이터이면 서비스 시그널링 섹션 핸들러(138-1)로 출력하며, NRT 서비스 데이터이면 ALC/LCT 스트림 핸들러(151)로 출력한다.
즉, 상기 NRT 서비스 시그널링 채널을 전송하는 IP 데이터그램의 접속 정보는 well-known 데스티네이션(destination) IP 어드레스와 well-known 데스티네이션 (destination) UDP 포트 번호인 것을 일 실시예로 한다.
따라서, 상기 IP 데이터그램 핸들러(136)와 UDP 데이터그램 핸들러(138)는 well-known 데스티네이션 IP 멀티캐스트 어드레스와 well-known 데스티네이션 UDP 포트 번호를 가지면서, NRT 서비스 시그널링 채널을 전송하는 IP 멀티캐스트 스트림 즉, NRT 서비스 시그널링 데이터를 추출하여 서비스 시그널링 섹션 핸들러(138-1)로 출력한다.
그리고, 상기 서비스 시그널링 섹션 핸들러(138-1)는 서비스 시그널링 섹션 버퍼와 서비스 시그널링 섹션 파서로 구성되며, 상기 NRT 서비스 시그널링 데이터로부터 NST를 복원하고 파싱하여 서비스 매니저(160)로 출력한다. 상기 NST를 파싱하면 NRT 서비스를 구성하는 컨텐트/파일들을 전송하는 FLUTE 세션의 접속 정보와 상기 NRT 서비스를 렌더링하는데 필요한 시그널링 정보를 추출할 수 있다. 예를 들어, 상기 NST로부터 각 FLUTE 세션으로 전송되는 NRT 서비스의 컨텐트/파일들의 렌더링(rendering)에 필수적인 정보를 추출할 수 있다. 상기 NRT 서비스의 컨텐트/파일들의 렌더링(rendering)에 필수적인 정보는 컨테이너 정보가 될 수도 있고, 인코딩 정보가 될 수도 있으며, 미디어 오브젝트의 디코딩 파라미터가 될 수도 있다.
상기 NST로부터 파싱된 정보는 서비스 매니저(160)에 의해 수집되어 제1 저장부(180)에 저장된다. 서비스 매니저(160)는 상기 NST에서 추출된 정보를 서비스 맵 및 가이드 데이터 형태로 제1 저장부(180)에 저장한다. 다른 실시예로, 서비스 매니저(160)의 역할을 NRT 서비스 매니저(192)에서 수행할 수도 있다. 즉, 상기 NST로부터 파싱된 정보는 NRT 서비스 매니저(192)에 의해 수집되어 제1 저장부(180)에 저장될 수도 있다.
ALC/LCT 스트림 핸들러(151)는 ALC/LCT 스트림 버퍼와 ALC/LCT 스트림 파서로 구성되며, UDP 데이터 그램 핸들러(138)로부터 출력되는 ALC/LCT 구조의 데이터를 버퍼링한 후, 버퍼링된 데이터로부터 ALC/LCT 세션의 헤더 및 헤더 확장(header extension)을 분석한다. 상기 ALC/LCT 세션의 헤더 및 헤더 확장을 분석한 결과, ALC/LCT 세션으로 전송되는 데이터가 XML 구조이면 XML 파서(153)로 출력하고, 파일 구조이면 파일 재건(File Reconstruction) 버퍼(152)에 일시 저장한 후 파일 디코더(157)로 출력하거나, 제3 저장부(156)에 저장한다. ALC/LCT 스트림 핸들러(151)는 상기 ALC/LCT 세션으로 전송되는 데이터가 NRT 서비스를 위한 데이터이면 NRT 서비스 매니저(192)의 제어를 받는다. 이때 상기 ALC/LCT 세션으로 전송되는 데이터가 압축되어 있으면, 디콤프레서(155)에서 해제된 후 XML 파서(153), 파일 디코더(157), 제3 저장부(156) 중 적어도 하나로 출력된다.
XML 파서(153)는 상기 ALC/LCT session을 통하여 전송되는 XML 데이터를 분석하고, 분석된 데이터가 파일기반 서비스를 위한 데이터이면 FDT 핸들러(154)로 출력하고, 서비스 가이드를 위한 데이터이면 SG 핸들러(190)로 출력한다.
FDT 핸들러(154)는 ALC/LCT session을 통하여 FLUTE 프로토콜의 파일 디스크립션 테이블(File Description Table)을 분석하고 처리한다. 상기 FDT 핸들러(154)는 수신된 파일이 NRT 서비스를 위한 파일이면 NRT 서비스 매니저(192)의 제어를 받는다.
SG 핸들러(190)는 XML 구조로 전송되는 서비스 가이드를 위한 데이터를 수집하고 분석하여 EPG 매니저(191)로 출력한다.
파일 디코더(157)는 파일 재건 버퍼(152)로부터 출력되는 파일 또는 디콤프레서(155)로부터 출력되는 파일 또는 제3 저장부(156)로부터 업로드된 파일을 기 설정된 알고리즘으로 디코딩하여 미들웨어 엔진(193)으로 출력하거나, A/V 디코더(141)로 출력한다.
미들웨어 엔진(193)은 파일 구조의 데이터 즉, 어플리케이션을 해석하여 실행시킨다. 그리고 상기 어플리케이션을 프리젠테이션 매니저(195)를 통해 화면이나 스피커와 같은 출력 장치로 출력할 수도 있다. 상기 미들웨어 엔진(193)은 자바(JAVA) 기반의 미들웨어 엔진인 것을 일 실시예로 한다.
EPG 매니저(191)는 유저의 입력에 따라 SG 핸들러(190)로부터 서비스 가이드 데이터를 입력받아 디스플레이 포맷으로 변환한 후 프리젠테이션 매니저(195)로 출력한다. 상기 어플리케이션 매니저(194)는 상기 파일 등의 형태로 수신되는 어플리케이션 데이터의 처리에 관한 전반적인 관리를 수행한다.
서비스 매니저(160)는 PSI/PSIP 테이블 데이터 또는 NRT 서비스 시그널링 채널로 전송되는 NRT 서비스 시그널링 데이터를 수집하고 분석하여 서비스 맵을 만든 후 제1 저장부(125)에 저장한다. 또한 서비스 매니저(160)는 사용자가 원하는 NRT 서비스에 대한 접속 정보를 제어하며, 튜너(111), 복조기(112), IP 데이터그램 핸들러(136) 등에 대한 제어를 수행한다.
오퍼레이션 제어기(100)는 UI 매니저(196)를 통해 입력되는 유저의 명령에 따라 상기 서비스 매니저(160), PVR 매니저(170), EPG 매니저(191), NRT 서비스 매니저(192), 어플리케이션 매니저(194), 프리젠테이션 매니저(195) 중 적어도 하나를 제어하여, 상기 유저의 명령에 따른 기능이 수행되도록 한다.
NRT 서비스 매니저(192)는 IP 계층 상에서 FLUTE 세션을 통하여 컨텐트/파일 형태로 전송되는 NRT 서비스에 대한 전반적인 관리를 수행한다.
UI 매니저(196)는 UI를 통해 유저의 입력을 오퍼레이션 제어기(100)로 전달한다.
상기 프리젠테이션 매니저(195)는 A/V 디코더(141)에서 출력되는 오디오 및 비디오 데이터, 미들웨어 엔진(193)에서 출력되는 파일 데이터, EPG 매니저(191)에서 출력되는 서비스 가이드 데이터 중 적어도 하나를 스피커 및 화면 중 적어도 하나를 통해 유저에게 제공한다.
한편, 서비스 시그널링 섹션 핸들러(138-1), 서비스 매니저(160), NRT 서비스 매니저(192) 중 어느 하나는 NST의 FLUTE 세션 루프(또는 NST의 콤포넌트 루프)로부터 상기 NRT 서비스를 구성하는 컨텐트 또는 파일을 전송하는 FLUTE 세션에 대한 IP 접속 정보를 획득한다. 또한 상기 NST의 FLUTE 세션 루프에 포함되어 수신되는 NRT_FLUTE_File_delivery_descriptor()로부터 FLUTE레벨 접속 정보를 획득한다. 또한 NST의 콤포넌트 루프에 포함되어 수신되는 component_descriptor()로부터 FLUTE 레벨 접속 정보를 획득한다.
그러면, 상기 ALC/LCT 스트림 핸들러(151)와 파일 디코더(157)에서는 상기 획득한 FLUTE 레벨 접속 정보를 이용하여 FLUTE 파일 딜리버리 세션에 접속하여, 상기 세션에 속한 파일들을 모은다. 상기 파일들을 모으면 하나의 NRT 서비스가 구성된다. 이러한 NRT 서비스는 제3 저장부(156)에 저장하거나, 미들웨어 엔진(193)이나 A/V 디코더(141)로 출력하여 디스플레이 장치에 표시되도록 한다.
상기 제3 저장부(156)는 NRT 서비스 데이터와 같은 파일을 저장하는 저장 매체로서, 제2 저장부(125)와 공유하여 사용할 수도 있고, 별도로 사용할 수도 있다.
도 24는 본 발명의 일 실시예에 따라 수신기가 NRT 서비스를 수신하여 제공하는 방법을 설명하기 위한 흐름도이다.
수신기는 NRT 서비스 시그널링 채널을 통하거나, 모바일 NRT 서비스의 경우에는 IP데이터그램을 수신하여 NRT 서비스 시그널링 정보를 획득할 수 있으며, NRT 서비스 시그널링 정보로부터 SMT를 획득한다(S2010).
그리고, 수신기는 SMT로부터 NRT 서비스 정보를 획득한다(S2020). NRT 서비스 정보는 SMT 내의 Service level descriptor 루프에서 NRT_service_info_descriptor를 파싱하여 획득할 수 있다. 획득한 NRT 서비스 정보는 각 NRT 서비스에 대한 어플리케이션 형식(application type) 또는 기타 NRT 서비스에 대한 요구(requirement)정보를 포함할 수 있다.
이후, 수신기는 획득한 NRT 서비스 정보에 기초하여 NRT 서비스 가이드를 출력한다(S2030). NRT 서비스 가이드에는 각 서비스에 대한 어플리케이션과 서비스 카테고리 정보가 표시될 수 있다. 또한, NRT service info descriptor의 각 필드에 기초하여 상세 정보가 더 표시될 수 있다. 상세 정보는 예를 들어, storage_requirement필드에 따른 해당 NRT 서비스의 용량 정보나 audio_codec_type 또는 video_codec_type 필드에 따른 해당 NRT 서비스의 오디오 또는 비디오 코덱 정보를 포함할 수 있다. 사용자는 서비스 가이드에 표시된 정보를 바탕으로 수신 또는 사용하고자 하는 NRT 서비스를 선택할 수 있다.
그리고, 수신기는 선택된 NRT 서비스를 구성하는 컨텐트 아이템에 대한 식별자(content_id)를 NCT로부터 획득한다(S2040). 수신기는 선택된 NRT 서비스에 대응하는 NRT_service_id를 SMT로부터 획득하고, 획득한 NRT_service_id의 값과 일치하는 NRT_channel_id값을 가지는 NCT를 획득하며, 획득한 NCT를 통하여 해당 NRT 서비스를 구성하는 컨텐트 아이템에 대한 식별자(content_id)를 획득할 수 있다.
이후, 수신기는 획득한 컨텐트 아이템 식별자(content_id)를 이용하여 해당 컨텐트 아이템을 구성하는 파일을 수신하기 위해 FLUTE 세션에 접속한다(S2050). 컨텐트 아이템을 구성하는 각각의 파일은 FLUTE세션 내의 FDT에 명시된 TOI 또는 Content-Location필드에 매칭되어 있으므로, 이후 수신기는 이와 같은 FLUTE 세션을 이용하여 해당 컨텐트 아이템의 파일을 수신한다(S2060). 파일의 수신은, 예를 들어, 해당 FLUTE 세션에서 FDT를 읽어 해당 파일에 대한 Content-ID attribute 필드가 획득한 content_id와 일치하면 해당 파일 또는 오브젝트를 수신하는 방법으로 이루어질 수 있다.
또한, 수신기는 해당 FLUTE 세션 내의 FDT 인스턴스들을 파싱함으로써, 컨텐트 아이템에 대응하는 파일들의 목록을 획득할 수 있다. 그리고, 수신기는 각 파일들의 목록 중 엔트리(entry)의 역할을 수행하는 파일들의 목록을 포함하는 엔트리 정보를 획득한다(S2070).
마지막으로, 수신기는 수신한 컨텐트 아이템과 컨텐트 아이템에 대응하는 파일들의 목록 또는 엔트리 정보에 기초하여 사용자에게 NRT 서비스를 제공한다(S2080).
이와 같이 NRT 서비스를 통하여 다운로드된 컨텐트는 실시간 방송과 독립적으로 사용자가 원하는 시점에 이용할 수 있다.
또한, 방송국은 NRT 서비스를 미리 송출하고 수신기가 수신하여 저장한 후, 특정 실시간 방송이 송출되거나 수신기에서 표시되는 시점에 해당 NRT 서비스의 컨텐트 아이템을 실행하도록 지정할 수도 있다. 이와 같이 본 발명의 일 실시예로서, NRT 서비스는 실시간 방송과 연계되어 미리 다운로드한 후, 특정 시점에 실행시킬 수 있는 컨텐트를 포함할 수 있다. 또한, 본 발명의 일 실시예로서 NRT 서비스는 특정 NRT 서비스를 특정 시점에 실행시키기 위해 미리 준비하기 위한 컨텐트를 포함할 수 있다. 이와 같이 특정 NRT 서비스에 대하여 특정 액션이 실행되도록 실시간 방송과 연계된 특정 시점에 트리거된 NRT 서비스 컨텐트를 트리거 선언적 오브젝트(TDO, Triggered Declarative Object) 라고 할 수 있다. 따라서, NRT 서비스 어플리케이션은 특정 시점에 실행되는지 여부에 따라 비실시간 선언적 오브젝트(NDO) 또는 트리거 선언적 오브젝트(TDO)로 구분될 수 있다.
본 발명의 일 실시예에 따르면, 방송국은 이와 같은 트리거 선언적 오브젝트(TDO)를 트리거 하기 위한 트리거 정보를 전송할 수 있다. 트리거 정보는 수신기가 특정 트리거 선언적 오브젝트에 대한 특정 액션을 특정 시점에 수행하기 위한 정보들을 포함할 수 있다.
또한, 트리거 정보는 트리거를 시그널링 하기 위한 트리거 시그널링 데이터(트리거 시그널링 정보) 및 트리거를 구성하는 트리거 데이터를 포함할 수 있다. 또한, 트리거 데이터를 전송하는 데이터 스트림을 트리거 스트림이라고 할 수 있다. 그리고, 본 발명에서 트리거 데이터는 트리거 그 자체를 의미할 수 있다.
이와 같은 트리거는 트리거를 식별하기 위한 트리거 식별자, 트리거하기 위한 NRT 서비스를 식별하기 위한 TDO 식별자, TDO에 대해 수행될 액션 정보 및 트리거 시간 중 적어도 하나를 포함할 수 있다.
트리거 식별자는 트리거를 유일하게 식별하기 위한 식별자일 수 있다. 예를 들어, 방송국은 EIT를 통해 제공되는 일정 시간 동안의 방송 프로그램 정보에 하나 이상의 트리거를 포함하여 전송할 수 있다. 이 경우, 수신기는 하나 이상의 트리거에 기초하여 각 트리거별로 지정된 시간에 트리거 대상 TDO에 대한 액션을 수행할 수 있다. 이 때, 수신기는 트리거 식별자를 이용하여 각 트리거들을 구별할 수 있다.
TDO 식별자는 트리거의 대상이 되는 NRT 서비스 컨텐트를 식별하기 위한 식별자일 수 있다. 따라서, TDO 식별자는 트리거 NRT 서비스 식별자(NRT_service_id), 컨텐트 결합(content_linkage), NRT 컨텐트 아이템 엔트리의 URI 또는 URL 중 적어도 하나를 포함할 수 있다. 그리고 후술할 트리거 대상 TDO를 식별하기 위한 대상 식별자(targer_service_id)를 포함할 수있다.
또한, TDO 액션 정보는 트리거 대상이 되는 TDO에 대해 수행할 액션에 대한 정보를 포함할 수 있다. 액션 정보는 대상 TDO의 실행, 종료, 연장 명령중 적어도 하나일 수 있다. 또한, 액션 정보는 대상 TDO 내의 특정 함수 또는 이벤트를 발생시키기 위한 명령을 포함할 수 있다. 예를 들어 액션 정보가 대상 TDO의 실행 명령을 포함하는 경우, 트리거는 대상 TDO의 활성화를 수신기에 요청할 수 있다. 또한, 액션 정보가 대상 TDO의 연장 명령을 포함하는 경우, 트리거는 대상 TDO가 연장될 것임을 수신기에 지시할 수 있다. 그리고, 액션 정보가 대상 TDO의 종료 명령을 포함하는 경우, 트리거는 대상 TDO가 종료되어야 함을 수신기에 지시할 수 있다. 이와 같이 방송국은 트리거를 통해 실시간 방송 컨텐트에 따른 수신기에서의 TDO 동작을 제어할 수 있다.
한편, 트리거 시간은 대상 TDO에 대해 지정된 액션을 수행(트리거)하기 위해 지정된 시간을 의미할 수 있다. 또한, 트리거 시간은 NRT 서비스를 실시간 방송과 연계하기 위하여, 특정 가상 채널의 비디오 스트림과 동기화시킬 수 있다. 따라서, 방송국은 비디오 스트림에서 참조하는 PCR을 참조하여 트리거 시간으로 지정할 수 있다. 또한, 수신기는 비디오 스트림이 참조하는 PCR을 참조하여 방송국이 지정한 시간에 TDO를 트리거 할 수 있다. 그리고, 방송국은 정확한 트리거 시간을 전송하기 위하여 비디오 스트림의 헤더에 트리거 식별자를 포함하여 트리거를 시그널링 할 수 있다.
또한, 트리거 시간은 UTC 시간으로 지정될 수 있다. UTC 시간의 경우는 상대적인 시간이 아니라, 절대적인 시간을 참조하여 트리거 할 수 있는 장점이 있다.
이와 같은 트리거 시간은 정확한 트리거 시점일 수 있으며, 대략적인 시작 시간을 포함할 수도 있다. 그리고, 수신기는 대략적인 시간을 수신하여 정확한 트리거 시점 이전에 미리 대상 TDO에 대한 액션을 준비할 수 있다. 예를 들어, 수신기는 미리 TDO를 실행할 준비를 하여 트리거 시간에 자연스럽게 TDO를 동작시킬 수 있다.
도 25는 본 발명의 일 실시 예에 따라 구성한 트리거의 비트스트림 신택스를 도시한 것이다.
여기서, 트리거 또는 트리거 데이터는 트리거 테이블의 형태로 구성하였고, 해당 신택스는 이해를 돕기 위하여 MPEG-2 프라이빗 섹션(Private section) 형태로 작성되었으나, 해당 데이터의 포맷은 어떠한 형태가 되어도 무방하다. 예를 들어, SDP(Session Description Protocol)의 형태로 표현하여 SAP(Session Announcement Protocol)을 통하여 시그널링하는 등의 다른 방법도 사용할 수 있다.
table_id 필드는 임의로(0XTBD) 설정되어, 해당 테이블 섹션이 트리거를 구성하는 테이블 섹션임을 식별한다.
section_syntax_indicator 필드는 1로 설정되면, 상기 섹션이 일반적인 섹션 신택스를 따름을 나타낸다.
private_indicator 필드는 1로 설정되어 있다.
section_length 필드는 section_length 필드 바로 다음에서부터 상기 섹션의 마지막까지 이 섹션에 남아 있는 바이트들의 개수를 상술한다.
source_id 필드는, 가상 채널과 연관된 프로그램의 소스를 나타낸다.
TTT_version_number 필드는 트리거의 버전 정보를 나타낼 수 있다. 또한, 트리거의 버전 정보는 트리거 프로토콜의 버전을 나타낼 수 있다. 트리거 버전 정보는 트리거 구조 또는 트리거 자체에 변화가 있는지 판단하기 위하여 사용될 수 있다. 예를 들어, 수신기는 트리거의 버전 정보가 동일하면 트리거에 변화가 없음을 판단할 수 있다. 또한 수신기는 트리거의 버전 정보에 변경이 있는 경우, 트리거에 변화가 있음을 판단할 수 있다. 예를 들어, 트리거 버전 정보는 복수의 버전 넘버를 포함할 수 있으며, 수신기는 복수의 버전 넘버 중 일부에 기초하여 트리거에 변화가 발생하였는지 판단할 수 있다.
current_next_indicator 필드는 1로 설정되어 있으면 해당 테이블 섹션은 현재 적용 가능함을 나타낸다.
section_number 필드는, 해당 테이블 섹션의 넘버를 지시한다.
last_section_number 필드는, 섹션들 중 가장 마지막 및 가장 높은 넘버의 테이블 섹션을 의미한다.
num_triggers_in_section 필드는, 해당 테이블 섹션 내에 포함되는 트리거의 개수를 의미한다. 한 섹션에 포함되는 트리거의 개수는 1개일 수 있으며, 복수일 수도 있다. 또한, 다음의 'for' 루프는 트리거의 개수만큼 반복될 수 있다.
trigger_id 필드는, 트리거를 유일하게 식별할 수 있는 식별자를 나타낸다.
trigger_time 필드는, 트리거를 수행하는 시간을 나타낸다. 한편 이 필드는 섹션 내에 포함되지 않을 수 있으며, 그 경우 트리거 시간은 상술한 바와 같이 방송 스트림으로부터 지정된 시간일 수 있다.
trigger_action 필드는, 트리거 시간에 수행될 트리거의 액션 정보를 나타낸다. 트리거 액션은 상술한 바와 같이 대상 TDO에 대한 준비, 대상 TDO의 실행, 대상 TDO의 연장 또는 대상 TDO의 종료 명령 중 어느 하나를 포함할 수 있으며, 대상 TDO내의 특정 함수나 이벤트를 발생하도록 하는 명령을 포함할 수도 있다.
trigger_description_length 필드는, trigger_description_text의 길이를 나타낸다.
trigger_description_text 필드는, 해당 트리거에 대한 텍스트 형태의 디스크립션을 나타낸다.
service_id_ref 필드는, 트리거의 대상 TDO를 식별하기 위한 식별자를 나타낸다. 따라서, 예를 들어 service_id_ref 필드는 트리거의 대상 TDO의 NRT 서비스를 식별하기 위해 SMT 또는 NST의 NRT_service_id 필드를 지시할 수 있다.
content_linkage 필드는, 트리거의 대상 TDO 컨텐트 아이템을 식별하기 위한 식별자를 나타낸다. 예를 들어, content_linkage 필드는 트리거의 대상 TDO 컨텐트 아이템을 식별하기 위해 NRT-IT 또는 NCT의 content_linkage 필드를 지시할 수 있다. 또한, service_id_ref 필드와 content_linkage 필드는 하나의 대상 TDO를 지시하기 위한 클래스 내에 포함될 수도 있다.
num_trigger_descriptors 필드는, 트리거 디스크립터의 개수를 나타낸다.
trigger_descriptor()필드는, 트리거에 대한 정보를 포함하는 디스크립터를 나타낸다.
이와 같이 MPEG2 프라이빗 섹션의 테이블 형태로 구성되는 트리거의 경우, 방송국은 가상 채널에 따라 하나의 트리거를 전송할 수 있다.
방송국이 트리거를 전송하기 위한 제1 방법으로서, 상술한 트리거 테이블을 PSIP 기본 PID인 0X1FF 스트림에 포함하여 전송할 수 있다. 제1 방법은 트리거 테이블의 table_id를 유일하게 할당함으로써 트리거 테이블을 다른 테이블과 구별할 수 있는 특징이 있다.
그리고, 트리거를 전송하기 위한 제2 방법으로서, 마스터 가이드 테이블(Master Guide Table, MGT)에 트리거 테이블에 대응하는 PID를 할당하고, 해당PID의 스트림에 트리거 테이블을 포함하여 전송할 수 있다. 제2 방법은 수신기가 해당 PID의 스트림 내에 있는 모든 테이블을 트리거 테이블로 처리할 수 있는 특징이 있다.
한편, 본 발명에서는 비디오 및 오디오에 동기화된 정확한 시점을 트리거 시간으로 지정하기 위해 MPEG2 PES(Packetized Elemetary Stream)을 통해 트리거 및 트리거 시그널링 정보중 적어도 하나를 전송하는 것을 일 실시예로 한다.
여기서, MPEG2 PES의 비디오 및 오디오의 동기화를 설명하면 다음과 같다. 수신기 디코더는 송신기 인코더의 시간 스탬프에 의해 동기화하여 동작한다. 인코더는 System Time Clock(이하, STC라 함)이라는 주 오실레이터(main oscillator)와 카운터(counter)를 가지고 있다. STC는 특정 프로그램에 속해 있고 비디오와 오디오 인코더를 위한 프로그램의 주 클럭(main clock)이다.
한편, 인코더 입력에서 비디오 프레임이 발생하거나 오디오 블럭이 발생하면 STC를 샘플링하도록 한다. 샘플링 값과 인코더 버퍼와 디코더 버퍼의 지연만큼의 상수값을 더하여 표시 시간 정보, 즉 Presentation Time Stamp(이하, PTS라 한다)를 생성하고 픽쳐 블록(picture block) 또는 오디오 블록(audio block)의 처음 부분에 삽입한다. 프레임 재배치(frame reordering)가 발생하는 경우에는 데이터가 디코더에서 디코딩되어야 하는 시간을 나타내는 Decode Time Stamp(이하, DTS라 함)를 삽입한다. B 픽쳐의 프레임 재배치의 경우를 제외하고는 DTS와 PTS는 동일하다. DTS는 이러한 프레임 재배치의 경우에만 추가적으로 필요하다. DTS가 사용될 때는 항상 PTS도 존재하며 이들은 700msec 이내의 간격으로 삽입될 수 있다. 또한, ATSC에서는 각각의 픽쳐의 시작부분에 PTS와 DTS를 삽입하도록 정의되어있다.
한편, 인코더 버퍼의 출력에는 전송 패킷(transport packet) 레벨에서는 프로그램 클럭 레퍼런스(Program Clock Reference; 이하 PCR이라고 함)이라는 타임 스탬프를 갖는다. 그리고, PCR 타임 스탬프는 100msec이내의 간격으로 발생할 수 있으며, 이러한 PCR 은 디코더의 STC와 인코더의 STC를 동기화하기 위해 사용된다.
그리고, 비디오 스트림과 오디오 스트림은 디코더의 동기화를 위해 공통된 STC에 해당하는 각각의 PTS 또는 DTS를 가질 수 있다. 따라서, 오디오 스트림과 비디오 스트림이 디코딩 단위마다 언제 재생해야 하는지를 각 PTS와 DTS를 통하여 알 수 있게 되며, 이를 이용하여 오디오와 비디오가 동기화된다.
예를 들어 설명하면, 수신기의 디코더는 수신된 TS 스트림에서 PES 패킷을 비디오 PES 디패킷타이저(Video PES Depacketizer)로 출력하고, TS 패킷 헤더에 삽입된 PCR값을 PCR 카운터(PCR Counter) 로 출력한다. PCR 카운터는 PCR값 100을 카운팅시켜 비교부로 출력한다. 그리고, 비디오 PES 디패킷타이저는 PES 패킷의 헤더를 DTS/PTS 추출부(DTS/PTS Extractor)로 출력하고, ES(Elementary Stream), 즉 디스플레이될 영상 데이터를 엘레멘터리 스트림 버퍼&디코더(Elementary Stream Buffer&Decoder)에 버퍼링한다. DTS/PTS 추출부는 PES 패킷 헤더로부터 DTS값과 PTS값을 추출하여 비교부로 출력한다. 비교부는 상기 PCR 카운터로부터 입력받은 PCR값이 DTS값으로 되거나, PCR값 100이 PTS값으로 되면 그에 대한 각각의 신호를 디코딩/디스플레이 콘트롤부(Decoding, Display Control Block)로 출력한다. 상기 디코딩/디스플레이 콘트롤부는 상기 비교부로부터 PCR값이 DTS값으로 된 것에 대한 신호를 입력받아 상기 엘레멘터리 스트림 버터&디코더에 버퍼링된 영상 데이터를 디코딩하여 디코디드 스트림 메모리(Decoded StreamMemory)에 저장시킨다. 또한 디코딩/디스플레이 콘트롤부는 비교부로부터 PCR값이 PTS값으로 된 것에 대한 신호를 입력받으면 디코디드 스트림 메모리에 디코딩되어 저장된 영상 데이터를 디스플레이부를 통해 디스플레이한다.
따라서, MPEG2 PES는 헤더에 PTS와 DTS를 포함하여, 데이터 전송시 전송되는 데이터와 하나의 엘레멘터리 스트림(Elementray Stream, ES) 또는 복수의 ES간의 표시되는 시간(Presentation time)을 동기화할 수 있다. 이를 동기화된 데이터 스트림(synchronized data stream)방식이라 할 수 있다.
즉, 본 발명의 일 실시예에 따르면, 방송국은 이와 같은 동기화된 데이터 스트림 방식을 이용하여 트리거 데이터 또는 트리거 스트림을 PES의 페이로드에 포함시키고, 트리거 시간을 PES 패킷 헤더의 PTS값으로 지정할 수 있다. 이 경우, 수신기는 트리거를 포함하는 PES의 PTS가 참조하는 PCR값에 따라 정확한 시간에 대상 TDO를 트리거 할 수 있다. 따라서, 방송국은 트리거 시간으로 지정된 PES 패킷 헤더의 PTS와 오디오 및 비디오 PES 패킷 헤더의 PTS값을 이용하여 방송국이 트리거하고자 하는 오디오 및 비디오가 재생(Presentation)되는 정확한 시간에 트리거를 동기화할 수 있다.
그리고, 트리거를 포함하는 PES 스트림 패킷의 헤더는 동기화된 데이터 스트림 방식을 나타내기 위해 steam_type값이 0x06일 수 있으며, stream_id는 기 설정된 스트림의 식별자를 나타낼 수 있고, PES_packet_length는 PES 스트림의 페이로드를 포함하는 PES 스트림의 길이를 나타낼 수 있다.
도 26은 본 발명의 일 실시예에 따라 트리거가 포함된 동기화된 데이터 스트리밍 방식에 따른 PES의 구조를 도시한 도면이다.
도 26과 같이, 동기화된 데이터 스트리밍 방식의 PES는 PES 헤더와 PES 페이로드로 구성될 수 있으며, PES 페이로드는 동기화된 데이터 패킷 구조(Synchronized Data Packet Structure)를 포함할 수 있다. 상술한 바와 같이 트리거 테이블로 구성되거나, 다른 형식의 데이터로 구성된 트리거는 도 26의 PES 페이로드(payload) 부분에 포함되어 전송될 수 있다. 또한, 방송국은 트리거를 IP데이터그램의 형태로 패킷화하고, 패킷화된 트리거를 IP 데이터 영역에 포함하여 전송할 수도 있다.
도 27은 본 발명의 일 실시예에 따라 트리거를 전송하기 위한 PES 페이로드의 동기화된 데이터 패킷 구조(synchrozied data packet structure)를 비트스트림 신택스로 도시한 것이다.
도 26 및 도27과 같이, 트리거는 동기화된 데이터 패킷 구조 내에 포함되어 전송될 수 있다. 구조내 각 필드의 상세한 설명은 다음과 같다.
data_identifier 필드는, PES 데이터 패킷에 포함된 데이터의 타입을 식별하기 위한 식별자이다. 이는 데이터 타입에 따라 0X22로 설정될 수 있다.
sub_stream_id 필드는, 사용자에 의해 설정가능한 식별자이다(user private).
PTS_extention_flag 필드는, PTS 확장 필드(PTS_extention field)가 존재하는지를 지시한다. 이 필드의 값이 1이면 PES_data_packet 필드에 PTS 확장 필드가 존재할 수 있다. 또한, PTS 확장 필드가 존재하지 않으면 이 필드의 값은 0일 수 있다.
output_data_rate_flag 필드는, 0으로 설정될 수 있다.
syncnronized_data_packet_header_length필드는, PES 패킷 헤더에 포함된 선택적 필드(optional field)의 길이를 나타낸다. 이 필드는 PTS_extention_flag 필드가 1일 때 포함될 수 있으며, synchroziced_data_privete_data_byte(s)를 포함하는 길이를 나타낼 수 있다.
PTS_extension 필드는, 해당 PES 패킷의 헤더로부터 전달된 PTS를 확장한다. 이 필드는 9비트의 PCR(Program Clock Reference) 확장 정보를 포함할 수 있다. 또한, 수신기는 이 필드를 통하여 동기화된 데이터의 PTS 해상도를 MPEG2 표준인 11.1 마이크로초(90kHz)로부터 37나노초(27MHz)로 확장할 수 있다.
synchronized_data_private_data_byte 필드는, 동기화된 PES 패킷의 페이로드의 바이트를 나타낸다. 만약 데이터 서비스 테이블(DST)의 protocol_encapsulation필드가 동기화된 데이터그램, LLC/SNAP을 포함하지 않는 IP 데이터그램, LLS/SNAP를 포함하는 다중프로토콜(multiprotocol) 데이터그램 중 어느 하나임을 나타내면, synchronized_data_byte 필드는 유일한 하나의 데이터그램을 포함할 수있다. 따라서, LLC/SNAP가 사용되는 경우에는 오직 PES패킷의 처음 8 바이트의 synchronized_data_byte에만 8바이트의 LLC/SNAP 헤더가 나타날 수 있다.
따라서, 방송국이 상술한 바와 같은 PES의 동기화된 데이터 스트림(stream_type이 0x06)에 트리거를 포함하여 전송하면, 수신기는 트리거 스트림을 PES의 페이로드로부터 추출할 수 있다. 또한, 수신기는 PES헤더의 PTS값을 트리거 시간으로 하여 대상 TDO에 대한 액션을 수행할 수 있게 된다. 따라서, 비디오와 오디오의 표시 동기를 위한 기준 시간인 PTS를 기준으로 트리거를 동기화 함으로써, 프레임단위의 정확한 시간에 TDO가 트리거될 수 있다. 또한, 트리거 시간을 PTS로 지정하는 경우, 비디오 및 오디오와의 동기화가 쉽게 이루어질 수 있다.
한편, 본 발명에서는 트리거 스트림을 획득할 수 있는 트리거 시그널링 정보를 전송하는 것을 일 실시예로 한다. 수신기는 트리거 시그널링 정보를 수신하고, 수신한 트리거 시그널링 정보에 기초하여 PES의 동기화된 데이터 스트림에 포함된 트리거 스트림을 획득할 수 있다.
동기화된 데이터 스트리밍을 이용하여 전송되는 트리거 스트림을 획득하기 위한 트리거 시그널링 정보를 전송하는 방법은 실시예에 따라 다양한 방법이 있을 수 있다. 본 발명에서는 1. DST를 통한 전송 방법, 2. 서비스 식별자 디스크립터(service id descriptor)를 통한 전송 방법, 3. 트리거 스트림 디스크립터(trigger stream descriptor)를 통한 전송 방법 또는 4. 트리거 스트림에 대한 스트림 타입을 정의하여 전송하는 방법 중 적어도 하나의 방법을 사용하여 트리거 시그널링 정보를 전송하는 것을 일 실시예로 한다.
일 실시예에 따라, 본 발명에서는 NRT 서비스를 위한 DST(data_service_table)를 통하여 트리거 시그널링 정보를 전송할 수 있다. DST는 데이터 서비스를 전송하기 위한 테이블 섹션으로서, DST에 대한 설명 및 DST를 구성하는 data_service_bytes()의 일 실시예에 대한 설명은 도 8에서 설명한 바와 같으므로 생략하기로 한다.
상술한 DST에는 데이터 서비스를 구성하는 각 엘레멘터리 스트림(Elementray Stream, ES)을 수신하기 위한 시그널링 데이터가 포함될 수 있다. 따라서, 트리거 스트림을 수신하기 위한 트리거 시그널링 데이터도 DST에 포함될 수 있다.
한편, 데이터 서비스는 각각 하나 이상의 어플리케이션을 포함할 수 있으며, 각 어플리케이션은 app_id와 같은 어플리케이션 식별자를 포함하는 어플리케이션 식별 구조(application identification structure)의 형태일 수 있다. 그리고, 각 어플리케이션은 해당 어플리케이션을 구성하는 하나 이상의 데이터 엘리먼트(data element) 또는 데이터 스트림(data stream)을 포함할 수 있다.
따라서, 방송국은 트리거 스트림을 데이터 서비스를 통해 전송하기 위해 특정 가상 채널(Virtual Channel, VC)에 하나의 트리거 스트림을 포함하여 전송할 수 있다. 뿐만 아니라 어플리케이션마다 하나의 트리거 스트림을 포함하여 전송할 수도 있다. 따라서, 하기에 두 가지 방법에 대해 경우를 나누어 트리거 시그널링 정보를 전송하는 일 실시예들을 설명한다.
가상 채널에 하나의 트리거 스트림이 포함되는 경우, 본 발명의 일 실시예에서는 트리거 스트림을 전송하기 위한 데이터 서비스를 트리거 서비스라고 할 수 있다. 이 경우, 방송국은 고정된 서비스 식별자(Service ID)를 트리거 서비스에 할당할 수 있다.
따라서, 수신기는 예를 들어, 서비스 식별자가 고정된 값으로서 0X01인 경우에 해당 가상 채널에 하나의 트리거 스트림이 전송되고 있음을 식별할 수 있다.
여기서, 방송국은 DST에 포함된 어플리케이션 식별 구조(Application identification structure)에 트리거 시그널링 정보를 포함하여 전송할 수 있다.
예를 들어, 방송국은 DST의 App_id_description 필드의 값으로 0x0001을 추가하여 TDO와 같은 형태의 NRT 서비스를 실시간 방송과 연계하기 위한 양방향 어플리케이션을 의미하는 값으로 설정할 수 있다. 또한, app_id_byte_length는 0x0003으로 3바이트를 사용하며, app_id_byte는 0x01로 할당하여 해당 데이터 서비스가 트리거 스트림 시그널링 정보를 포함하는 것을 지시할 수 있다.
따라서, 수신기는 상술한 방법으로 DST를 수신하여 app_id_byte_length가 0x0003이고, app_id_description이 0x0001이며, app_id_byte가 0x01인 경우 트리거 시그널링 정보를 포함하는 tap()을 식별할 수 있다. 수신기는 식별된 tap()구조로부터 association_tag값을 포함하는 트리거 시그널링 정보를 추출하며, 방송 스트림에서 추출한 PMT 내에 리스트 된 데이터 엘리먼트리 스트림(ES) 중 association_tag_descriptor가 상기 추출된 association_tag와 일치하는 PID를 갖는 스트림을 수신하여 트리거 스트림을 수신할 수 있다.
상술한 바와 같이, NRT 서비스는 SMT 또는 NST를 통해 시그널링 되며, 16비트의 서비스 식별자(service_id)를 통해 유일하게 식별될 수 있다. 또한, NRT 서비스를 구성하는 컨텐트 아이템들은 NCT 또는 NRT-IT내의 content_linkage 또는 컨텐트 식별자를 통해 식별될 수 있다. 따라서, DST를 통해 app_id_byte를 확장하여 트리거 서비스를 NRT 서비스와 같이 전송할 수 있다. 예를 들어, app_id_byte는 트리거 서비스의 서비스 식별자(service id)필드 및 컨텐트 결합(content_linkage)필드를 조합한 데이터를 포함할 수 있다. 따라서, app_id_byte를 처음 16비트는 SMT 또는 NST 내의 서비스 식별자(service id) 필드에 대응되며, 이후 32비트는 NCT 또는 NRT-IT내의 content linkage 필드에 대응되도록 구성할 수 있다.
이와 같이, 방송국은 가상 채널당 하나의 스트림이 포함되는 경우, DST상의 어플리케이션 식별 구조(Application identification structure)를 통해 트리거 시그널링 정보를 tap()에 포함하여 전송할 수 있다.
한편, 본 발명의 일 실시예에서는 DST의 protocol_encapsulation 필드를 이용하여 트리거 시그널링 정보를 전송할 수 있다. 예를 들어, DST내 app_id_byte_length를 0x0000으로 설정하면 app id가 할당되지 않으며, protocol_encapsulation 필드의 값이 0x0F인 경우에 트리거 시그널링 정보가 해당 tap()구조에 포함되어 있음을 지시할 수 있다. 따라서, 수신기는 app_id_byte_length가 0x0000이고, protocol_encapsulation 필드의 값이 0x0F이면, 해당 tap()구조로부터 트리거 시그널링 정보를 수신할 수 있으며, 이를 통하여 상술한 바와 같이 트리거 스트림을 지시하는 PMT상의 PID값을 획득하고, 트리거 스트림을 수신할 수 있다.
한편, 본 발명의 다른 일 실시예에서는 DST의 content type descriptor 필드를 이용하여 트리거 시그널링 정보를 전송할 수 있다.
도 28과 같이, DST상의 tap()에 포함될 수 있는 content type descriptor 구조의 일 실시예는 다음과 같다.
descriptorTag 필드는 contentTypeDescriptor를 나타내기 위한 0x72값을 가질 수 있다.
descriptorLenth 필드는 디스크립터의 전체 길이(바이트 단위)를 나타낸다.
contentTypeByte 필드는 본 디스크립터가 연결되어 있는 tap에 의해 참조된 데이터의 MIME 미디어 타입 값을 나타낸다. MIME 미디어 타입은 RFC2045 섹션 [8]의 5에 정의되어 있다.
따라서, 본 발명의 일 실시예에서는 트리거 시그널링 정보를 포함하는 tap()구조에 content type descriptor를 부가할 수 있다. 따라서, 수신기는 app_id_byte_length가 0x0000이고, tap()구조의 content type descriptor가 기 설정된 내용과 일치하면 해당 tap()구조로부터 트리거 시그널링 정보를 수신할 수 있으며, 이를 통하여 상술한 바와 같이 트리거 스트림을 지시하는 PMT상의 PID값을 획득하고, 트리거 스트림을 수신할 수 있다. content type descriptor로부터 트리거 서비스 시그널링 정보가 존재함을 식별하기 위해, MIME 미디어 타입은 특정 타입으로 지정될 수 있다.
상술한 바와 같이, 하나의 NRT 서비스가 트리거 스트림을 전송하기 위한 트리거 서비스일 수 있으며, 트리거 서비스 내의 컨텐트 아이템별로 각각 다른 트리거 스트림을 전송할 수도 있다. 이 경우, 각 어플리케이션은 하나의 트리거 스트림을 포함할 수 있다.
따라서 본 발명의 일 실시예에서는 NRT 서비스의 각 컨텐트 아이템에 트리거 스트림을 포함하여 전송할 수 있다. 이 경우, 상술한 어플리케이션 식별 구조(Application identification structure)를 이용할 수 있다. 예를 들어, app_id_byte_length를 0x0003인 경우는 하나의 서비스 식별자를 이용하여 하나의 NRT 서비스를 통해 트리거 스트림을 전송함을 나타내고, 0x0007인 경우는 서비스 식별자 및 컨텐트 결합(content linkage)을 이용하여 컨텐트 아이템별로 트리거 스트림을 전송함을 나타낼 수 있다. 이와 같이 정의한 경우, 각 NRT 서비스 또는 컨텐트 아이템에 대응하여 각각의 트리거 스트림을 전송할 수 있다. 이후 단계의 트리거 시그널링 정보 전송 방법 및 트리거 스트림 수신 방법은 가상 채널당 하나의 트리거 스트림을 포함하는 경우와 동일하므로 생략하기로 한다.
도 29는 PMT의 신택스와 서비스 식별자 디스크립터의 일 실시예를 도시하고 있다.
도 29와 같이, PMT(Program Map Table)는 각 채널에서 방송되는 프로그램에 대한 정보를 나타낸다. PMT는 'packet ID'가 '0x00'으로 정의되어 전송되는 PAT(Program AssociationTable)에서, PMT가 전송되는 'packet ID'를 파싱하여서, PMT를 수신할 수 있다.
한편, 서비스 식별자 디스크립터는 PMT의 엘리멘터리 스트림(ES)별 디스크립터 루프(loop)에 포함될 수 있다. 그리고, 각 프로그램 엘리먼트에 포함된 서비스의 목록 정보를 포함할 수 있다.
서비스 식별자 디스크립터의 구조를 설명하면 다음과 같다.
descriptor_tag 필드는, 본 디스크립터가 service_id_descriptor()임을 나타내기 위한 필드이며, 0xC2값을 가질 수 있다.
descriptor_length 필드는, 본 필드 다음부터 본 디스크립터의 종료시까지 의 바이트 단위 길이를 나타낸다.
service_count 필드는, 본 디스크립터가 붙어 있는 프로그램 엘리먼트에 포함된 서비스의 개수를 지시한다.
service_id 필드는, 본 디스크립터가 붙어 있는 프로그램 엘리먼트에 포함된 서비스 식별자를 나타낸다.
본 발명의 일 실시예에서 트리거 스트림은 기 설정된 IP 주소(Well-known IP address)를 통해 전송될 수 있다. 그리고, 방송국은 트리거를 시그널링 하기 위해 트리거 스트림에 대응하는 특정 서비스 식별자(service id, 예를 들어 0x01)를 서비스 식별자 디스크립터에 포함하여 전송할 수 있다. 즉, 트리거 스트림을 수신하기 위한 트리거 시그널링 정보는 서비스 식별자 디스크립터를 통해 전송될 수 있다. 따라서, 수신기는 PMT의 ES 루프 내의 ES descriptor 루프에 포함된 service_id_descriptor의 서비스 식별자가 0x01인 경우, ES 루프 내의 elementray_PID가 트리거 스트림을 지시하는 PID라고 판단할 수 있으며, 이 PID를 이용하여 트리거 스트림을 수신할 수 있다.
도 30은 본 발명의 일 실시예에 따른 트리거 스트림 디스크립터를 도시한 도면이다. 본 발명의 일 실시예에 따르면 트리거 스트림 디스크립터를 이용하여 트리거를 시그널링할 수 있다. 상술한 서비스 식별자 디스크립터와 마찬가지로, 트리거 스트림 디스크립터는 PMT의 ES 루프 내 ES descriptor 루프에 포함될 수 있다. 따라서, 트리거 스트림이 존재하는 경우 ES descriptor 루프에 트리거 스트림 디스크립터가 존재할 수 있다. 수신기는 트리거 스트림 디스크립터를 식별한 경우, 해당 ES 루프 내 elementray_PID로부터 트리거 스트림의 PID를 획득하여 트리거 스트림을 수신할 수 있다.
이와 같이 트리거 시그널링 정보를 전송하기 위한 트리거 스트림 디스크립터는 트리거 스트림내 트리거의 대상이 되는 TDO의 서비스 식별자(target service id) 또는 트리거 스트림을 전송하는 IP 주소 리스트 중 적어도 하나를 포함할 수 있다. 도 30의 트리거 스트림 디스크립터는 일 실시예이며, 구조에 대한 설명은 다음과 같다.
descriptor_tag 필드는, 기 설정된 값인 경우 트리거 스트림 디스크립터(trigger_stream_descriptor)임을 나타낸다.
descriptor_length 필드는, 본 필드 다음부터 본 디스크립터의 종료시까지 바이트 단위 길이를 나타낸다.
target_service_count 필드는, 트리거 스트림에 포함된 하나 이상의 트리거들의 대상 NRT 서비스(TDO)의 개수를 나타낸다.
target_service_id 필드는, 트리거 스트림에 포함된 하나 이상의 트리거들의 대상 NRT 서비스(TDO)의 서비스 식별자(service_id)를 나타낸다. 수신기는 target_service_id 필드를 이용하여, 트리거 스트림을 수신하기 전이라도 대상 TDO의 서비스 식별자(service_id)를 알 수 있다.
target_content_item_count 필드는, 트리거 스트림에 포함된 하나 이상의 트리거들의 대상 NRT 서비스 컨텐트 아이템의 개수를 나타낸다.
target_content_linkage 필드는, 트리거 스트림에 포함된 하나 이상의 트리거들의 대상 NRT 서비스 컨텐트 아이템 결합(content_linkage)을 나타낸다.
한편, 트리거 스트림 디스크립터는 일 실시예이므로, 추가적인 정보를 부가하거나 다른 형태로 구성할 수 있는 점은 자명할 것이다. 예를 들어, 가상 채널 당 하나의 트리거 스트림을 전송하는 경우에는 컨텐트 아이템에 관한 필드는 생략할 수 있다. 또한 트리거 스트림을 식별하기 위한 트리거 스트림 식별 정보 필드 또는 프로필 정보 필드 중 적어도 하나가 부가될 수 있다.
방송국은 상술한 트리거 스트림 디스크립터를 이용하여 TDO와 같은 트리거 대상 NRT 서비스의 목록 정보를 전송할 수 있다. 또한, 방송국은 컨텐트 아이템에 따라 다른 트리거가 존재하는 경우에는 target_service_id 및 targe_content_linkage필드를 이용하여 트리거 시그널링 정보를 전송할 수 있다. 또한, 트리거 스트림 디스크립터는 트리거 스트림을 전송하는 IP 주소 정보 또는 포트 넘버의 목록을 더 포함할 수 있다.
한편, 본 발명의 일 실시예에 따르면, 방송국은 스트림 타입을 지정하여 트리거 시그널링 정보를 전송할 수 있다. 수신기는 PMT로부터 스트림 타입을 이용하여 트리거 시그널링 정보를 추출하고, 이를 통하여 트리거 스트림을 수신할 수 있다. 예를 들어, 현재 예비적으로 설정되어 있는 스트림 타입중 하나인 0x96을 트리거 스트림으로 지정할 수 있다. 이 경우, 종래의 수신기는 스트림 타입이 0x96인 경우에 대한 정보가 없으므로, 트리거 스트림을 처리하지 않고 버릴 수 있다. 따라서, 하위 기종의 수신기에 대한 호환성이 보장되는 장점이 있다.
본 발명의 일 실시예에 따르면 MHP(Multimidia Home Platform) 또는 ACAP(Advanced Common application platform)등의 데이터 방송에서 어플리케이션 정보를 전송하기 위한 AIT(Application information)테이블에 트리거를 포함하여 전송할 수 있다. 도 31은 이와 같은 AIT테이블의 일 실시예를 도시하고 있다.
그리고, 본 발명의 다른 일 실시예에 따르면 트리거 시간으로서 STT(System Time Table)를 참조하기 위해 트리거를 STT의 디스크립터에 포함하여 전송할 수도 있다. 도 32는 이와 같은 STT 테이블의 일 실시예를 도시한다.
도 33은 본 발명의 일 실시예에 따른 TDO 및 트리거를 송신하기 위한 송신기를 개략적으로 나타낸 블록도이다.
도 33을 참조하면, 본 발명의 일 실시예에 따른 송신기(200)는 NRT 서비스 전송부(210), 트리거 전송부(220), 다중화부(230) 및 변조부(240)를 포함하여 구성되며, NRT 서비스 전송부(210)는 NRT 서비스(TDO)생성부(211) 및 NRT 서비스 시그널링 데이터 생성부(212)를 포함하고, 트리거 전송부(220)는 트리거 생성부(221) 및 트리거 시그널링 데이터 생성부(222)를 포함하여 구성된다.
NRT 서비스(TDO)생성부(211)는 서비스 제공자로부터 NRT 서비스 생성을 위한 데이터를 수신하여 NRT 서비스를 생성하고, 생성된 NRT 서비스를 IP 데이터그램으로 패킷화하고, 이를 다시 전송 패킷(TP)으로 패킷화한다. 패킷화된 NRT 서비스 데이터는 다중화부(230)로 전송된다.
그리고, NRT 서비스 생성부(211)는 NRT 서비스 시그널링 데이터 생성부(212)로 NRT 서비스를 전송하고자 하는 채널 정보 및 service_id를 포함하는 메타데이터를 전송한다. 또한, 생성된 NRT 서비스가 TDO인 경우에는, TDO를 트리거 하기 위한 트리거 시간, 대상 TDO의 식별 정보 및 트리거 액션 정보를 포함하는 트리거 정보를 추출하여 트리거 생성부(221)로 전송한다.
NRT 서비스 시그널링 데이터 생성부(212)는 수신한 NRT 서비스 메타데이터를 이용하여 NRT 서비스를 수신하기 위한 NRT 서비스 시그널링 데이터를 생성하고, 전송 패킷(TP)으로 패킷화 한 뒤, 다중화부(230)로 전송한다.
한편, 트리거 생성부(221)는 NRT 서비스(TDO) 생성부로부터 수신한 TDO의 트리거 정보를 이용하여 트리거 데이터를 생성한다. 생성된 트리거 데이터는 전송 패킷화 되어 다중화부(230)로 전송된다. 그리고 트리거 생성부(221)는 전송한 트리거 데이터의 패킷 식별자(PID)와 같은 트리거 수신을 위한 메타데이터를 트리거 시그널링 데이터 생성부(222)로 전송한다.
트리거 시그널링 데이터 생성부(222)는 수신한 메타데이터에 기초하여 트리거 시그널링 데이터를 생성하고, 이를 다시 전송 패킷화 하여 다중화부(230)로 전송한다.
다중화부(230)는 수신한 전송 패킷들을 각각의 채널별로 다중화하고, 다중화된 신호를 변조부(240)로 전송한다.
변조부(240)는 다중화된 신호에 대하여 전송을 위한 변조 처리를 거쳐 외부로 송신한다. 변조 방법으로는 다양한 방법이 있을 수 있으며, 본 발명은 변조 방법에 한정되지는 않는다.
도 34는 본 발명의 일 실시예에 따른 TDO 및 트리거를 수신하기 위한 수신기(300)를 개략적으로 나타낸 블록도이다.
도 34와 같이, 본 발명의 일 실시예에 따른 수신기(300)는 복조부(310), 역다중화부(320), 트리거 처리부(330), NRT 서비스 처리부(340) 및 서비스 매니저(350)를 포함하여 구성되며, 트리거 처리부(330)는 트리거 수신부(331) 및 트리거 시그널링 데이터 수신부(332)를 포함하고, NRT 서비스 처리부(340)는 NRT 서비스(TDO) 수신부(341) 및 NRT 서비스 시그널링 데이터 수신부(342)를 포함하여 구성된다.
복조부(310)는 송신기(200)로부터 변조된 신호를 수신하여 기 지정된 복조 방식에 따라 복조하여 역다중화부(320)로 전송한다.
역다중화부(320)는 복조된 신호를 역다중화하여 각 채널별 원래의 전송 패킷들을 복원하여 트리거 처리부(330) 또는 NRT 서비스 처리부(340)의 각 수신부로 전송한다.
NRT 서비스 시그널링 데이터 수신부(342)는 앞서 설명한 바와 같은 패킷화된 NRT 서비스 시그널링 데이터를 역다중화부(320)로부터 수신하고 복원하여 NRT 서비스를 수신하기 위한 정보를 추출한 뒤, 이를 NRT 서비스(TDO) 수신부(341)로 전송한다. NRT 서비스(TDO) 수신부(341)는 NRT 서비스를 수신하기 위한 정보를 이용하여 NRT 서비스의 전송 패킷들을 역다중화부(320)로부터 수신하고, 이를 NRT 서비스 데이터로 복원하여 서비스 매니저(350)로 전송한다.
한편 트리거 시그널링 데이터 수신부(332)는 앞서 설명한 바와 같은 패킷화된 트리거 시그널링 데이터를 역다중화부(320)로부터 수신하여 복원하고, 트리거를 수신하기 위한 정보를 추출하여 트리거 수신부(331)로 전송한다. 트리거 수신부(331)는 트리거를 수신하기 위한 정보를 이용하여 트리거를 포함하는 전송 패킷들을 역다중화부(320)로부터 수신하고, 트리거 데이터를 복원하여 서비스 매니저(350)로 전송한다.
서비스 매니저(350)는 트리거 처리부(330) 또는 NRT 처리부(340)로부터 트리거 데이터 또는 NRT 서비스(TDO) 데이터 중 적어도 하나를 수신한다. 그리고, 서비스 매니저(350)는 트리거 시간에 트리거 대상 TDO에 대하여 트리거 액션을 수행 또는 적용함으로써 TDO에 대한 트리거 액션이 이루어지도록 한다.
도 35는 본 발명의 일 실시예에 의한 트리거 전송 방법을 개략적으로 나타낸 흐름도이다.
도 35를 참조하면, NRT 서비스 생성부(211)는 외부로부터 NRT 서비스 데이터를 수신하거나, NRT 서비스 제공자로부터 수신한 데이터에 기초하여 NRT 서비스 데이터를 생성한다(S100). 그리고, NRT 서비스 생성부(211)는 생성한 데이터를 전송 패킷으로 패킷화한다. 또한, NRT 서비스 생성부(211)는 NRT 서비스를 포함하는 전송 패킷들을 수신하기 위한 정보를 NRT 서비스 시그널링 데이터 생성부(212)로 전송한다.
이후, NRT 서비스 시그널링 데이터 생성부(212)는 앞서 설명한 바와 같은 NRT 서비스 시그널링 데이터를 생성하고, 전송 패킷으로 패킷화한다(S110).
한편, NRT 서비스 생성부(211)는 생성된 NRT 서비스가 트리거 선언적 오브젝트인지, 즉 TDO인지 판단한다(S120).
그리고, NRT 서비스 생성부(211)는 생성된 NRT 서비스가 TDO인 경우에는 대상 TDO를 트리거 하기 위한 트리거 시간, 트리거 액션, 대상 TDO 식별 정보를 포함하는 트리거 정보를 트리거 생성부(221)로 전송하고, 트리거 생성부(211)는 수신한 트리거 정보를 이용하여 트리거 데이터를 생성한다(S130). 생성된 트리거 데이터는 전송 패킷화되어 다중화부로 전송된다. 예를 들어, 대상 TDO에 대한 타겟 서비스 식별자 및 타겟 서비스에 대해 적용할 트리거 액션 정보는 패킷화된 스트림, 즉 PES의 페이로드에 삽입되어 전송될 수 있다. 또한, 트리거 시간 정보는 예를 들어, PTS 또는 DTS의 형태로 지정되어 PES의 페이로드 또는 헤더에 삽입되고, 전송될 수 있다. 이와 같이 동기화된 데이터 스트리밍 방식을 사용하면, 트리거 스트림의 PTS와 비디오 및 오디오 스트림의 PTS가 동기화되어 정확한 재생 타이밍을 맞출 수 있게 된다.
그리고, 트리거 시그널링 데이터 생성부(222)는 트리거 생성부(221)에서 전송한 트리거를 식별하여 수신하기 위한 트리거 시그널링 데이터를 생성하여 전송 패킷화하고, 다중화부로 전송한다(S140). 여기서, 트리거 시그널링 데이터는 프로그램 맵 테이블에 삽입된 트리거 스트림 디스크립터 또는 서비스 식별자 디스크립터를 포함할 수 있으며, 각 디스크립터에 대응되는 트리거 스트림의 패킷 식별자를 포함할 수 있다. 또한, 트리거 시그널링 데이터는 DST의 TAP구조에 포함된 트리거 스트림의 패킷 식별자를 포함할 수도 있다.
이후, 다중화부(230)는 전송 패킷화된 NRT 서비스 데이터, NRT 서비스 시그널링 데이터, 트리거 데이터 및 트리거 시그널링 데이터 중 적어도 하나를 전송 채널별로 다중화하고, 변조부(240)로 전송한다.
그리고, 변조부(240)는 다중화된 신호를 송신하기 위한 변조를 수행하고, 외부 수신기 또는 방송망으로 전송한다(S160).
도 36은 본 발명의 일 실시예에 따른 수신기(300)의 동작을 개략적으로 나타낸 흐름도이다.
먼저 수신기(300)는 전원이 ON 되는 경우, 사용자에 의해 선택된 채널 또는 기 설정된 채널을 선택한다(S200). 그리고, 선택된 채널로부터 수신되는 신호를 복조부(310)에서 복조하고, 역다중화부(320)는 복조된 신호를 전송 채널별로 역다중화한다(S210). 그리고, NRT 서비스 수신부(341) 및 NRT 서비스 시그널링 데이터부 수신부(342)는 앞서 설명한 바와 같이 NRT 서비스 데이터를 수신하여 서비스 매니저(350)로 전송한다.
이후, 트리거 시그널링 데이터 수신부(332) 또는 NRT 서비스 시그널링 데이터 수신부(342)는 트리거 수신이 가능한지 확인한다(S220). 트리거 수신 확인은 상술한 방법들 중 어느 하나를 이용할 수 있다. 즉, 트리거 시그널링 데이터 수신부(332) 또는 NRT 서비스 시그널링 데이터 수신부(342)는 PSIP base PID 또는 MGT에서 트리거에 대응하는 PID를 확인하는 방법, DST의 tap 구조를 이용한 방법, 서비스 식별자 디스크립터 또는 트리거 스트림 디스크립터를 이용한 방법, 트리거 스트림 타입을 이용한 방법, AIT 또는 STT를 이용한 방법 중 어느 하나의 방법을 사용하여 트리거 수신이 가능한지 확인 할 수 있다.
그리고, 트리거 수신이 가능한 것으로 확인된 경우, 트리거 시그널링 데이터 수신부(332)는 트리거 시그널링 데이터를 포함하는 전송 패킷을 수신하여, 트리거 시그널링 데이터를 복원하고, 트리거 수신부(331)로 전송한다(S230).
이후, 트리거 수신부(331)는 트리거 시그널링 데이터를 이용하여 수신한 전송 패킷 중에서 트리거 데이터를 추출하고, 이를 서비스 매니저(350)로 전송한다(S240). 예를 들어, 트리거 수신부(331)는 상술한 트리거 스트림 디스크립터에 대응하는 패킷 식별자를 이용하여 트리거 스트림을 수신할 수 있다. 또한, 트리거 수신부(331)는 트리거 스트림으로부터 트리거 정보를 추출하여 서비스 매니저(350)로 전송할 수 있다. 또한, 수신한 트리거 스트림이 PES인 경우에는, PES의 헤더에 포함된 PTS를 트리거 시간으로 추출하고, PES의 페이로드에 포함된 타겟 서비스 식별자 및 트리거 액션을 추출하여 서비스 매니저(350)로 전송할 수 있다.
그리고, 서비스 매니저(350)는 트리거가 수신된 경우, 트리거 시간에 대상 TDO에 대해 트리거 액션을 수행함으로써, TDO의 트리거가 이루어지도록 한다(S250). 특히, PES의 PTS가 트리거 시간인 경우에는 트리거 스트림의 PTS가 오디오 및 비디오 스트림의 PES의 헤더에 포함된 PTS와 동기화되어 정확한 재생 타이밍을 맞출 수 있다.
도 37은 본 발명의 일 실시예에 따른 트리거 수신 방법 중, 트리거 테이블을 이용하여 수신하는 방법을 나타낸 흐름도이다.
복조부(310) 선택된 채널에 대한 방송 신호를 수신하여 복조한다. 그리고, 트리거 시그널링 데이터 수신부(332)는 역다중화부(320)를 통하여 PSIP 테이블을 수신하며, 수신되는 테이블 중 트리거 테이블이 존재하는지 판단하여 트리거 서비스를 식별한다(S310). 트리거 시그널링 데이터 수신부(332)는 트리거 테이블로 할당한 PID를 MGT 또는 PSIP base 테이블중에서 검색하거나, 트리거 테이블에 할당한 Table_id에 대응되는 테이블을 검색하여 트리거 서비스를 식별할 수 있다.
만약, 트리거 서비스가 식별되지 않는 경우에는 수신기(300)는 일반 방송 서비스를 제공한다.
한편, 트리거 서비스가 식별된 경우, 트리거 수신부(331)는 검색된 트리거 테이블을 수신하여 수신한 트리거 테이블을 파싱한다(S320, S330).
이후, 서비스 매니저(350)는 트리거 테이블에서 파싱된 트리거 시간, 트리거 액션, 대상 TDO 식별 정보를 포함하는 트리거 정보를 수신하여, 해당 트리거 시간에 해당 TDO에 대해 해당 트리거 액션을 수행한다(S340).
도 38은 본 발명의 일 실시예에 따라 DST를 이용하여 트리거 시그널링 정보 및 트리거를 전송하는 경우 수신기(300)의 동작을 나타낸 흐름도이다.
수신기(300)는 물리적 전송 채널이 선택되고(S3000), 튜너에 의해 선택된 채널이 튜닝되면, 튜닝된 물리적 전송 채널로 수신되는 방송 신호로부터 복조부(310) 및 역다중화부(320)를 이용하여 VCT와 PMT를 획득한다(S3010). 그리고, PSI/PSIP 섹션 핸들러 또는 트리거 시그널링 데이터 수신부(332) 또는 NRT 서비스 시그널링 데이터 수신부(342)는 획득된 VCT 및 PMT를 파싱하며, NRT서비스가 있는지 확인한다.
예를 들어, VCT의 service_type필드 값이 0x04 또는 0x08이 아니면 해당 가상 채널은 NRT 전용 서비스를 전송하지 않는다. 이때 해당 가상 채널은 기존 방송 서비스를 전송하므로, 수신기(300)는 해당 가상 채널에 포함된 정보에 따라 적절한 동작을 수행한다. 그러나 service_type 필드 값이 NRT 전용 서비스를 의미하지 않는다 하더라도, 해당 가상 채널은 NRT 서비스를 포함할 수 있다. 이러한 경우 해당 가상 채널에 포함되는 부가 NRT 서비스(adjunct NRT service)라고 부르고, 수신기(300)는 NRT 서비스를 수신하는 경우와 같은 프로세스를 수행할 수 있다.
그리고, NRT 서비스 시그널링 데이터 수신부(342) 또는 트리거 시그널링 데이터 수신부(332)는 service_type 필드의 값이 0x04 또는 0x08이면, 해당 가상 채널을 통해 NRT 서비스를 수신할 수 있음을 판단할 수 있다. 이 경우, VCT의 service location descriptor(또는 PMT의 ES loop)에 포함된 stream_type 필드 값이 0x95(즉, DST 전송)이면, 이때의 Elementary_PID 필드 값을 이용하여 DST를 수신한다(S3020). 이는 서비스 매니저(350)의 제어에 의해 역다중화부(320)에서 수행될 수 있다.
그리고, 트리거 시그널링 데이터 수신부(342)는 수신된 DST로부터 트리거 서비스를 식별한다(S3040). 트리거 서비스를 식별하는 방법은 상술한 바와 같이 어플리케이션 식별 구조(application identification structure)를 이용하여 app_id_description, app_id_byte에 할당된 특정 값을 식별하는 방법, protocol_encapsulation 필드에 할당된 특정 값을 식별하는 방법, content type descriptor가 존재하는 tap을 식별하는 방법 중 어느 하나를 사용할 수 있다.
만약, 수신된 DST에서 트리거 서비스가 식별되지 않는 경우에는 해당 가상 채널은 트리거 데이터가 일반 NRT 서비스를 전송하고 있으므로, 수신기(300)는 해당 가상 채널에 포함된 NRT 서비스에 따라 적절한 동작을 수행한다(S3030).
그리고, DST에서 트리거 서비스가 식별된 경우, 트리거 시그널링 데이터 수신부(332)는 트리거 시그널링 정보(트리거 스트림의 PID)를 포함하는 DST로부터 tap을 추출한다(S3060).
이어서 트리거 시그널링 데이터 수신부(332)는 추출된 Tap의 association_tag를 포함하는 스트림 PID를 PMT로부터 추출한다(S3070).
트리거 수신부(331)는 추출된 스트림 PID에 해당하는 MPEG-2 TS 패킷들을 수신하고 디캡슐레이션 즉, TS 헤더를 제거하여, 트리거 스트림을 포함하는 PES 스트림을 복원한다. 트리거 스트림을 포함하는 PES 패킷의 스트림 타입(stream_type)은 동기화된 데이터 스트림을 나타내는 0x06일 수 있다. 트리거 수신부(331)는 복원된 PES 스트림으로부터 PES패킷 헤더의 PTS, 트리거 스트림에 포함된 대상 TDO 식별자, 트리거 식별자 또는 트리거 액션 정보중 적어도 하나를 파싱한다(S3070).
이후, 서비스 매니저(350)는 트리거를 포함하는 PES 패킷 헤더의 PTS를 트리거 시간으로 하여, 트리거 시간에 대상 TDO에 대한 액션을 수행한다(S3080). 여기서, 대상 TDO는 파싱된 대상 TDO 식별자에 의해 지시된 NRT 서비스일 수 있다. 또한, 액션은 파싱된 트리거 액션 정보에 의해 지시된 준비, 실행, 연장, 종료 명령 중 어느 하나일 수 있다.
도 39는 본 발명의 일 실시예에 따라 트리거 스트림 디스크립터를 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
수신기(300)는 물리적 전송 채널이 선택되고(S3000), 튜너에 의해 선택된 채널이 튜닝되면, 튜닝된 물리적 전송 채널로 수신되는 방송 신호로부터 복조부(310) 및 역다중화부(320)를 이용하여 VCT와 PMT를 획득한다(S4000). 방송 신호는 VCT와 PMT를 포함하며, 트리거 시그널링 데이터 수신부(332) 또는 PSI/PSIP 섹션 핸들러가 획득된 VCT 및 PMT를 파싱한다.
그리고, 트리거 시그널링 데이터 수신부(332)는 VCT와 PMT로부터 해당 가상 채널로 트리거가 전송되고 있는지 확인한다. 이를 위하여 트리거 시그널링 데이터 수신부(332)는 해당 가상 채널에 대응하는 PMT의 ES 디스크립터 루프에 상술한 트리거 스트림 디스크립터(Trigger_stream_descriptor)가 존재하는지를 판단한다(s4020). Trigger_stream_descriptor가 존재하는지 여부는, ES 디스크립터 루프 내 디스크립터들을 탐색하되, stream_type 값이 동기화된 데이터 스트리밍에 해당하는 0x06인지와 해당 디스크립터의 descriptor_tag 필드가 트리거 스트림 디스크립터에 대응되도록 설정한 값과 일치하는지를 이용하여 판단할 수 있다.
만약, PMT에서 Trigger_stream_descriptor가 식별되지 않아 존재하지 않는다고 판단한 경우에는 해당 가상 채널은 트리거를 전송하지 않으므로, 수신기(300)는 해당 가상 채널에 포함된 방송 서비스에 따라 적절한 동작을 수행한다(S4025).
그리고, Trigger_stream_descriptor가 존재하는 경우, 트리거 시그널링 데이터 수신부(332)는 PMT의 해당 ES 루프 에 포함된 Elementray_PID를 추출한다(S4030). 추출된 스트림 PID는 트리거 스트림을 포함하는 스트림의 PID값일 수 있다.
이후, 트리거 수신부(331)는 추출된 스트림 PID에 해당하는 MPEG-2 TS 패킷들을 수신하여 디캡슐레이션 즉, TS 헤더를 제거하고, 트리거 스트림을 포함하는 PES 스트림을 복원한다. 트리거 스트림을 포함하는 PES 패킷의 스트림 타입(stream_type)은 동기화된 데이터 스트림을 나타내는 0x06일 수 있다. 트리거 수신부(331)는 복원된 PES 스트림으로부터 PES패킷 헤더의 PTS, 트리거 스트림에 포함된 대상 TDO 식별자, 트리거 식별자 또는 트리거 액션 정보중 적어도 하나를 파싱한다(S4040).
이후, 서비스 매니저(350)는 트리거를 포함하는 PES 패킷 헤더의 PTS를 트리거 시간으로 하여, 트리거 시간에 대상 TDO에 대한 액션을 수행한다(S4050). 여기서, 대상 TDO는 파싱된 대상 TDO 식별자에 의해 지시된 NRT 서비스일 수 있다. 또한, 액션은 파싱된 트리거 액션 정보에 의해 지시된 준비, 실행, 연장, 종료 명령 중 어느 하나일 수 있다.
도 40은 본 발명의 일 실시예에 따라 스트림 타입을 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
수신기(300)는 물리적 전송 채널이 선택되고, 튜너에 의해 선택된 채널이 튜닝되면, 튜닝된 물리적 전송 채널로 수신되는 방송 신호로부터 복조부(310) 및 역다중화부(320)를 이용하여 VCT와 PMT를 획득한다. 방송 신호는 VCT와 PMT를 포함하며, 트리거 시그널링 데이터 수신부(332) 또는 PSI/PSIP 섹션 핸들러가 획득된 VCT 및 PMT를 파싱한다(S400).
그리고, 트리거 시그널링 데이터 수신부(332)는 VCT와 PMT로부터 해당 가상 채널로 트리거가 전송되고 있는지 확인한다. 이를 위하여 트리거 시그널링 데이터 수신부(332)는 해당 가상 채널에 대응하는 PMT의 ES 디스크립터 루프에 상술한 특정 스트림 타입인 0x96이 있는지 판단한다(S410).
만약, PMT에서 스트림 타입에 0x96이 식별되지 않아 존재하지 않는다고 판단한 경우에는 해당 가상 채널은 트리거를 전송하지 않으므로, 수신기(300)는 해당 가상 채널에 포함된 방송 서비스에 따라 적절한 동작을 수행한다(S415).
그리고, 스트림 타입이 0x96인 경우, 트리거 시그널링 데이터 수신부(332)는 PMT의 해당 ES 루프 에 포함된 Elementray_PID를 추출한다(S420). 추출된 스트림 PID는 트리거 스트림을 포함하는 스트림의 PID값일 수 있다.
이후, 트리거 수신부(331)는 추출된 스트림 PID에 해당하는 MPEG-2 TS 패킷들을 수신하여 디캡슐레이션 즉, TS 헤더를 제거하고, 트리거 스트림을 포함하는 PES 스트림을 복원한다. 트리거 수신부(331)는 복원된 PES 스트림으로부터 PES패킷 헤더의 PTS, 트리거 스트림에 포함된 대상 TDO 식별자, 트리거 식별자 또는 트리거 액션 정보중 적어도 하나를 파싱한다(S430).
이후, 서비스 매니저(350)는 트리거를 포함하는 PES 패킷 헤더의 PTS를 트리거 시간으로 하여, 트리거 시간에 대상 TDO에 대한 액션을 수행한다(S440). 여기서, 대상 TDO는 파싱된 대상 TDO 식별자에 의해 지시된 NRT 서비스일 수 있다. 또한, 액션은 파싱된 트리거 액션 정보에 의해 지시된 준비, 실행, 연장, 종료 명령 중 어느 하나일 수 있다.
도 41은 본 발명의 일 실시예에 따라 AIT를 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
트리거 시그널링 데이터 수신부(332)는 복조부(310) 및 역다중화부(320)를 이용하여 AIT를 수신한다(S500).
그리고, 트리거 시그널링 데이터 수신부(332)는 AIT로부터 트리거가 전송되고 있는지 확인한다. 이를 위하여 트리거 시그널링 데이터 수신부(332)는 AIT에 트리거 디스크립터가 존재하는 확인한다(S510).
만약, 트리거 디스크립터가 존재하지 않는다고 판단한 경우에는 해당 어플리케이션은 트리거를 포함하지 않으므로, 수신기(300)는 해당 어플리케이션 서비스에 따라 적절한 동작을 수행한다(S515).
그리고, 트리거 디스크립터가 존재하는 경우, 트리거 수신부(332)는 트리거 디스크립터로부터 트리거 데이터를 추출하고, 추출한 트리거 데이터를 파싱하여 서비스 매니저(350)로 전송한다(S530).
이후, 서비스 매니저(350)는 파싱된 트리거 데이터에 기초하여 트리거 시간에 대상 TDO에 대한 액션을 수행한다(S540). 여기서, 대상 TDO는 파싱된 대상 TDO 식별자에 의해 지시된 NRT 서비스일 수 있다. 또한, 액션은 파싱된 트리거 액션 정보에 의해 지시된 준비, 실행, 연장, 종료 명령 중 어느 하나일 수 있다.
도 42는 본 발명의 일 실시예에 따라 STT를 이용하여 트리거를 전송하는 경우의 수신기의 동작을 나타낸 흐름도이다.
트리거 시그널링 데이터 수신부(332)는 복조부(310) 및 역다중화부(320)를 이용하여 STT를 수신한다(S600).
그리고, 트리거 시그널링 데이터 수신부(332)는 STT로부터 트리거가 전송되고 있는지 확인한다. 이를 위하여 트리거 시그널링 데이터 수신부(332)는 STT에 트리거 디스크립터가 존재하는 확인한다(S610).
만약, 트리거 디스크립터가 존재하지 않는다고 판단한 경우에는 해당 STT는 트리거를 포함하지 않으므로, 수신기(300)는 방송 신호에 따라 적절한 동작을 수행한다(S615).
그리고, 트리거 디스크립터가 존재하는 경우, 트리거 수신부(332)는 트리거 디스크립터로부터 트리거 데이터를 추출하고, 추출한 트리거 데이터를 파싱하여 서비스 매니저(350)로 전송한다(S630).
이후, 서비스 매니저(350)는 파싱된 트리거 데이터에 기초하여 트리거 시간에 대상 TDO에 대한 액션을 수행한다(S540). 여기서, 대상 TDO는 파싱된 대상 TDO 식별자에 의해 지시된 NRT 서비스일 수 있다. 또한, 액션은 파싱된 트리거 액션 정보에 의해 지시된 준비, 실행, 연장, 종료 명령 중 어느 하나일 수 있다.
이하에서는 도 43과 도 44를 참고하여 본 발명의 한 실시예에 따른 트리거 데이터 전송 패턴을 설명한다. 특히, 활성화 트리거 데이터(Activation Triggering Data, ATD)의 전송 패턴을 설명한다.
일 실시예에서, 활성화에 해당하는 값으로 설정된 트리거 액션을 포함하는 트리거 데이터가 활성화 트리거 데이터일 수 있다. 활성화 트리거 데이터는 타겟 서비스 식별자에 해당하는 오브젝트의 활성화(실행)를 트리거한다.
도 43은 본 발명의 한 실시예에 따른 타이밍 다이어그램을 보여준다.
도 43에 도시된 바와 같이, 송신기(200)는 수신기(300)가 언제 채널을 변경할지 수신기(300)가 언제 Power On될지 그리고 수신기(300)가 해당 NRT 서비스가 존재하는 채널을 언제 선택할지를 알 수 없으므로, 송신기(200)는 지상파 방송을 통해 NRT 방식으로 전송되는 다운로드 컨텐트들을 주기적으로 반복하여 전송할 수 있다.
이와 같은 이유로, 송신기(200)는 활성화 트리거 데이터 또한 주기적으로 전송할 수 있다. 그러나, 매우 짧은 주기로 활성화 트리거 데이터가 전송되면 전송 대역의 낭비가 초래되고, 수신기(300)는 주기적으로 활성화 트리거 데이터를 체크하여야 하므로 오버헤드가 발생할 수 있다. 반면, 매우 긴 주기로 활성화 트리거 데이터가 전송되면 수신기(300)는 활성화 트리거 데이터에 해당하는 NRT 데이터를 수신하였음에도 불구하고 수신한 NRT 데이터를 활성화시키지 못할 수 있다. 따라서 적절한 활성화 트리거 데이터의 전송 타이밍이 요구된다.
도 43에서, 활성화 시간(T1)은 NRT(T1) 서비스의 활성화가 트리거되는 시간을 나타낸다. 유효 시간(Te)은 활성화 시간(T1) 이전에 마지막으로 NRT(T1)이 전송되기 시작한 시간을 나타낸다. 전송 주기 변경 시간(To)는 활성화 트리거 데이터가 전송되는 주기가 변경되는 시간을 나타낸다. 전송 주기 변경 시간(To)은 송신기(200)가 결정할 수 있는 시간 파라미터이다. 시간 윈도우(Tp1)는 유효 시간(Te) 이전을 나타낸다. 시간 윈도우(Tp2)는 유효 시간(Te)과 활성화 시간(T1) 사이를 나타낸다. 시간 윈도우(Tp3)는 유효 시간(Te)과 전송 주기 변경 시간(To) 사이를 나타낸다. 시간 윈도우(Tp4)는 전송 주기 변경 시간(To)과 활성화 시간(T1) 사이를 나타낸다.
활성화 시간(T1)에 NRT(T1) 서비스가 실행되기 위해서는 수신기(300)는 활성화 시간(T1) 이전에 NRT(T1) 서비스의 수신과 저장을 완료하고 NRT(T1) 서비스를 위한 활성화 트리거 데이터를 수신할 필요가 있다. 이를 위하여 수신기(300)는 유효 시간(Te) 이전에 NRT(T1) 서비스를 전송하는 채널을 튜닝하고 NRT(T1) 서비스의 수신 완료까지 해당 채널을 유지하면, 수신기(300)는 NRT(T1) 서비스를 활성화 시간(T1) 이전에 저장할 수 있다. 따라서 시간 윈도우(Tp2)에서 활성화 트리거 데이터가 전송된다하더라도 수신기(300)는 NRT(T1) 서비스를 수신할 수 없으므로 시간 윈도우(Tp2)에서 활성화 트리거 데이터의 전송은 의미가 없을 수 있다.
하지만 수신기(300)가 시간 윈도우(Tp1)에서 NRT(T1) 서비스를 전송하는 채널을 튜닝하고 NRT(T1) 서비스의 수신을 완료한 후 다른 채널로 채널 변경을 수행한 경우에, 수신기(300)가 시간 윈도우(Tp2)에서 NRT(T1) 서비스를 전송하는 채널로 채널 변경을 수행하면, 수신기(300)는 NRT(T1) 서비스를 가지고 있을 수 있다. 따라서, 송신기(200)는 시간 윈도우(Tp2)에서 활성화 트리거 데이터를 전송하는 것이 필요하다.
한편, 송신기(200)는 전송 주기 변경 시간(To)에 의해 시간 윈도우(Tp3)와 시간 윈도우(Tp4)를 구별하여 활성화 트리거 데이터를 전송할 수 있다. 전송 주기 변경 시간(To) 이전에서는 NRT(T1) 서비스가 실행될 때까지 적어도 시간 윈도우(Tp4)의 시간이 남아 있으므로, 송신기(200)는 긴 주기로 활성화 트리거 데이터를 전송한다. 이때, 송신기(200)는 n*Tp4를 주기로 하여 활성화 트리거 데이터를 전송할 수 있다.
반면에, 전송 주기 변경 시간(To)과 활성화 시간(T1) 사이에서는 NRT(T1) 서비스가 실행될 때까지 시간이 얼마 남지 않았으므로, 송신기(200)는 짧은 주기로 활성화 트리거 데이터를 전송할 수 있다. 이때, 송신기(200)는 짧은 주기 전송 횟수(M)만큼의 활성화 트리거 데이터를 전송할 수 있다. 이때의 짧은 주기(P(Tp4))는 [Tp4/M]가 될 수 있다. []는 가우스 기호를 나타낸다. 짧은 주기 전송 횟수(M)는 수신기(300)의 채널 변경 시간을 고려하여 설계될 수 있다. 따라서 수신기(300)가 활성화 시간(T1)보다 P(Tp4) 이전에 NRT(T1) 서비스를 제공하는 채널로 채널 변경을 수행하면, NRT(T1) 서비스가 정상적으로 제공될 수 있다.
T1 - P(Tp4)와 활성화 시간(T1) 사이에서 수신기(300)가 (T1) 서비스를 제공하는 채널로 진입하면, NRT(T1) 서비스가 정상적으로 제공될 수 없지만, 아주 짧은 시간에 불과하므로 확률적으로 발생할 가능성이 적다. 또한, 이 경우는 후술하는 유지 트리거 데이터에 의해 보완할 수 있다.
이상에서, 유효 시간(Te)가 전송 주기 변경 시간(To)보다 이전이었지만, 반드시 이에 한정될 필요는 없다. 즉, 전송 주기 변경 시간(To)가 유효 시간(Te)보다 이전일 수 있다.
도 44는 본 발명의 한 실시예에 따른 활성화 트리거 데이터 전송 방법을 보여주는 흐름도이다.
먼저, 트리거 전송부(220)는 타겟 오브젝트인 NRT(T1) 서비스의 활성화 시간(T1)을 설정하고(S5101), 전송 주기 변경 시간(To)을 설정하고(S5103), 짧은 주기 전송 횟수(M)를 설정한다(S5105).
현재 시스템 시간(t)이 전송 주기 변경 시간(To) 이전이면(S5107), 트리거 전송부(220)는 긴 주기로 NRT(T1) 서비스를 위한 활성화 트리거 데이터를 전송한다(S5109). 이때, 트리거 전송부(220)는 n*Tp4를 주기로 하여 활성화 트리거 데이터를 전송할 수 있다.
현재 시스템 시간(t)이 전송 주기 변경 시간(To) 이후이고 NRT(T1) 서비스의 활성화 시간(T1) 이전이면(S5111), 트리거 전송부(220)는 짧은 주기로 NRT(T1) 서비스를 위한 활성화 트리거 데이터를 전송한다(S5113).
현재 시스템 시간(t)이 NRT(T1) 서비스의 활성화 시간(T1) 이후이면(S5111), 트리거 전송부(220)는 NRT(T1) 서비스를 위한 활성화 트리거 데이터의 전송을 종료한다(S5115).
도 44에서, 현재 시스템 시간(t)은 전송 주기 변경 시간(To)이나 NRT(T1) 서비스의 활성화 시간(T1)과 비교된다. 따라서, 현재 시스템 시간(t), 전송 주기 변경 시간(To), NRT(T1) 서비스의 활성화 시간(T1)의 시간 기준은 동일할 필요가 있다. 예컨데, 현재 시스템 시간(t), 전송 주기 변경 시간(To), NRT(T1) 서비스의 활성화 시간(T1)은 모두 UTC 시간일 수 있다. NRT(T1) 서비스의 활성화 시간(T1)이 PTS로 주어진다면, PTS는 PCR을 reference로 사용하므로, 현재 시스템 시간(t)은 STC에 해당할 수 있다. 이러한 사항은 본 명세서에서 언급하는 시간 비교에 적용될 수 있다.
이하에서는 도 45 내지 도 47을 참고하여 본 발명의 또 다른 실시예에 따른 트리거 데이터 전송 패턴을 설명한다. 특히, 유지 트리거 데이터(maintenance Triggering Data, MTD)의 전송 패턴을 설명한다.
일 실시예에서, 유지에 해당하는 값으로 설정된 트리거 액션을 포함하는 트리거 데이터가 유지 트리거 데이터일 수 있다.
유지 트리거 데이터의 타겟 서비스 식별자에 해당하는 오브젝트가 수신기(300)에서 이미 활성화되었으면, 유지 트리거 정보는 이 오브젝트의 활성화의 유지를 트리거할 수 있다. 그리고, 유지 트리거 데이터의 타겟 서비스 식별자에 해당하는 오브젝트가 수신기(300)에서 아직 활성화되지 않았으면, 유지 트리거 정보는 이 오브젝트의 활성화를 트리거할 수 있다.
도 45는 본 발명의 또 다른 실시예에 따른 타이밍 다이어그램을 보여준다.
도 45에서 활성화 시간(Ta)는 TDO의 활성화 시간을 나타내고, 종료 시간(Tf)은 TDO의 종료 시간을 나타낸다. 추가 액션 시간(Taction)은 활성화 시간(Ta) 이후에 그리고 종료 시간(Tf) 이전에 TDO를 위한 다른 추가 액션이 트리거(활성화)되는 시간을 나타낸다. 시간 윈도우(Tplife)는 활성화 시간(Ta)과 종료 시간(Tf) 사이를 나타내며, 특히 TDO의 라이프타임을 나타낸다. 시간 윈도우(Tp1)은 활성화 시간(Ta)과 추가 액션 시간(Taction) 사이를 나타낸다. 시간 윈도우(Tp2)은 추가 액션 시간(Taction)과 종료 시간(Tf) 사이를 나타낸다.
수신기(300)가 A 채널에서 B 채널로 튜닝 채널을 변경한 후 다시 A 채널로 돌아온 경우에, 수신기(300)는 이전에 실행하던 TDO를 재실행해 줄 필요가 발생한다. 또는 A 채널에 해당하는 NRT 컨텐트(TDO)가 수신기(300)에 미리 저장되어 있고 수신기(300)가 이 TDO의 활성화 시간(Ta) 이후에 A 채널로 들어오는 경우에 수신기(300)는 TDO를 실행해 줄 필요가 발생한다. 이러한 경우를 위하여 송신기(200)는 본 발명의 실시예에 따른 유지 트리거 데이터를 전송할 수 있다.
수신기(300)가 해당 NRT 컨텐트를 이전에 다운받아 저장했다면, 수신기(300)는 다음과 같은 경우에 MTD를 필요로 할 수 있다. 즉, 수신기(300)가 A 채널에서 B 채널로 튜닝 채널을 변경한 이후에 시간 윈도우(Tplife) 안에 다시 A 채널로 돌아온 경우에, 수신기(300)는 MTD를 필요로 할 수 있다. 또한, 수신기(300)가 A 채널에서 파워 오프된 후 파워 온되어 시간 윈도우(Tplife) 안에 다시 A 채널로 돌아온 경우에, 수신기(300)는 MTD를 필요로 할 수 있다. 수신기(300)가 시간 윈도우(Tplife) 내에 A 채널에서 B 채널로 튜닝 채널을 변경한 후에 시간 윈도우(Tplife) 안에 다시 A 채널로 돌아온 경우에, 수신기(300)는 MTD를 필요로 할 수 있다. 수신기(300)가 시간 윈도우(Tplife) 안에 A 채널에서 파워 오프된 후 파워 온되어 시간 윈도우(Tplife) 안에 다시 A 채널로 돌아온 경우에, 수신기(300)는 MTD를 필요로 할 수 있다.
MTD가 필요한 경우엔 송신기(200)는 시간 윈도우(Tplife) 내에서 MTD를 계속해서 전송해서 MTD와 관련된 TDO가 재실행될 수 있도록 한다. MTD의 전송 주기(Pmtd)는 수신기(300)의 전원 온/오프에 걸리는 시간과 채널 변경이 일어나는 시간을 고려해서 설정될 수 있다.
한편, 도 45는 시간 윈도우(Tplife) 내에서 TDO action이 Taction 시간에 한 차례 발생하는 경우를 예로 보여 주고 있다. 이 경우 시간 윈도우(Tp1) 내에서 송신기(200)는 ATD와 동일한 형태의 MTD를 구성하여 전송할 수 있다. 또한, 송신기(200)는 ATD에 특정 추가 행동을 덧붙인 형태의 MTD를 구성하여 전송할 수도 있다. TDO action이 발생한 이후인 시간 윈도우(Tp2)에서 송신기(200)는 TDO action에 해당하는 트리거 데이터와 동일한 형태의 MTD를 구성하여 전송할 수도 있고, TDO action에 해당하는 트리거 데이터에 특정 추가 행동을 덧붙인 형태의 MTD를 구성하여 전송할 수도 있다.
도 46은 본 발명의 한 실시예에 따른 유지 트리거 데이터 전송 방법을 보여주는 흐름도이다.
트리거 전송부(220)는 타겟 오브젝트인 TDO를 위한 활성화 시간(Ta)를 설정한다(S5201).
트리거 전송부(220)는 타겟 오브젝트를 위한 MTD의 전송 주기(Pmtd)를 결정한다(S5203). MTD의 전송 주기(Pmtd)는 미리 결정된 값으로 설정될 수 있다. 또한, MTD의 전송 주기(Pmtd)는 수신기(300)의 채널 변경 시간 또는 수신기(300)의 전원 온/오프에 걸리는 시간을 고려하여 설정될 수 있다.
현재 시스템 시간(t)이 타겟 오브젝트의 활성화 시간(Ta) 이전이면(S5205), 트리거 전송부(220)는 타겟 오브젝트를 위한 MTD를 전송하지 않는다(S5207).
한편, 현재 시스템 시간(t)이 타겟 오브젝트의 활성화 시간(Ta) 이후이고(S5205) 타겟 오브젝트의 종료 시간(Tf) 이전이면(S5209), 트리거 전송부(220)는 트리거 데이터의 변경을 확인한다(S5211).
트리거 데이터가 변경된 경우에, 트리거 전송부(220)는 변경된 트리거 데이터와 추가 액션을 포함하는 유지 트리거 데이터를 전송한다(S5213).
트리거 데이터가 변경되지 않은 경우에, 트리거 전송부(220)는 변경 전 트리거 데이터와 추가 액션을 포함하는 유지 트리거 데이터를 전송한다(S5215).
한편, 현재 시스템 시간(t)이 타겟 오브젝트의 종료 시간(Tf) 이후이면(S5209), 트리거 전송부(220)는 유지 트리거 데이터의 전송을 종료한다(S5217).
도 47은 본 발명의 한 실시예에 따른 유지 트리거 수신 방법을 설명한다.
먼저, 수신기(300)의 트리거 수신부(331)는 유지 트리거 데이터를 수신한다(S5301). 유지 트리거 데이터의 수신은 앞에서 설명한 다양한 실시예에 따라 수행될 수 있다.
유지 트리거 데이터의 타겟 서비스 식별자에 해당하는 오브젝트가 수신기(300)에서 이미 활성화되었으면(S5303), 수신기(300)의 서비스 매니저(350)는 이 오브젝트의 활성화를 유지한다(S5305)
유지 트리거 데이터의 타겟 서비스 식별자에 해당하는 오브젝트가 수신기(300)에서 아직 활성화되지 않았으면(S5303), 수신기(300)의 서비스 매니저(350)는 상기 오브젝트를 활성화시킨다(S5307).
이하에서는 도 48 내지 도 50를 참고하여 본 발명의 한 실시예에 따른 트리거 데이터 수신 타이밍을 설명한다. 특히, 준비 트리거 데이터(preparation Triggering Data, PTD)의 수신 타이밍을 설명한다.
일 실시예에서, 준비에 해당하는 값으로 설정된 트리거 액션을 포함하는 트리거 데이터가 준비 트리거 데이터일 수 있다. 준비 트리거 데이터의 파싱을 통해 준비를 위한 타겟 서비스 식별자와 준비 트리거 시간이 획득될 수 있다. 준비 트리거 데이터는 타겟 서비스 식별자에 해당하는 오브젝트의 준비를 트리거한다.
송신기(200)는 활성화 시간 전에 사전 작업이 필요한 TDO를 위해 다음과 같은 사전 작업에 대한 Trigger인 준비 트리거 데이터를 제공할 수 있다.
인터넷 연결을 체크하여 TDO와 연계된 다운로드 가능한 컨텐트를 미리 다운 받는 작업이 활성화 시간 전에 요구되는 경우에, 준비 트리거 데이터가 전송될 수 있다.
또한, 사용자 인터페이스를 생성하는데 시간이 오래 걸려서 TDO를 백그라운드(background)에서 활성화시킬 것이 요구되는 경우에, 준비 트리거 데이터가 전송될 수 있다. 이는 사용자 인터페이스를 생성하는데 사용되는 사진 데이터와 같은 데이터가 많아서 디코딩이 미리 요구되는 경우나, TDO와 연관된 메타 데이터를 통해 사용자 인터페이스를 생성할 때 시간이 오래 걸리는 경우에 해당할 수 있다. 또 웹 기반(Web-based) TDO의 다운로드가 미리 요구되는 경우에 해당할 수 있다.
활성화될 TDO가 네트워크를 통한 서버와 연동이 필요한 TDO여서 미리 서버와의 접속 가능성을 체크하거나 서버와 연결을 미리 수행하기 위하여, 준비 트리거 데이터가 전송될 수 있다.
이상의 사전 작업은 서로 조합된 형태를 가질 수도 있다.
도 48은 본 발명의 한 실시예에 따른 타이밍 다이어그램을 보여준다.
도 48에서, 준비 트리거 시간(Tp)는 PTD에 의해서 TDO의 준비가 트리거되는 시간을 나타낸다. 활성화 시간(Ta)는 TDO가 활성화되는 시간을 나타내고, 종료 시간(Tf)는 TDO가 종료되는 시간을 나타낸다.
시간 윈도우(Tpa)는 준비 트리거 시간(Tp)과 활성화 시간(Ta)의 사이를 나타내고, 시간 윈도우(Tplife)는 활성화 시간(Ta)과 종료 시간(Tf) 사이를 나타낸다.
시간 윈도우(Tpa)는 사전 작업에 따라 해당 사전 작업에 따라서 달라질 수 있다.
수신기(300)가 컨텐트 다운로드와 관련된 준비 트리거 데이터를 수신하는 경우에, 가능한 한 빨리 컨텐트를 다운로드하는 것이 좋을 수 있다. 이를 위하여 송신기(200)는 0으로 설정된 준비 트리거 시간을 가지는 준비 트리거 데이터를 전송할 수 있다. 즉, 수신기(300)가 0으로 설정된 준비 트리거 시간을 가지는 준비 트리거 데이터를 수신하면, 수신기(300)는 즉시 컨텐트 다운로드를 개시할 수 있다.
수신기(300)는 활성화를 위하여 다운로드 컨텐트를 필요로 하는 TDO를 위한 PTD를 수신하지 못하였거나 활성화 시간(Ta) 직전에 TDO를 위한 준비를 트리거 할 수 있다. TDO의 활성화를 위하여 다운로드 컨텐트가 필요하지만 다운로드되지 않은 경우에, 수신기(300)는 TDO를 활성화 시간(Ta)에 활성화시키지 않을 수도 있고, 활성화를 한 후에 컨텐트의 다운로드를 수행할 수 있다. TDO 액션이 이러한 정보를 담는다면, 수신기300)는 TDO 액션에 기초하여 TDO의 활성화를 결정할 수도 있다.
송신기200)는 UI 생성이 필요하거나 네트워크 체크가 필요한 TDO를 위한 준비 트리거 시간Tp)을 TDO의 타입에 따라 설정할 수 있다. 송신기200)는 시간 윈도우Tpa)에서도 Tp로 설정된 트리거 시간을 갖는 PTD를 계속해서 전송할 수 있다.
수신기300)는 준비 트리거 시간Tp)과 현재 시스템 시간을 비교하여 현재 시스템 시간이 준비 트리거 시간Tp) 이후이면, 활성화 시간Ta) 이전에 가능한한 빨리 TDO의 준비를 완료할 수 있도록 수신기300)는 PTD를 받자 마자 TDO의 준비를 개시한다.
도 49는 본 발명의 한 실시예에 따른 준비 트리거 수신 방법을 보여주는 흐름도이다.
특히 도 49는 다운로딩 준비 트리거 데이터의 처리 방법을 보여준다.
먼저, 수신기(300)의 트리거 수신부(331)는 준비 트리거 데이터를 수신하고(S5401), 수신한 준비 트리거 데이터를 파싱하여 저장한다(S5403). 준비 트리거 데이터의 수신은 앞에서 설명한 트리거 데이트를 수신하는 다양한 실시예에 따라 수행될 수 있다.
수신한 준비 트리거 데이터가 다운로딩 준비 트리거 데이터가 아니면(S5405), 서비스 메니저(350)는 수신한 준비 트리거 데이터를 다른 종류의 준비 트리거 데이터로서 처리한다(S5407).
수신한 준비 트리거 데이터가 다운로딩 준비 트리거 데이터이면(S5405), 서비스 메니저(350)는 인터넷 연결을 확인한다(S5409).
인터넷 연결이 정상적이 아니면, 서비스 메니저(350)는 수신한 PTD를 무시한다(S5411). 계속해서 수신되는 다운로딩 PTD를 처리하기 위한 부하를 줄이기 위하여 서비스 메니저(350)는 수신한 PTD를 저장한 채 무시하면서 지우지는 않을 수 있다. 다운로딩 PTD와 관련된 TDO가 종료되면, 서비스 메니저(350)는 수신한 PTD를 삭제할 수 있다.
인터넷 연결이 정상적이면, 서비스 메니저(350)는 수신한 준비 트리거 데이터의 트리거 시간에 다운로드 컨텐트의 다운로드를 개시한다(S5413). 이때, 서비스 메니저(350)는 수신한 준비 트리거 데이터의 타겟 서비스 식별자에 해당하는 TDO를 백그라운드에서 활성화시켜 활성화된 TDO가 다운로드 컨텐트를 다운로드하도록 할 수 있다. 또한, 서비스 메니저(350)는 타겟 서비스 식별자와 다운로딩 URL을 다운로드 메니저에 제공하여 다운로드 메니저가 다운로드 컨텐트를 다운로드하도록 할 수 있다.
활성화된 TDO 또는 다운로드 메니저는 다운로드 컨텐트를 저장한다(S5415). 한편, 다운로드 메니저가 컨텐트를 다운로드한 경우에, 다운로드 메니저는 타겟 서비스 식별자와 관련하여 다운로드 컨텐트를 저장한다.
도 50은 본 발명의 또 다른 실시예에 따른 준비 트리거 수신 방법을 보여주는 흐름도이다.
특히, 도 50은 TDO의 준비를 위하여 TDO의 백그라운드 활성화를 요구하는 PTD의 처리 방법을 보여준다.
먼저, 수신기(300)의 트리거 수신부(331)는 준비 트리거 데이터를 수신하고(S5501), 수신한 준비 트리거 데이터를 파싱하여 저장한다(S5503). 준비 트리거 데이터의 수신은 앞에서 설명한 트리거 데이트를 수신하는 다양한 실시예에 따라 수행될 수 있다. 수신한 준비 트리거 데이터의 파싱을 통해, 타겟 서비스 식별자와 준비 트리거 시간이 획득될 수 있다.
현재 시스템 시간(t)이 준비 트리거 시간(Tp) 이후이면(S5505), 서비스 메니저(350)는 준비 트리거 데이터의 타겟 서비스 식별자에 해당하는 TDO를 백그라운드에서 활성화한다(S5507). 즉, PTD의 수신 시간이 준비 트리거 시간(Tp) 이전이면, 준비 트리거 시간(Tp)에 도달할 때 서비스 메니저(350)는 TDO를 백그라운드에서 활성화한다. 한편, PTD의 수신 시간이 준비 트리거 시간(Tp) 이후이면, 서비스 메니저(350)는 즉시 TDO를 백그라운드에서 활성화한다. 이때, 수신기(300)의 튜닝 채널이 변경되더라도, 서비스 메니저(350)는 TDO를 종료하지 않고, 백그라운드 상태를 유지한다.
현재 시스템 시간(t)이 TDO의 활성화 시간(Ta) 이후이면(S5509), 서비스 메니저(350)는 TDO의 상태를 포그라운드(foreground)로 변경한다(S5511). 특히, TDO의 활성화 시간(Ta)과 TDO의 종료 시간(Tf) 사이에서 수신기(300)가 TDO의 서비스 채널로 복귀하면, 서비스 메니저(350)는 TDO의 상태를 포그라운드(foreground)로 변경한다
현재 시스템 시간(t)이 TDO의 종료 시간(Tf) 이후이면(S5513), 서비스 메니저(350)는 TDO를 종료한다(S5515). 특히, 백그라운드 상태로 활성화되고 포그라운드 상태로 변경되지 못한 TDO가 있다면, 서비스 메니저(350)는 그러한 TDO를 종료한다. 이때, 서비스 메니저(350)는 해당 TDO의 종료시점을 알고 있을 필요가 있다. 이를 위하여, ATD는 해당 TDO의 종료 시점을 포함할 수 있다.
이처럼 트리거는 그 성격에 따라 크게 준비 트리거, 활성화 트리거, 및 유지 트리거로 분류될 수 있다.
즉, 준비 트리거는 활성화 트리거(Activation Trigger)에 앞서서 수신기(300)에 전달되어 활성화 트리거(Activation trigger)를 통해 수행되는 기능에 대한 사전 준비를 수신기(300)가 하게 할 수 있는 사전 트리거(pre-trigger)를 나타낼 수 있다. 준비 트리거를 통해 수신기(300)는 정확한 시점에 자연스럽게 트리거 액션을 수행할 수 있다.
활성화 트리거(Activation Trigger)는 특정 시점에 수신기가 TDO의 실행 또는 종료와 같은 TDO의 상태 변경과 관련된 특정한 기능을 수행하도록 명하는 트리거이다.
유지 트리거(Maintenance Trigger)는 수신기(300)가 활성화 트리거(Activation trigger)에서 지정된 트리거 수행 시점을 놓쳤을 경우에 수신기(300)가 이 트리거를 처리하는 방안에 대한 지시 혹은 가이드를 제공해 줄 수 있는 트리거이다. 넓은 의미에서 유지 트리거는 트리거의 라이프 사이클 관리에 이용되는 트리거를 통칭하는 의미를 가질 수 있다.
이러한 3 종류 트리거의 조합을 통하여 수신기(300)는 활성화 트리거(Activation trigger)가 지시하는 트리거링 시점 이전에 활성화 트리거(Activation trigger)가 지시하는 Action에 필요한 준비를 완료하여 정확한 시점에 자연스러운 action 수행을 할 수 있다. 또한 만일 수신기(300)가 트리거링 시점 직전이나 이후에 해당 채널로 진입하여 트리거 수행을 하지 못하였을 경우에는 Maintenance trigger를 통하여 이에 대한 대처를 할 수 있다. 따라서 이와 같이 구성한 트리거는 다양한 실제 시청 환경에서 최적의 트리거 수행을 이룰 수 있는 방안을 제공할 수 있다.
이런 3가지 트리거의 식별 방법과 3가지 트리거 간의 상호 참조 방법에 대하여는 후술한다.
도 51은 본 발명의 또 다른 실시예에 따라 구성한 트리거의 비트스트림 신택스를 도시한 것이다.
도 51에 도시된 신택스를 따르는 트리거는 도 25에 도시된 신택스를 따르는 트리거에 비하여 트리거 타입 필드(trigge_type)와 참조 타겟 트리거 식별자 필드(target_trigger_id_ref)를 더 포함한다.
트리거 타입 필드(trigge_type)는 트리거의 종류를 나타낸다. 예컨데, 트리거 타입 필드의 값이 0x00인 트리거는 "Reserved for future use"를 나타낼 수 있다. 트리거 타입 필드의 값이 0x01, 0x02, 0x03인 트리거는 각각 준비 트리거, 활성화 트리거, 유지 트리거를 나타낼 수 있다.
준비 트리거, 활성화 트리거, 유지 트리거의 구별을 위하여 트리거 타입 필드를 이용하는 것 이외의 방안도 이용될 수 있다.
예컨데, 일 실시예에서, 트리거 데이터는 트리거 타입 필드를 가지지 않고, trigger_action 필드를 통해 준비 트리거, 활성화 트리거, 유지 트리거는 구별될 수 있다. 즉, trigger_action 필드가 준비 트리거에 해당하는 값을 가지면, 수신기(300)는 수신한 트리거를 준비 트리거로 식별할 수 있다. 또, trigger_action 필드가 활성화 트리거에 해당하는 값을 가지면, 수신기(300)는 수신한 트리거를 활성화 트리거로 식별할 수 있다. trigger_action 필드가 유지 트리거에 해당하는 값을 가지면, 수신기(300)는 수신한 트리거를 유지 트리거로 식별할 수 있다.
또 다른 실시예에서, 트리거 데이터는 트리거 타입 필드를 가지지 않고, 유지 트리거에 해당하는 trigger_action 필드 값과 활성화 트리거에 해당하는 trigger_action 필드 값이 같을 수 있다. 대신에, 활성화 트리거가 타겟 TDO의 활성화 여부에 따라 활성화 트리거로 식별될 수도 있고, 유지 트리거로 식별될 수 있다. 예컨데, 수신된 활성화 트리거의 타겟 TDO가 아직 활성화되어 있지 않다면, 수신기(300)는 수신된 활성화 트리거를 활성화 트리거로 식별하고 수신된 활성화 트리거에 의해 지정된 트리거 시간에 타겟 TDO를 활성화할 수 있다. 반면, 수신된 활성화 트리거의 타겟 TDO가 이미 활성화되어 있다면, 수신기(300)는 수신된 활성화 트리거를 유지 트리거로 식별하고 타겟 TDO의 활성화를 유지할 수 있다.
또 다른 실시예에서, 트리거 데이터는 트리거 타입 필드를 가지지 않고, 유지 트리거에 해당하는 trigger_action 필드 값과 활성화 트리거에 해당하는 trigger_action 필드 값이 같을 수 있다. 대신에, 활성화 트리거가 트리거 타임의 경과 여부에 따라 활성화 트리거로 식별될 수도 있고, 유지 트리거로 식별될 수 있다. 예컨데, 수신된 활성화 트리거의 트리거 타임이 아직 도달하지 않았다면, 수신기(300)는 수신된 활성화 트리거를 활성화 트리거로 식별하고 수신된 활성화 트리거에 의해 지정된 트리거 시간에 타겟 TDO를 활성화할 수 있다. 반면, 수신된 활성화 트리거의 트리거 시간이 이미 도달하였다면, 수신기(300)는 수신된 활성화 트리거를 유지 트리거로 식별할 수 있다. 이때, 트리거의 타겟 TDO가 아직 활성화되어 있지 않다면, 수신기(300)는 즉시 타겟 TDO를 활성화할 수 있다. 수신된 활성화 트리거의 타겟 TDO가 이미 활성화되어 있다면, 수신기(300)는 타겟 TDO의 활성화를 유지할 수 있다.
참조 타겟 트리거 식별자 필드(target_trigger_id_ref)를 포함하는 트리거가 준비 트리거나 유지 트리거인 경우, 참조 타겟 트리거 식별자 필드는 준비 트리거나 유지 트리거와 연관된 활성화 트리거의 트리거 식별자(trigger_id)를 나타낼 수 있다. 참조 타겟 트리거 식별자 필드(target_trigger_id_ref)를 포함하는 트리거가 활성화 트리거인 경우, 참조 타겟 트리거 식별자 필드는 준비 트리거나 유지 트리거의 트리거 식별자(trigger_id)를 나타낼 수 있다. 이를 통해 수신기(300)는 준비 트리거나 유지 트리거를 처리할 때 활성화 트리거를 참조할 수 있다. 또한 수신기(300)는 활성화 트리거를 처리할 때 준비 트리거나 유지 트리거를 참조할 수 있다. 이를 통해, 실제 트리거 수행에 필요하거나 이용되는 메타데이터는 모두 활성 트리거에 포함될 필요가 없고, 준비 트리거를 통해 분산 배치될 수 있다. 이를 통해 활성화 트리거를 위한 스트림은 가능한한 compact하게 유지될 수 있다.
이처럼, 한 실시예에서, 연계된 3 종류의 트리거가 서로 다른 트리거 id를 가지면, 수신기(300)는 참조 타겟 트리거 식별자 필드를 통해 한 트리거와 연계된 또 다른 트리거를 인식할 수 있다.
한편, 또 다른 실시예에서, 연계된 3 종류의 트리거가 모두 동일한 트리거 id를 가지면, 수신기(300)는 동일한 값을 가진 트리거 id를 통해 한 트리거와 연계된 또 다른 트리거를 인식할 수 있다. 예컨데, 수신기(300)는 트리거 타입 필드를 통해 수신한 트리거의 타입을 식별할 수 있으므로, 활성화 트리거와 연관된 준비 트리거를 각 트리거의 트리거 id를 통해 인식할 수 있다.
다음은 본 발명의 실시예에 따른 준비 트리거에서 트리거 액션 필드(trigger action)의 의미를 설명한다.
트리거 액션 필드의 값이 0x00인 준비 트리거는 "reserved for future use"를 나타낼 수 있다.
트리거 액션 필드의 값이 0x01인 준비 트리거는 수신기(300)에게 활성화 트리거를 위한 컨텐트 아이템을 미리 준비할 것을 지시할 수 있다. 이때 준비는 다운로드를 나타낼 수 있다. 수신기(300)는 준비 트리거에 의해 지정되는 컨텐트 아이템을 미리 다운로드할 수 있다. 이 컨텐트 아이템은 방송망을 통해 획득될 수도 있고 IP망을 통해 수신될 수도 있다. 이 경우 미리 다운로드할 컨텐트는 준비 트리거의 서비스 식별자 필드와 컨텐트 링키지 필드에 의해 지정될 수 있다. 또한, 미리 다운로드할 컨텐트들의 리스트는 SMT와 NRT-IT에 의해 지정될 수도 있고, 트리거 내의 디스크립터(descriptor)에 의해 지정될 수도 있다. 또한, 미리 다운로드할 컨텐트의 위치 정보는 SMT와 NRT-IT 및 FDT에 의해 지정될 수도 있고, 트리거 내의 디스크립터(descriptor)에 의해 지정될 수도 있다. 구체적인 방법은 후술한다.
트리거 액션 필드의 값이 0x02인 준비 트리거는 수신기(300)에게 활성화 트리거를 위한 컨텐트 아이템을 미리 로딩할 것을 지시할 수 있다. 이를 통해, 수신기(300)는 활성화 트리거가 지시하는 트리거 액션의 수행 시점이 임박함을 인지하고 미리 필요한 컨텐트 아이템을 로딩할 수 있다. 이 경우 미리 로딩할 컨텐트는 준비 트리거의 서비스 식별자 필드와 컨텐트 링키지 필드에 의해 지정될 수 있다. 또한, 미리 로딩할 컨텐트들의 리스트는 SMT와 NRT-IT에 의해 지정될 수도 있고, 트리거 내의 디스크립터(descriptor)에 의해 지정될 수도 있다. 또한, 미리 로딩할 컨텐트의 정보는 SMT와 NRT-IT 및 FDT에 의해 지정될 수도 있고, 트리거 내의 디스크립터(descriptor)에 의해 지정될 수도 있다. 구체적인 방법은 후술한다.
트리거 액션 필드의 값이 0x03인 준비 트리거는 수신기(300)에게 서버와의 연결을 미리 설정할 것을 지시할 수 있다. 수신기(300)는 준비 트리거에 의해 지정되는 서버와의 연결을 미리 설정할 수 있다. 연결할 서버의 주소는 트리거 내의 인터넷 위치 디스크립터(internet location descriptor)를 통해 지정될 수 있다.
다음은 본 발명의 실시예에 따른 활성화 트리거에서 트리거 액션 필드(trigger action)의 의미를 설명한다.
트리거 액션 필드의 값이 0x00인 활성화 트리거는 "reserved for future use"를 나타낼 수 있다.
트리거 액션 필드의 값이 0x01인 활성화 트리거는 수신기(300)에게 활성화 트리거의 타겟 TDO를 실행(Execute)할 것을 지시할 수 있다. 일 실시예에서, 수신기(300)는 트리거 액션 필드의 값이 0x00인 활성화 트리거를 수신하면, 바로 타겟 TDO를 실행할 수도 있다. 또 다른 실시예에서, 수신기(300)는 트리거 액션 필드의 값이 0x00인 활성화 트리거를 수신하면, 타겟 TDO를 실행할 수 있음을 사용자에게 표시하고, 사용자로부터 타겟 TDO 실행 명령을 수신하면, 타겟 TDO를 실행할 수 있다.
트리거 액션 필드의 값이 0x02인 활성화 트리거는 수신기(300)에게 활성화 트리거의 타겟 TDO를 종료(Terminate)할 것을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x02인 활성화 트리거를 수신하면, 수신기의 구현에 따라 타겟 TDO를 종료하면서 리소스를 반환할 수도 있고 리소스를 반환하지 않을 수도 있다. 리소스가 반환되지 않는 경우, 짧은 기간 내에 재실행되면 실행 속도가 향상될 수 있다.
트리거 액션 필드의 값이 0x03인 활성화 트리거는 수신기(300)에게 활성화 트리거의 타겟 TDO를 실행할 수 있음을 사용자에게 알릴 것을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x03인 활성화 트리거를 수신하면, 이와 같은 안내를 한번만 수행할 수도 있고, 5분과 같은 주기를 가지고서 주기적으로 안내할 수도 있다.
트리거 액션 필드의 값이 0x04인 활성화 트리거는 수신기(300)에게 활성화 트리거의 타겟 TDO를 중단(Suspend)할 것을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x04인 활성화 트리거를 수신하면, 타겟 TDO의 동작을 멈추고 타겟 TDO를 대기 상태로 둘 수 있다. 또한, 수신기(300)는 타겟 TDO의 UI를 모두 숨길 수 있다. 중단(Suspend)은 종료(terminate)와는 다르며, 별도의 트리거나 사용자의 명령에 의해 중단된 TDO는 다시 실행되거나 종료될 수 있다.
트리거 액션 필드의 값이 0x05인 활성화 트리거는 수신기(300)에게 활성화 트리거에 의해 지정되는 중단된 타겟 TDO를 깨울 것(wake up)을 지시할 수 있다. 중단된 타겟 TDO를 깨울 것(wake up)을 지시하는 트리거는 타겟 TDO를 실행(Execute)할 것을 지시하는 트리거와 동일할 수 있다.
트리거 액션 필드의 값이 0x06인 활성화 트리거는 수신기(300)에게 활성화 트리거의 타겟 TDO를 숨길 것(hide)을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x06인 활성화 트리거를 수신하면, 타겟 TDO의 동작을 유지한 채 화면으로부터 숨긴다.
트리거 액션 필드의 값이 0x07인 활성화 트리거는 수신기(300)에게 활성화 트리거의 타겟 TDO를 보일 것(show)을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x07인 활성화 트리거를 수신하면, 타겟 TDO의 동작을 유지한 채 화면상에 보이도록 한다.
활성화 정보 획득과 관련한 일 실시예에서, 수신기(300)는 준비 트리거에 의해 지정된 액션을 수행할 때 준비 트리거에 의해 지정된 타겟 TDO의 활성화(실행, 중단, 종료, 타겟 TDO를 실행할 수 있음을 사용자에게 알림, 웨이크업, 타겟 TDO를 표시할 것 등)를 위한 필요한 정보를 수신한 NRT-IT로부터 얻고 타겟 TDO를 저장하면서 이 타겟 TDO와 함께 활성화 정보를 로컬 메모리에 저장할 수 있다. 수신기(300)가 준비 트리거에 의해 지정된 액션을 수행할 때 이외에도 수신기(300)는 수신한 NRT-IT로부터 타겟 TDO의 활성화를 위한 정보를 얻고, 타겟 TDO와 함께 활성화 정보를 로컬 메모리에 저장할 수 있다. 활성화 트리거를 수신한 수신기(300)는 활성화 트리거에 의해 지정된 타겟 TDO를 위한 활성화 정보를 로컬 메모리로부터 얻어 이 활성화 정보를 참조하여 활성화 트리거에 의해 지정된 타겟 TDO를 활성화할 수 있다.
활성화 정보 획득과 관련한 또 다른 실시예에서, 활성화 트리거를 수신한 수신기(300)는 타겟 TDO의 활성화를 위한 정보를 수신한 NRT-IT로부터 얻고, 이 활성화 정보를 참조하여 활성화 트리거에 의해 지정된 타겟 TDO를 활성화할 수 있다.
다음은 본 발명의 실시예에 따른 유지 트리거에서 트리거 액션 필드(trigger action)의 의미를 설명한다.
트리거 액션 필드의 값이 0x00인 유지 트리거는 "reserved for future use"를 나타낼 수 있다.
트리거 액션 필드의 값이 0x01인 유지 트리거는 수신기(300)에게 유지 트리거의 타겟 TDO를 즉시 실행할 것을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x01인 유지 트리거를 수신하면, 타겟 TDO가 실행되지 않은 경우에 타겟 TDO를 즉시 실행하고, 타겟 TDO가 이미 실행된 경우에 타겟 TDO의 실행을 유지할 수 있다. 수신기(300)는 타겟 TDO를 실행할 수 있음을 사용자에게 즉시 표시하고, 사용자로부터 타겟 TDO 실행 명령의 수신을 추가 조건으로 타겟 TDO를 실행할 수 있다. TDO가 특정 시간 윈도우 내에서 지속적으로 이용될 수 있을 경우 이 Action으로 해당 TDO는 바로 실행되고 이용될 수 있다.
트리거 액션 필드의 값이 0x02인 유지 트리거는 수신기(300)에게 유지 트리거의 타겟 TDO의 실행을 준비할 것(Being ready to launch)을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x02인 유지 트리거를 수신하면, 타겟 TDO의 준비가 아직 수행되지 않은 경우에 타겟 TDO의 준비를 즉시 수행하고, 타겟 TDO가 이미 수행된 경우에 타겟 TDO의 준비를 유지할 수 있다.
트리거 액션 필드의 값이 0x03인 유지 트리거는 수신기(300)에게 유지 트리거의 타겟 TDO를 실행할 수 있음을 사용자에게 알릴 것(notifying TDO availability)을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x03인 유지 트리거를 수신하면, 타겟 TDO를 실행할 수 있음을 사용자에게 아직 알리지 않은 경우에 타겟 TDO를 실행할 수 있음을 즉시 알리고, 타겟 TDO를 실행할 수 있음을 사용자에게 이미 알린 경우에 타겟 TDO를 실행할 수 있음의 알림을 유지한다. 수신기(300)는 이와 같은 안내를 한번만 수행할 수도 있고, 5분과 같은 주기를 가지고서 주기적으로 안내할 수도 있다.
트리거 액션 필드의 값이 0x04인 유지 트리거는 수신기(300)에게 유지 트리거의 타겟 TDO와 관련된 모든 자원을 반환할 것(Unloading all the related resources)을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x04인 유지 트리거를 수신하면, 유지 트리거의 타겟 TDO와 관련된 모든 자원을 아직 반환하지 않은 경우에 해당 자원의 반환을 즉시 수행하고, 해당 자원의 반환이 이미 수행된 경우에 해당 자원의 반환을 유지한다. 이를 통해, 지정된 TDO가 당분간 사용할 예정이 없을 경우 등에 이 트리거는 이 지정된 TDO를 위해 수신기가 사용중인 리소스를 모두 반환하게 하여 추후에 이용할 다른 TDO 등의 실행에 지장이 없도록 한다. 만일 해당 TDO가 실행중이라면 수신기(300)는 타겟 TDO를 종료 시키고 리소스를 반환할 수 있다.
트리거 액션 필드의 값이 0x05인 유지 트리거는 수신기(300)에게 유지 트리거의 타겟 TDO를 즉시 종료(terminate)할 것을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x05인 유지 트리거를 수신하면, 타겟 TDO가 종료되지 않은 경우에 타겟 TDO를 즉시 종료하고, 타겟 TDO가 이미 종료된 경우에 타겟 TDO의 종료를 유지할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x02인 유지 트리거를 수신하면, 수신기의 구현에 따라 타겟 TDO를 종료하면서 리소스를 반환할 수도 있고 리소스를 반환하지 않을 수도 있다. 리소스가 반환되지 않는 경우, 짧은 기간 내에 재실행되면 실행 속도가 향상될 수 있다.
트리거 액션 필드의 값이 0x06인 유지 트리거는 수신기(300)에게 유지 트리거에 의해 지정된 트리거를 무시(ignore)하도록 지시할 수 있다.
트리거 액션 필드의 값이 0x07인 유지 트리거는 수신기(300)에게 유지 트리거의 타겟 TDO의 실행을 계속할 것을 지시할 수 있다. 수신기(300)는 트리거 액션 필드의 값이 0x07인 유지 트리거를 수신하면, 타겟 TDO가 이미 실행된 경우에 타겟 TDO의 실행을 유지하고, 타겟 TDO가 실행되지 않은 경우에 타겟 TDO를 실행하지 않을 수 있다.
유지 정보 획득과 관련한 일 실시예에서, 수신기(300)는 준비 트리거에 의해 지정된 액션을 수행할 때 준비 트리거에 의해 지정된 타겟 TDO의 유지(즉시 실행, 준비, 타겟 TDO를 실행할 수 있음을 알림, 자원 반환, 종료, 무시, 실행 계속 등)를 위한 필요한 정보를 수신한 NRT-IT로부터 얻고 타겟 TDO를 저장하면서 이 타겟 TDO와 함께 유지 정보를 로컬 메모리에 저장할 수 있다. 수신기(300)가 준비 트리거에 의해 지정된 액션을 수행할 때 이외에도 수신기(300)는 수신한 NRT-IT로부터 타겟 TDO의 유지를 위한 정보를 얻고, 타겟 TDO와 함께 유지 정보를 로컬 메모리에 저장할 수 있다. 유지 트리거를 수신한 수신기(300)는 유지 트리거에 의해 지정된 타겟 TDO를 위한 유지 정보를 로컬 메모리로부터 얻어 이 유지 정보를 참조하여 유지 트리거에 의해 지정된 타겟 TDO를 유지할 수 있다.
유지 정보 획득과 관련한 또 다른 실시예에서, 유지 트리거를 수신한 수신기(300)는 타겟 TDO의 유지를 위한 정보를 수신한 NRT-IT로부터 얻고, 이 유지 정보를 참조하여 유지 트리거에 의해 지정된 타겟 TDO를 유지할 수 있다.
다음은 본 발명의 실시예에 따른 준비 트리거에서 트리거 시간 필드(trigger_time)의 의미를 설명한다.
준비 트리거의 전달 시점은 활성화 트리거의 전달 시점에 비해 상당히 앞설 수 있다. 준비 트리거는 향후의 트리거링 시점에 대한 대략적인 시간 정보를 제공할 수 있다. 따라서 준비 트리거의 시간 정보는 PCR을 레퍼런스하기 보다는 UTC 시간으로 설정되는 것도 고려될 수 있다.
준비 트리거의 트리거 시간은 시작 시간(start time), 끝 시간(end time), 예정된 활성화 시간(scheduled activation time) 중 어느 하나를 나타낼 수 있다.
먼저, 준비 트리거의 트리거 시간은 준비 트리거의 액션의 시작 시간을 나타낼 수 있다. 예컨데, 준비 트리거가 수신기(300)에게 활성화 트리거를 위한 컨텐트 아이템들을 미리 다운로드할 것을 지시하는 경우, 트리거 시간은 다운로드의 시작 시간을 나타낼 수 있다.
준비 트리거의 트리거 시간은 준비 트리거의 액션이 종료되어야할 마감 시간을 나타낼 수 있다. 이 경우, 준비 트리거의 트리거 시간까지는 준비 트리거의 액션이 종료되어야 준비 트리거와 연계된 활성화 트리거가 정상적으로 처리될 수 있다. 따라서, 수신기(300)는 준비 트리거의 트리거 시간 이전에 준비 트리거의 액션을 종료할 수 있도록 준비 트리거의 액션을 시작한다.
한편, 준비 트리거의 트리거 시간은 예정된 활성화 시간(scheduled activation time)을 나타낼 수 있다. 즉, 송신기(200)는 수신기(300)에게 준비 트리거와 연계된 활성화 트리거의 예정된 대략적인 트리거링 시점을 제공할 수 있다. 이 경우, 실제 정확한 타이밍은 활성화 트리거의 트리거 시간을 통해 제공될 수 있다.
이처럼, 준비 트리거의 트리거 시간은 준비 트리거의 액션의 정확한 수행 시점을 제공하기 보다는 준비 트리거에 의해 지정되는 타겟 TDO의 시기 적절한 활성화를 보장하기 위한 준비 액션의 시간 구간(time window)를 지시할 수 있다.
한편, 준비 트리거가 트리거 시간을 포함하지 않는 경우 수신기(300)는 즉시 준비 트리거를 수행할 수 있다.
다음은 본 발명의 실시예에 따른 유지 트리거에서 트리거 시간 필드(trigger_time)의 의미를 설명한다.
유지 트리거(Maintenance trigger)는 활성화 트리거(Activation Trigger)의 트리거링 시점 이후에 전달될 수 있다. 유지 트리거는 해당 트리거에 대한 처리 방안을 제공하는 것으로 볼 수 있으므로, 유지 트리거의 트리거 시간은 활성화 트리거의 트리거 시간에 비해 보다 낮은 타이밍 정확성(timing accuracy)을 요구할 수 있다. 따라서 유지 트리거의 시간 정보는 PCR을 레퍼런스하기 보다는 UTC 시간으로 설정되는 것도 고려될 수 있다.
유지 트리거의 트리거 시간은 시작 시간(start time), 끝 시간(end time) 중 어느 하나를 나타낼 수 있다.
유지 트리거의 트리거 시간은 유지 트리거(Maintenance trigger)의 액션(Action)을 시작할 수 있는 시간을 나타낼 수 있다. 현재 시스템 시간이 수신된 유지 트리거의 트리거 시간 이후이면, 수신기(300)는 유지 트리거의 액션을 즉시 수행할 수 있다. 만일 유지 트리거에서 시작 시간 등의 트리거 시간이 지정되지 않았을 경우에는, 수신기(300)는 실행 시간이 이미 지난 것으로 인식하고, 유지 트리거의 액션을 즉시 실행할 수 있다.
유지 트리거의 트리거 시간은 유지 트리거(Maintenance trigger)의 액션(Action)의 수행이 유효한 끝 시간(end time)을 나타낼 수도 있다. 이 경우에, 현재 시스템 시간이 수신된 유지 트리거의 트리거 시간 이후이면, 해당 트리거는 유효하지 않으며 수신기(300)는 지정된 액션(Action)을 수행해서는 안된다. 만일 끝 시간(end time)이 지정되지 않은 경우, 수신기(300)는 해당 트리거의 유효한 시간은 무한대로 지정된 것으로 간주할 수 있다.
이와 같이 유지 트리거(Maintenance trigger)의 트리거 시간은 유지 트리거의 액션(Action)을 수행할 수 있는 시간 구간(time window)를 지정할 수 있다.
다음은 본 발명의 다양한 실시예에 따른 준비 트리거와 활성화 트리거를 위한 컨텐트 아이템 지정 방법을 설명한다.
컨텐트 아이템 지정을 위한 일 실시예에서, 송신기(200)는 준비 트리거와 활성화 트리거를 위한 컨텐트 아이템을 트리거의 타겟 TDO를 식별하기 위한 식별자로 지정할 수 있다. 앞서 설명한 바와 같이 트리거의 타겟 TDO를 식별하기 위한 식별자는 service_id_ref 필드와 content_linkage 필드의 조합에 해당할 수 있다.
앞서 설명한 바와 같이, 송신기(200)는 TDO 식별자로 지정된 컨텐트 아이템의 위치 정보를 SMT, NRT-IT 및 FDT를 통해 제공할 수 있다. 구체적으로 송신기(200)는 SMT를 통해 트리거 내의 service_id_ref 필드에 해당하는 서비스 채널에 대한 정보를 제공한다. 이 시그널링 채널에 대한 정보는 SMT 내의 목적지 주소와 목적지 포트에 대한 정보를 통해 제공될 수 있다. 한편, 송신기(200)는 service_id_ref 필드에 해당하는 서비스에 속한 컨텐트 아이템들의 리스트를 NRT-IT를 통해 제공한다. 컨텐트 아이템들의 리스트는 NRT-IT내의 content_linkage의 리스트를 통해 제공될 수 있다. 송신기(200)는 트리거 내의 service_id_ref 필드에 해당하는 서비스 채널을 통해 각 컨텐트 아이템을 위한 하나 이상의 파일에 대한 정보를 포함하는 FDT를 제공한다. 각 파일에 대한 정보는 TOI 및 Content-Location 필드를 포함할 수 있다.
컨텐트 아이템 지정을 위한 또 다른 실시예에서, 송신기(200)는 준비 트리거와 활성화 트리거를 위한 컨텐트 아이템의 리스트를 디스크립터의 형태로 지정할 수 있다. 이 컨텐트 아이템 디스크립터는 트리거의 trigger_descriptor() 필드에 포함될 수 있다. 송신기(200)는 준비 트리거와 활성화 트리거를 위한 컨텐트 아이템의 리스트를 타겟 TDO 식별자와 함께 컨텐트 아이템 디스크립터를 통해 지정할 수도 있고, 타겟 TDO 식별자를 통해서는 지정하지 않는 대신에 컨텐트 아이템 디스크립터를 통해서만 지정할 수도 있다. 이러한 디스크립터의 한 예를 도 52를 참고하여 설명한다.
도 52는 본 발명의 한 실시예에 따른 컨텐트 아이템 디스크립터의 신택스를 보여준다.
도 52에 도시된 바와 같이, 컨텐트 아이템 디스크립터는 디스크립터 태그 필드(descriptor_tag), 디스크립터 길이 필드(descriptor_length), 서비스 카운트 필드(service_count), 서비스 식별자 필드(service_id), 컨텐트 아이템 카운트 필드(content_item_count), 컨텐트 링키지 필드(content_linkage)를 포함한다.
디스크립터 태그 필드(descriptor_tag)는 이 디스크립터를 컨텐트 아이템 디스크립터로서 구별하기 위한 8비트 부호없는 정수일 수 있다.
디스크립터 길이 필드(descriptor_length)는 이 필드를 즉시 뒤따르는 필드부터 컨텐트 아이템 디스크립터의 끝까지의 길이를 규정하는 8비트 부호없는 정수일 수 있다.
서비스 카운트 필드(service_count)는 컨텐트 아이템 디스크립터에 포함된 서비스의 개수를 나타낸다. 서비스 식별자 필드(service_id)는 컨텐트 아이템 디스크립터에 포함된 서비스의 식별자를 나타낸다. 따라서, 컨텐트 아이템 디스크립터는 서비스 카운트 필드에 해당하는 개수 만큼의 복수의 서비스 식별자 필드를 포함할 수 있다.
컨텐트 아이템 카운트 필드(content_item_count)는 서비스 식별자 필드(service_id)에 해당하는 서비스를 위한 컨텐트 아이템의 개수를 나타낸다. 컨텐트 링키지 필드(content_linkage)는 컨텐트 아이템의 식별자를 나타낸다. 따라서, 컨텐트 아이템 디스크립터는 각 서비스와 관련하여 컨텐트 아이템 카운트 필드에 해당하는 개수 만큼의 복수의 컨텐트 링키지 필드를 포함할 수 있다.
이와 같은 방식은 트리거에서 사용하는 컨텐트 아이템이 NRT 형태로 전송될 경우에 이용될 수 있으며, 이 때 각각의 컨텐트 아이템(content item)은 NRT Service ID와 Content linkage 값의 조합으로 유일하게 식별될 수 있다. 이전의 실시예와 마찬가지로, 송신기(200)는 TDO 식별자로 지정된 컨텐트 아이템의 위치 정보를 SMT, NRT-IT 및 FDT를 통해 제공할 수 있다.
컨텐트 아이템 지정을 위한 또 다른 실시예에서, 송신기(200)는 준비 트리거와 활성화 트리거를 위한 컨텐트 아이템의 리스트를 디스크립터의 형태로 지정할 수 있다. 송신기(200)는 이러한 인터넷 위치 디스크립터를 이용하여 방송망 및 IP 망을 통해 전송되는 컨텐트들을 트리거를 위한 컨텐트 아이템으로서 지정할 수 있다. 이 인터넷 위치 디스크립터는 트리거의 trigger_descriptor() 필드에 포함될 수 있다. 송신기(200)는 준비 트리거와 활성화 트리거를 위한 컨텐트 아이템의 리스트를 타겟 TDO 식별자와 함께 인터넷 위치 디스크립터를 통해 지정할 수도 있고, 타겟 TDO 식별자를 통해서는 지정하지 않는 대신에 인터넷 위치 디스크립터를 통해서만 지정할 수도 있다. 이러한 인터넷 위치 디스크립터의 한 예를 도 53을 참고하여 설명한다.
도 53은 본 발명의 한 실시예에 따른 인터넷 위치 디스크립터의 신택스를 보여준다.
도 53에 도시된 바와 같이, 인터넷 위치 디스크립터는 디스크립터 태그 필드(descriptor_tag), 디스크립터 길이 필드(descriptor_length), URL 카운트 필드(URL_count), URL 길이 필드(URL_length), URL() 필드를 포함한다.
디스크립터 태그 필드(descriptor_tag)는 이 디스크립터를 인터넷 위치 디스크립터로서 구별하기 위한 8비트 부호없는 정수일 수 있다. 예컨데, 이 필드는 0xC9 값을 가질 수 있다.
디스크립터 길이 필드(descriptor_length)는 이 필드를 즉시 뒤따르는 필드부터 인터넷 위치 디스크립터의 끝까지의 길이를 규정하는 8비트 부호없는 정수일 수 있다.
URL 카운트 필드(URL_count)는 인터넷 위치 디스크립터에 포함된 URL 길이 필드와 URL 필드의 쌍의 개수를 나타내는 5비트 부호없는 정수 일 수 있다. 즉, 인터넷 위치 디스크립터는 URL 카운트 필드에 해당하는 개수만큼의 복수의 URL 길이 필드와 URL 카운트 필드에 해당하는 개수만큼의 복수의 URL 필드를 포함한다.
URL 길이 필드(URL_length)는 이 필드를 바로 뒤따르는 URL() 필드의 길이를 나타내는 8비트 부호없는 정수이다.
URL() 필드는 URL(Uniform Reference Locator)을 나타내는 캐릭터 스트링이다. URL() 필드가 Relative URL이나 absolute tag URI를 나타내는 경우, 해당 URL은 NRT의 FLUTE를 통해서만 전송되는 컨텐트로 볼 수도 있다. 그 외의 경우에는 해당 URL은 방송망을 통해서 전송되는 컨텐트로 볼 수도 있고, IP망을 통해서 전송되는 컨텐트로 볼 수도 있고, 방송망 및 IP망 모두를 통해서 전송되는 컨텐트로 볼 수도 있다.
도 54는 본 발명의 또 다른 실시예에 따른 트리거 전송 방법을 도시한 흐름도이다.
송신기(200)는 준비 트리거의 전송 타이밍에서(S6001) 준비 트리거를 전송하고(S6003), 활성화 트리거의 전송 타이밍에서(S6005) 활성화 트리거를 전송하고(S6007), 유지 트리거의 전송 타이밍에서(S6009) 유지 트리거를 전송한다(S6011).
트리거는 PSIP 테이블이나 동기화된 데이터 스트림을 통해 전송될 수 있다.
PSIP 테이블을 통한 트리거 전송은 도 37, 도 41, 도 42를 통해 알 수 있다. 예컨데, 일 실시예에서, 트리거는 PSIP Base PID인 0x1FF인 스트림에 포함되어서 전달될 수 있다. 이 경우 트리거 테이블의 테이블 ID는 다른 테이블과의 구별을 위해 Unique하게 할당될 수 있다. 또 다른 실시예에서, 트리거는 Master Guide Table을 통해 할당되고 식별되는 PID에 해당하는 스트림을 통해서 전달될 수 있다. 이 경우에는 해당 스트림내에 있는 모든 테이블들은 트리거 테이블로 간주될 수 있다.
동기화된 데이터 스트림(Synchronized data stream)에 기반한 트리거 전송은 도 38, 도 39 및 도 40을 통해 알 수 있다. 동기화된 데이터 스트림은 PTS를 통해 다른 스트림과의 정확한 동기를 제공하므로, 동기화된 데이터 스트림(Synchronized data stream)에 기반한 트리거 전송은 PSIP 테이블을 통한 트리거 전송에 비하여 보다 높은 타이밍 정확성을 제공할 수 있다.
준비 트리거, 활성화 트리거 및 유지 트리거의 전송과 관련하여, 일 실시예에서, 준비 트리거, 활성화 트리거 및 유지 트리거는 하나의 스트림에 포함되어 전달될 수 있다.
또 다른 실시예에서, 송신기(200)는 준비 트리거를 PSIP 테이블을 통해 전달하고, 활성화 트리거(Activation Trigger)와 유지 트리거(Maintenance Trigger)를 동기화된 데이터 스트림을 통해 전송할 수 있다. 준비 트리거는 활성화 트리거(Activation Trigger)가 수행되어야 하는 시점보다 상당 시간 먼저 제공될 수도 있다. 실시 예에 따라서 준비 트리거가 제공되는 시점은 활성화 트리거(Activation Trigger)가 수행되어야 하는 시점보다 몇시간 전일 수도 있고 몇일 혹은 몇주 전일 수 있다. 준비 트리거는 수신기(300)가 활성화 트리거와 관련된 컨텐트 아이템을 미리 방송망이나 IP망을 통해 미리 다운로드할 수 있도록 필요할 수 있다. 이러한 준비 트리거의 특성으로 인하여 준비 트리거는 활성화 트리거(Activation Trigger)와 달리 장면(Scene) 단위의 타이밍 정확성(timing accuracy)을 요구하지 않을 수 있다. 따라서 활성화 트리거의 장면(Scene) 단위의 타이밍 정확성(timing accuracy)을 보장하기 위해 활성화 트리거(Activation Trigger)를 담은 스트림을 가능한한 compact하게 유지하는 방안도 고려될 수 있다. 이러한 목적으로 송신기(200)는 준비 트리거를 기존의 PSIP 시그널링 스트림을 통해서 별도의 테이블로 분리해서 전달할 수 있다. 준비 트리거를 담은 테이블은 준비 트리거만을 포함하여 PSIP 스트림을 통하여 전달될 수 있으며, 별도의 table id가 준비 트리거에 할당될 수도 있다.
또 다른 실시예에서, 송신기(200)는 준비 트리거 및 유지 트리거(Maintenance Trigger)를 PSIP 테이블 형태로 전송하고, 활성화 트리거(Activation Trigger)를 동기화된 데이터 스트리밍에 기반하여 전송할 수 있다. 유지 트리거는 트리거 시점을 놓친 수신기(300)에게 해당 트리거에 대응하는 방안을 지시 혹은 가이드하는 역할을 수행하므로, 특정 시점에 정확히 수행될 것이 요구되지 않을 수 있다. 따라서, 유지 트리거는 활성화 트리거(Activation Trigger) 보다 낮은 타이밍 정확성(timing accuracy)을 요구할 수 있다. 따라서, 유지 트리거(Maintenance Trigger)도 활성화 트리거(Activation Trigger)와 분리하여 준비 트리거와 함께 전송하는 방안을 생각해 볼 수 있다. 이 경우 송신기(200)는 준비 트리거와 유지 트리거를 하나의 테이블로 묶어서 전송할 수도 있다. 또한, 송신기(200)는 준비 트리거를 위한 테이블과 유지 트리거를 위한 테이블에 서로 다른 테이블 ID를 할당하고, 이를 통해 구분되는 2개의 테이블을 통해 준비 트리거와 유지 트리거를 전송할 수 있다.
다음은 도 55 내지 도 57을 참고하여 본 발명의 실시예에 따른 수신기(300)의 동작 방법을 설명한다.
도 55은 본 발명의 실시예에 따른 수신기의 동작 방법을 보여주는 흐름도이다.
수신기(300)는 트리거를 수신한다(S6101). 특히, 수신기(300)는 도 36 내지 도 42에 도시된 바와 같은 방법으로 트리거를 수신할 수 있다.
수신기(300)는 수신한 트리거의 종류를 확인한다(S6103). 수신기(300)는 앞서 설명한 바와 같은 방법으로 수신한 트리거의 종류를 확인할 수 있다. 예컨데, 수신기(300)는 트리거 내의 트리거 타입 필드(trigge_type)와 트리거 액션 필드(trigger_action) 중 하나 이상을 통해 트리거의 종류를 확인할 수 있다. 또한, 수신기(300)는 타겟 TDO의 활성화 여부나 트리거 타임의 경과 여부에 따라 트리거의 종류를 확인할 수 있다.
수신한 트리거가 준비 트리거이면(S6105), 수신기(300)는 수신한 준비 트리거를 처리한다(S6107). 수신기(300)의 준비 트리거의 처리에 대하여는 준비 트리거의 트리거 액션 필드와 관련하여 설명하였다. 이러한 준비 트리거의 처리를 통해 TDO의 상태가 변할 수 있다.
일실시예에서, 준비 트리거가 컨텐트 아이템의 다운로드를 트리거하는 경우, 도 56에서 보여지는 바와 같이 수신기(300)는 컨텐트 아이템의 위치 정보를 SMT, NRT-IT 및 FDT를 통해 파악하고, 파악한 위치 정보를 통해 컨텐트 아이템을 다운로드할 수 있다. 구체적으로 수신기(200)는 준비 트리거 내의 서비스 식별자에 해당하는 채널 정보를 SMT로부터 얻을 수 있다. 이때 채널 정보는 IP 주소와 포트 번호를 포함할 수 있다. 또한, 수신기(200)는 준비 트리거 내의 서비스 식별자에 해당하는 서비스에 속하는 컨텐트 식별자(content linkage)의 리스트를 NRT_IT로부터 얻을 수 있다. 수신기(200)는 트리거 내의 content linkage 필드 또는 트리거 내의 content_items_descriptor() 필드 내의 content linkage 필드 또는 NRT_IT내의 서비스 식별자에 해당하는 복수의 content_linkage 필드를 다운로드할 컨텐트 아이템의 식별자로 인식할 수 있다. 수신기(200)는 NRT_IT 내의 컨텐트 식별자들 또는 트리거 내의 컨텐트 식별자에 해당하는 컨텐트 위치들을 SMT의 IP 주소와 포트 번호를 통해 수신되는 FLUTE FDT로부터 파악할 수 있다. NRT_IT가 컨텐트 아이템의 인터넷 위치 정보를 가지고 있다면, 수신기(200)는 NRT_IT를 통해서도 컨텐트 아이템의 위치 정보를 파악할 수 있다.
또 다른 실시예에서, 준비 트리거가 컨텐트 아이템의 다운로드를 트리거하는 경우, 수신기(300)는 그 준비 트리거 내의 인터넷 위치 디스크립터로부터 다운로드할 컨텐트 아이템의 위치 정보를 파악하고, 파악한 위치 정보를 통해 컨텐트 아이템을 다운로드할 수 있다.
다시 도 55를 설명한다.
수신한 트리거가 활성화 트리거이면(S6109), 수신기(300)는 수신한 활성화 트리거를 처리한다(S6111). 수신기(300)의 활성화 트리거의 처리에 대하여는 활성화 트리거의 트리거 액션 필드와 관련하여 설명하였다. 이러한 활성화 트리거의 처리를 통해 TDO의 상태가 변할 수 있다.
수신한 트리거가 유지 트리거이면(S6113), 도 47에서 보여지는 바와 같이 수신기(300)는 수신한 유지 트리거를 처리한다(S6115).
도 57은 본 발명의 실시예에 따른 수신기가 트리거를 처리하는 방법을 보여주는 TDO 상태 천이도이다.
도 57에 도시된 바와 같이, 타겟 TDO는 준비되지 않은 상태(non-ready state)와 같은 해제 상태(released state)(ST110), 준비 상태(ready state)(ST120), 활동 상태(active state)(ST130), 중단 상태(suspended state)(ST140) 중 어느 한 상태에 있다.
수신기(300)가 준비 트리거를 수신하고 이 준비 트리거의 타겟 TDO가 해제 상태(ST110)에 있다면, 수신기(300)는 이 타겟 TDO를 준비하여 타겟 TDO의 상태를 준비 상태(ST120)로 둔다(S6201).
수신기(300)가 트리거 액션 필드의 값이 0x02인 종료 트리거를 수신하고 이 종료 트리거의 타겟 TDO가 준비 상태(ST120)에 있다면, 수신기(300)는 이 타겟 TDO를 종료하여 타겟 TDO의 상태를 해제 상태(ST110)로 둔다(S6203).
수신기(300)가 트리거 액션 필드의 값이 0x01인 실행 트리거를 수신하고 이 실행 트리거의 타겟 TDO가 준비 상태(ST120)에 있다면, 수신기(300)는 이 타겟 TDO를 실행하여 타겟 TDO의 상태를 활동 상태(ST130)로 둔다(S6205).
수신기(300)가 트리거 액션 필드의 값이 0x01인 유지 트리거를 수신하고 이 유지 트리거의 타겟 TDO가 활동 상태(ST120)에 있다면, 수신기(300)는 이 타겟 TDO의 상태를 활동 상태(ST130)로 유지한다(S6206).
수신기(300)가 트리거 액션 필드의 값이 0x04인 중단 트리거를 수신하고 이 중단 트리거의 타겟 TDO가 활동 상태(ST130)에 있다면, 수신기(300)는 이 타겟 TDO를 중단하여 타겟 TDO의 상태를 중단 상태(ST140)로 둔다(S6207).
수신기(300)가 웨이크업 트리거나 실행 트리거와 같은 별도의 트리거를 수신하고 이 별도의 트리거의 타겟 TDO가 중단 상태(ST140)에 있다면, 수신기(300)는 이 타겟 TDO를 다시 실행하여 타겟 TDO의 상태를 활동 상태(ST130)로 둔다(S6209).
수신기(300)가 트리거 액션 필드의 값이 0x02인 종료 트리거를 수신하고 이 종료 트리거의 타겟 TDO가 중단 상태(ST140)에 있다면, 수신기(300)는 이 타겟 TDO를 종료하여 타겟 TDO의 상태를 해제 상태(ST110)로 둔다(S6211). 또한, 수신기가 타겟 TDO와 관련된 채널로부터 벗어나라는 명령과 같은 사용자 명령을 수신하면, 수신기(300)는 이 타겟 TDO를 종료하여 타겟 TDO의 상태를 해제 상태(ST110)로 둘 수 있다.
수신기(300)가 트리거 액션 필드의 값이 0x01인 실행 트리거를 수신하고 이 실행 트리거의 타겟 TDO가 해제 상태(ST110)에 있다면, 수신기(300)는 이 타겟 TDO를 실행하여 타겟 TDO의 상태를 활동 상태(ST130)로 둔다(S6213).
수신기(300)가 트리거 액션 필드의 값이 0x02인 종료 트리거를 수신하고 이 종료 트리거의 타겟 TDO가 활동 상태(ST130)에 있다면, 수신기(300)는 이 타겟 TDO를 종료하여 타겟 TDO의 상태를 해제 상태(ST110)로 둔다(S6215).
상술한 본 발명에 따른 트리거 수신 방법 및 전송 방법은 컴퓨터에서 실행되기 위한 프로그램으로 제작되어 컴퓨터가 읽을 수 있는 기록 매체에 저장될 수 있으며, 컴퓨터가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한 캐리어 웨이브(예를 들어 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다.
컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 컴퓨터가 읽을 수 있는 코드가 저장되고 실행될 수 있다. 그리고, 방법을 구현하기 위한 기능적인(function) 프로그램, 코드 및 코드 세그먼트들은 본 발명이 속하는 기술분야의 프로그래머들에 의해 용이하게 추론될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형 실시가 가능한 것은 물론이고, 이러한 변형 실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해 되어서는 안될 것이다.

Claims (18)

  1. 제1 패킷화된 스트림을 수신하는 단계;
    상기 제1 패킷화된 스트림의 헤더로부터 표시 시간 정보를 추출하는 단계;
    상기 제1 패킷화된 스트림의 페이로드로부터 타겟 오브젝트 식별자를 포함하는 트리거 정보를 추출하는 단계;
    상기 트리거 정보의 종류를 인식하는 단계;
    상기 트리거 정보가 준비 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 해제 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 준비하여 상기 오브젝트의 상태를 준비 상태로 천이시키는 단계;
    상기 트리거 정보가 실행 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 준비 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 실행하여 상기 오브젝트의 상태를 활동 상태로 천이시키는 단계; 및
    상기 트리거 정보가 중단 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 활동 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 중단하여 상기 오브젝트의 상태를 중단 상태로 천이시키는 단계를 포함하는
    방송 수신 장치의 방송 서비스 수신 방법.
  2. 제1항에 있어서,
    상기 트리거 정보가 종료 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 중단 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 종료하여 상기 오브젝트의 상태를 상기 해제 상태로 천이시키는 단계를 더 포함하는
    방송 서비스 수신 방법.
  3. 제1항에 있어서,
    상기 트리거 정보가 소정의 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 중단 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 실행하여 상기 오브젝트의 상태를 상기 활동 상태로 천이시키는 단계를 더 포함하는
    방송 서비스 수신 방법.
  4. 제1항에 있어서,
    상기 오브젝트의 종료에 관한 사용자 명령을 수신하고 상기 오브젝트의 상태가 중단 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 종료하여 상기 오브젝트의 상태를 상기 해제 상태로 천이시키는 단계를 더 포함하는
    방송 서비스 수신 방법.
  5. 제1항에 있어서,
    상기 트리거 정보가 유지 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 활동 상태에 있다면, 상기 오브젝트의 상태를 활동 상태로 유지시키는 단계를 더 포함하는
    방송 서비스 수신 방법.
  6. 제1항에 있어서,
    상기 트리거 정보가 실행 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 해제 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 실행하여 상기 오브젝트의 상태를 상기 활동 상태로 천이시키는 단계를 더 포함하는
    방송 서비스 수신 방법.
  7. 제1항에 있어서,
    상기 트리거 정보가 종료 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 활동 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 종료하여 상기 오브젝트의 상태를 상기 해제 상태로 천이시키는 단계를 더 포함하는
    방송 서비스 수신 방법.
  8. 제1항에 있어서,
    상기 트리거 정보가 종료 트리거에 해당하고 상기 타겟 오브젝트 식별자에 해당하는 오브젝트의 상태가 상기 준비 상태에 있다면, 상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 종료하여 상기 오브젝트의 상태를 상기 해제 상태로 천이시키는 단계를 더 포함하는
    방송 서비스 수신 방법.
  9. 제1항에 있어서,
    상기 타겟 오브젝트 식별자에 해당하는 오브젝트를 실행하여 상기 오브젝트의 상태를 활동 상태로 천이시키는 단계는
    사용자로부터 상기 오브젝트의 실행 명령을 수신하면 상기 오브젝트를 상기 표시 시간 정보에 해당하는 시간에서 실행하는 단계를 포함하는
    방송 서비스 수신 방법.
  10. 제1항에 있어서,
    상기 제1 패킷화된 스트림의 헤더로부터 추출된 표시 시간 정보는 제2 패킷화된 스트림의 헤더로부터 추출된 표시 시간 정보와 동기화되고,
    상기 제1 패킷화된 스트림은 트리거 스트림을 포함하고,
    상기 제2 패킷화된 스트림은 오디오 또는 비디오 스트림을 포함하고,
    상기 제1 패킷화된 스트림의 헤더로부터 추출되는 상기 표시 시간 정보는 상기 제1 패킷화된 스트림의 헤더 내의 표시 시간 스탬프 값인
    방송 서비스 수신 방법.
  11. 제1 패킷화된 스트림을 수신하는 수신부;
    상기 제1 패킷화된 스트림의 헤더로부터 표시 시간 정보를 추출하고, 상기 제1 패킷화된 스트림의 페이로드로부터 타겟 오브젝트 식별자 필드와 트리거 액션 필드를 포함하는 트리거 정보를 추출하는 트리거 처리부; 및
    상기 제1 패킷화된 스트림의 헤더로부터 상기 표시 시간 정보가 추출되지 않으면, 상기 상기 타겟 오브젝트 식별자 필드에 해당하는 오브젝트에 관하여 상기 트리거 액션 필드에 해당하는 액션을 즉시 수행하는 서비스 매니저를 포함하는
    방송 서비스 수신 장치.
  12. 제11항에 있어서
    상기 트리거 정보는 유지 트리거에 해당하고,
    상기 오브젝트에 관한 상기 액션이 이미 수행되었으면 상기 서비스 매니저는 상기 오브젝트에 관한 상기 액션을 유지하고,
    상기 오브젝트에 관한 상기 액션이 아직 수행되지 않았으면 상기 서비스 매니저는 상기 오브젝트에 관한 상기 액션을 즉시 수행하는
    방송 서비스 수신 장치.
  13. 제1 패킷화된 스트림을 수신하는 단계;
    상기 제1 패킷화된 스트림의 헤더로부터 표시 시간 정보를 추출하는 단계;
    상기 제1 패킷화된 스트림의 페이로드로부터 타겟 오브젝트 식별자를 포함하는 트리거 정보를 추출하는 단계;
    상기 트리거 정보의 종류를 인식하는 단계;
    상기 트리거 정보가 준비 트리거인 경우에, 상기 타겟 오브젝트 식별자에 속한 파일의 위치 정보를 획득하는 단계; 및
    상기 위치 정보를 통해 상기 타겟 오브젝트 식별자에 속한 파일을 상기 표시 시간 정보에 해당하는 시간에 다운로드하는 단계를 포함하는
    방송 수신 장치의 방송 서비스 수신 방법.
  14. 제13항에 있어서,
    상기 타겟 오브젝트 식별자는 서비스 식별자와 컨텐트 식별자를 포함하고,
    상기 타겟 오브젝트 식별자에 속한 파일의 위치 정보를 획득하는 단계는
    상기 서비스 식별자에 기초하여 상기 위치 정보를 획득하는 단계를 포함하는
    방송 서비스 수신 방법.
  15. 제14항에있어서,
    상기 서비스 식별자에 기초하여 상기 위치 정보를 획득하는 단계는
    상기 서비스 식별자에 해당하는 채널 정보를 제1 테이블로부터 획득하는 단계;
    상기 채널 정보를 통해 제2 테이블을 수신하는 단계;
    상기 파일 디스크립션 테이블로부터 상기 위치 정보를 획득하는 단계를 포함하는 방송 서비스 수신 방법.
  16. 제15항에 있어서,
    상기 파일 디스크립션 테이블로부터 상기 위치 정보를 획득하는 단계는
    제3 테이블로부터 상기 서비스 식별자에 해당하는 서비스에 속한 컨텐트 아이템의 식별자를 획득하는 단계;
    제3 테이블로부터 획득한 컨텐트 아이템 식별자에 해당하는 위치 정보를 상기 파일 디스크립션 테이블로부터 획득하는 단계를 포함하는
    방송 서비스 수신 방법.
  17. 제16항에 있어서,
    상기 제1 테이블은 서비스 맵 테이블에 해당하고,
    상기 제2 테이블은 파일 디스크립션 테이블에 해당하고,
    상기 제3 테이블은 비실시간 정보 테이블에 해당하는
    방송 서비스 수신 방법.
  18. 제13항에 있어서,
    상기 타겟 오브젝트 식별자에 속한 파일의 위치 정보를 획득하는 단계는
    상기 트리거 정보의 디스크립터로부터 상기 상기 타겟 오브젝트 식별자에 속한 파일의 위치 정보를 획득하는 단계를 포함하는
    방송 서비스 수신 방법.
PCT/KR2012/000511 2011-01-19 2012-01-19 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치 WO2012099427A2 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
KR1020137018384A KR101690831B1 (ko) 2011-01-19 2012-01-19 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
CA2824965A CA2824965C (en) 2011-01-19 2012-01-19 Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
US13/980,335 US8978083B2 (en) 2011-01-19 2012-01-19 Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
US14/604,070 US9769518B2 (en) 2011-01-19 2015-01-23 Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201161433974P 2011-01-19 2011-01-19
US61/433,974 2011-01-19

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/980,335 A-371-Of-International US8978083B2 (en) 2011-01-19 2012-01-19 Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
US14/604,070 Continuation US9769518B2 (en) 2011-01-19 2015-01-23 Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service

Publications (2)

Publication Number Publication Date
WO2012099427A2 true WO2012099427A2 (ko) 2012-07-26
WO2012099427A3 WO2012099427A3 (ko) 2012-12-06

Family

ID=46516260

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/000511 WO2012099427A2 (ko) 2011-01-19 2012-01-19 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치

Country Status (4)

Country Link
US (2) US8978083B2 (ko)
KR (1) KR101690831B1 (ko)
CA (1) CA2824965C (ko)
WO (1) WO2012099427A2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016056800A1 (ko) * 2014-10-06 2016-04-14 엘지전자 주식회사 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
US11343549B2 (en) 2014-11-13 2022-05-24 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, and transmission method

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012099427A2 (ko) * 2011-01-19 2012-07-26 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
CA2839444C (en) * 2011-06-16 2016-05-31 Lg Electronics Inc. Method for transmitting a broadcast service, method for receiving a broadcast service, and apparatus for receiving a broadcast service
WO2013111630A1 (ja) * 2012-01-24 2013-08-01 ソニー株式会社 受信装置、受信方法、プログラム、及び情報処理システム
JP2015073245A (ja) * 2013-10-04 2015-04-16 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US9544655B2 (en) 2013-12-13 2017-01-10 Nant Holdings Ip, Llc Visual hash tags via trending recognition activities, systems and methods
KR102205703B1 (ko) * 2014-04-18 2021-01-21 한국전자통신연구원 증강방송 서비스를 위한 방송 사업자 장치, 콘텐츠 사업자 장치, 수신 단말 및 증강방송 서비스 방법
JP6300114B2 (ja) * 2014-08-06 2018-03-28 パナソニックＩｐマネジメント株式会社 送信方法、受信方法、送信装置及び受信装置
US20160197669A1 (en) 2014-12-11 2016-07-07 Tesla Wireless Company LLC Communication method and system that uses low latency/low data bandwidth and high latency/high data bandwidth pathways
EP3244626B1 (en) * 2015-01-07 2021-03-24 Sony Corporation Reception device, reception method, transmission device, and transmission method
US10306297B2 (en) 2015-06-23 2019-05-28 Samsung Electronics Co., Ltd. Method and apparatus for transmitting and receiving signal in multimedia system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080102316A (ko) * 2006-04-18 2008-11-24 모토로라 인코포레이티드 전송 윈도우를 사용하는 통신 시스템에서의 최적화된 패킷 데이터 전송 프로토콜
KR20090021111A (ko) * 2007-08-24 2009-02-27 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR20090103182A (ko) * 2008-03-27 2009-10-01 삼성전자주식회사 디지털 방송 서비스 방법 및 시스템
KR20090122256A (ko) * 2007-03-09 2009-11-26 노키아 코포레이션 다수의 컴포넌트들을 포함하는 통지 메시지들을 전송하기 위한 방법 및 장치

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7174562B1 (en) * 1999-12-20 2007-02-06 Microsoft Corporation Interactive television triggers having connected content/disconnected content attribute
US7584491B2 (en) * 2001-04-25 2009-09-01 Sony Corporation System and method for managing interactive programming and advertisements in interactive broadcast systems
US7886332B2 (en) 2002-03-19 2011-02-08 Canon Kabushiki Kaisha Television broadcast receiving apparatus
KR101314291B1 (ko) * 2007-02-15 2013-10-02 삼성전자주식회사 디지털 방송의 미들웨어 표준이 다른 장치에서 상호서비스를 제공하는 장치 및 방법
CA2721397C (en) 2008-05-02 2014-09-30 Lg Electronics Inc. Method of receiving broadcasting signal and apparatus for receiving broadcasting signal
US20110177774A1 (en) * 2010-01-13 2011-07-21 Qualcomm Incorporated Dynamic generation, delivery, and execution of interactive applications over a mobile broadcast network
US8863171B2 (en) * 2010-06-14 2014-10-14 Sony Corporation Announcement of program synchronized triggered declarative objects
JP5765558B2 (ja) * 2010-08-27 2015-08-19 ソニー株式会社 受信装置、受信方法、送信装置、送信方法、プログラム、および放送システム
US20120050619A1 (en) * 2010-08-30 2012-03-01 Sony Corporation Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system
US8595783B2 (en) * 2010-08-30 2013-11-26 Sony Corporation Receiving device, receiving method, program, and broadcasting system
US10511887B2 (en) * 2010-08-30 2019-12-17 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, transmission method, program, and broadcasting system
WO2012029584A1 (ja) * 2010-08-30 2012-03-08 ソニー株式会社 受信装置、受信方法、及びプログラム
US9179198B2 (en) * 2010-10-01 2015-11-03 Sony Corporation Receiving apparatus, receiving method, and program
CN103283219B (zh) * 2010-12-26 2016-08-31 Lg电子株式会社 接收广播服务的方法和设备
WO2012099427A2 (ko) * 2011-01-19 2012-07-26 엘지전자 주식회사 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
TWI574565B (zh) * 2011-03-31 2017-03-11 Sony Corp A transmitting apparatus, a transmitting method, a receiving apparatus, a receiving method, a computer-readable medium, and a broadcasting system
US8917358B2 (en) * 2011-07-27 2014-12-23 Sony Corporation Reception apparatus, terminal apparatus, control method, program, and communication system
US8930988B2 (en) * 2011-12-21 2015-01-06 Sony Corporation Reception apparatus, reception method, program, and information processing system
WO2013111630A1 (ja) * 2012-01-24 2013-08-01 ソニー株式会社 受信装置、受信方法、プログラム、及び情報処理システム
US9414002B2 (en) * 2012-02-07 2016-08-09 Sony Corporation Receiving apparatus, receiving method, and program
US9456245B2 (en) * 2012-07-05 2016-09-27 Sony Corporation Receiving device, receiving method, transmitting device, and transmitting method for controlling applications

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20080102316A (ko) * 2006-04-18 2008-11-24 모토로라 인코포레이티드 전송 윈도우를 사용하는 통신 시스템에서의 최적화된 패킷 데이터 전송 프로토콜
KR20090122256A (ko) * 2007-03-09 2009-11-26 노키아 코포레이션 다수의 컴포넌트들을 포함하는 통지 메시지들을 전송하기 위한 방법 및 장치
KR20090021111A (ko) * 2007-08-24 2009-02-27 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR20090103182A (ko) * 2008-03-27 2009-10-01 삼성전자주식회사 디지털 방송 서비스 방법 및 시스템

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016056800A1 (ko) * 2014-10-06 2016-04-14 엘지전자 주식회사 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
US11343549B2 (en) 2014-11-13 2022-05-24 Saturn Licensing Llc Reception apparatus, reception method, transmission apparatus, and transmission method

Also Published As

Publication number Publication date
KR20140033325A (ko) 2014-03-18
US20150172750A1 (en) 2015-06-18
CA2824965A1 (en) 2012-07-26
KR101690831B1 (ko) 2016-12-28
US20130305308A1 (en) 2013-11-14
US8978083B2 (en) 2015-03-10
CA2824965C (en) 2016-05-24
WO2012099427A3 (ko) 2012-12-06
US9769518B2 (en) 2017-09-19

Similar Documents

Publication Publication Date Title
WO2012091370A1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2012144867A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2012091371A1 (en) Method for transmitting broadcast service, method for receiving the broadcasting service, and apparatus for receiving the broadcasting service
WO2012091322A1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2012099427A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2013022309A1 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
WO2012161535A2 (ko) 방송 서비스 전송 방법, 그 수신 장치 및 그 수신 장치의 부가 서비스 처리 방법
WO2009151265A2 (ko) 방송 신호 수신 방법 및 수신 시스템
WO2013058633A1 (ko) 방송 서비스 수신 방법 및 방송 서비스 수신 장치
WO2012173441A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 방송 서비스 수신 장치
WO2011049278A1 (en) Method for processing broadcast program information and broadcast receiver
WO2012111979A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2010068033A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2014025207A1 (en) A method and an apparatus for processing a broadcast signal including an interactive broadcast service
WO2012169779A2 (ko) 방송 서비스 전송 방법, 그 수신 방법 및 그 수신 장치
WO2010058958A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2010021526A2 (en) A method for processing additional information related to an announced service or content in an nrt service and a broadcast receiver
WO2010068040A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2010082783A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2014003394A1 (en) Apparatus and method for processing an interactive service
WO2011112053A2 (ko) 비실시간 방송 서비스 처리 시스템 및 그 처리방법
WO2013042902A1 (ko) 방송 서비스 수신 방법 및 그 수신 장치
WO2014030924A1 (en) Apparatus and method for processing an interactive service
WO2011062385A2 (ko) 방송 신호 송수신 방법 및 그를 이용한 방송 수신 장치
WO2009151267A2 (ko) 서비스 제공 방법 및 방송 수신기

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12736984

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 20137018384

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2824965

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 13980335

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12736984

Country of ref document: EP

Kind code of ref document: A2