WO2019212318A1 - 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치 - Google Patents

방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치 Download PDF

Info

Publication number
WO2019212318A1
WO2019212318A1 PCT/KR2019/005400 KR2019005400W WO2019212318A1 WO 2019212318 A1 WO2019212318 A1 WO 2019212318A1 KR 2019005400 W KR2019005400 W KR 2019005400W WO 2019212318 A1 WO2019212318 A1 WO 2019212318A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
service
network
multicast
broadcast signal
Prior art date
Application number
PCT/KR2019/005400
Other languages
English (en)
French (fr)
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 EP19796648.4A priority Critical patent/EP3790286A4/en
Publication of WO2019212318A1 publication Critical patent/WO2019212318A1/ko

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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • 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/23614—Multiplexing of additional data and video streams
    • H04N21/23617—Multiplexing of additional data and video streams by inserting additional data into a data carousel, e.g. inserting software modules into a DVB carousel
    • 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/2362—Generation or processing of Service Information [SI]
    • 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/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/4348—Demultiplexing of additional data and video streams
    • H04N21/4349—Demultiplexing of additional data and video streams by extracting from data carousels, e.g. extraction of software modules from a DVB carousel
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Definitions

  • the present invention relates to a broadcast signal transmitting apparatus, a broadcast signal transmitting method, a broadcast signal receiving method, and a broadcast signal receiving apparatus.
  • the digital broadcast signal may include a larger amount of video / audio data than the analog broadcast signal, and may further include various types of additional data as well as the video / audio data.
  • the apparatus for transmitting and receiving broadcast signals implements an IP-based TV service capable of providing the same user UX as the terrestrial, satellite, and cable linear channels.
  • the apparatus for transmitting and receiving broadcast signals provides a channel guide integrated with terrestrial, satellite, and cable channels through open internet based native code reception, rather than an application based linear channel service.
  • the broadcast service is consumed through media such as OTT, PC, IPTV, etc. of IP-based devices, and the traffic of unicast is not directly received by the fixed wave. Considering this, it provides a seamless service of real-time / non-real-time media streaming service.
  • An apparatus for transmitting and receiving broadcast signals provides a network control method and information for transmitting file-based content in a linear IP adaptive multicast broadcasting environment.
  • the broadcast signal transmission method generating a packet including service data and signaling information for the service data, encoding the packet, the packet Transmitting a broadcast signal comprising a.
  • the signaling information includes network information on the broadcast signal
  • the network information includes first identification information on a main network or an Arthur network, and the first identification information indicates the Arthur network.
  • the network information includes second identification information for the internet linear channel.
  • the signaling information is transmitted based on an internet linear channel
  • the signaling information includes service discovery information for obtaining service data for the internet channel
  • the signaling information identifies service data for the internet channel. Contains URI (Uniform Resource Identifier) information.
  • the apparatus for transmitting and receiving broadcast signals provides a service accessed through a UI in which an existing linear service and an OTT service are integrated.
  • the apparatus for transmitting and receiving broadcast signals realizes a media service that provides the same UX as existing linear channels through the open Internet without an STB.
  • An apparatus for transmitting and receiving broadcast signals proposes a method of delivering service discovery for an ABR service.
  • the broadcast signal transmission and reception apparatus provides a file identification method in consideration of a transmission method such as unicast / multicast / broadcast.
  • the broadcast signal transmission and reception apparatus proposes a structure of a network for IP-based multicast transmission and reception, and provides a seamless service to a user through multicast / unicast dynamic allocation.
  • FIG. 1 illustrates a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to embodiments of the present invention.
  • FIG. 2 illustrates a structure of a broadcast signal receiving apparatus for a next generation broadcast service according to embodiments of the present invention.
  • FIG. 3 illustrates a structure in which a broadcast signal transmitting apparatus and a broadcast signal receiving apparatus transmit and receive a service according to embodiments of the present invention.
  • FIG. 4 illustrates a network structure of a broadcast signal transmitting apparatus and a broadcast signal receiving apparatus according to embodiments of the present invention.
  • FIG. 5 illustrates a structure in which a broadcast signal receiving apparatus receives data according to embodiments of the present invention.
  • NIT network information table
  • SDT service description table
  • FIG 9 illustrates a process of parsing signaling information by the apparatus for receiving broadcast signals according to embodiments of the present invention.
  • URI_linkage_descriptor shows the configuration of a URI descriptor (URI_linkage_descriptor).
  • uri_linkage_type a configuration of URI linkage type (uri_linkage_type) information.
  • Fig. 13 shows the configuration of private data.
  • IP_channel_ID_descriptor IP_channel_ID_descriptor
  • FIG. 16 illustrates a process of service discovery based on a bouquet.
  • Fig. 22 shows the configuration of the user class option.
  • Figure 23 shows the format of DHCP.
  • Figure 24 shows a service provider discovery information record.
  • Fig. 25 shows the configuration of data for the service discovery and selection server according to the payload ID value.
  • Fig. 26 shows the structure of the offering list type information.
  • Fig. 28 shows the configuration of the offering list type.
  • 29 illustrates the push mode and pull mode for the offering element.
  • Figure 31 illustrates an embodiment of service provider discovery.
  • 38 illustrates a service discovery configuration for a single service.
  • FIG. 40 shows a configuration for providing a service incorporating an Internet channel.
  • Fig. 41 shows the configuration of the integrated channel guide UI.
  • 43 shows a network structure for adaptive media streaming.
  • 45 shows the configuration of a content network for broadcasting.
  • Fig. 46 shows the configuration of a content network for broadcasting of satellites.
  • FIG. 48 shows a configuration of an ABR multicast network for a cable network.
  • 49 shows a configuration of an ABR multicast network for a mobile network.
  • 50 shows the configuration of a user network for a home network.
  • 51 shows a network structure for adaptive media streaming.
  • 52 illustrates a protocol for adaptive media streaming.
  • 53 illustrates a protocol for adaptive media streaming.
  • FIG. 54 illustrates a protocol for signaling and control for the multicast sender on FIG. 52.
  • FIG. 55 shows a protocol for signaling and control for the multicast receiver and decoder on FIG.
  • FIG. 56 shows a protocol for signaling and control on FIG.
  • 57 shows a protocol stack for IP multicast.
  • 58 shows a media delivery method for IP multicasting.
  • 60 shows media delivery for IP multicasting.
  • Fig. 61 shows the structure, generation, and parsing sequence of the DASH segment.
  • Fig. 62 shows the structure of the DASH segment.
  • Fig. 63 shows the structure, generation, and parsing order of the DASH segment.
  • 64 shows a user network for playback of a DASH segment.
  • 65 shows an MPD hierarchical structure.
  • 66 shows a user network for playback of a DASH segment.
  • 67 shows a signaling method for fast startup.
  • 69 shows base url definition according to the Multicast ABR delivery method.
  • 70 shows a method of constructing a segment access URL.
  • 71 illustrates a multicast ABR service architecture.
  • 73 illustrates a broadcast signal transmission method according to embodiments of the present invention.
  • 74 is a view illustrating a broadcast signal receiving method according to embodiments of the present invention.
  • 75 illustrates a process of a broadcast signal receiving apparatus discovering a service and displaying a service guide according to an embodiment of the present invention.
  • FIG. 1 illustrates a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to embodiments of the present invention.
  • An apparatus for transmitting broadcast signals for a next generation broadcast service includes an input format block 1000, a bit interleaved coding & modulation (BICM) block 1010, and a frame building block. 1020, orthogonal frequency division multiplexing (OFDM) generation block (OFDM generation block) 1030, and signaling generation block 1040. The operation of each block of the broadcast signal transmission apparatus will be described.
  • BICM bit interleaved coding & modulation
  • OFDM generation block orthogonal frequency division multiplexing
  • signaling generation block 1040 The operation of each block of the broadcast signal transmission apparatus will be described.
  • IP streams / packets and MPEG2-TS are the main input formats and other stream types are treated as general streams.
  • management information is input to control the scheduling and allocation of the corresponding bandwidth for each input stream.
  • One or multiple TS streams, IP streams and / or general stream inputs are allowed at the same time.
  • the input format block 1000 can demultiplex each input stream into one or multiple data pipes to which independent coding and modulation is applied.
  • the data pipe is the basic unit for controlling robustness, which affects the quality of service (QoS).
  • QoS quality of service
  • One or multiple services or service components may be delivered by one data pipe.
  • a data pipe is a logical channel at the physical layer that carries service data or related metadata that can carry one or multiple services or service components.
  • the data pipe may correspond to a physical layer pipe (PLP).
  • PLP physical layer pipe
  • the data pipe unit is a basic unit for allocating data cells to data pipes in one frame.
  • parity data is added for error correction and the encoded bit stream is mapped to a complex value constellation symbol.
  • the symbols are interleaved over the specific interleaving depth used for that data pipe.
  • MIMO encoding is performed at BICM block 1010 and additional data paths are added to the output for MIMO transmission.
  • the frame building block 1020 may map data cells of an input data pipe to OFDM solid balls within one frame. After mapping, frequency interleaving is used for frequency domain diversity, in particular to prevent frequency selective fading channels.
  • the OFDM generation block 1030 can apply existing OFDM modulation having a cyclic prefix as the guard interval.
  • a distributed MISO scheme is applied across the transmitter.
  • a peak-to-average power ratio (PAPR) scheme is implemented in the time domain.
  • PAPR peak-to-average power ratio
  • the signaling generation block 1040 may generate physical layer signaling information used for the operation of each functional block.
  • the signaling information is also transmitted such that the service of interest is properly recovered at the receiver side.
  • FIG. 2 illustrates a structure of a broadcast signal receiving apparatus for a next generation broadcast service according to embodiments of the present invention.
  • the broadcast signal reception apparatus for the next generation broadcast service may correspond to the broadcast signal transmission apparatus for the next generation broadcast service described with reference to FIG. 1.
  • An apparatus for receiving broadcast signals for a next generation broadcast service includes a synchronization & demodulation module 9000, a frame parsing module 9010, a demapping and decoding module a demapping & decoding module 9020, an output processor 9030, and a signaling decoding module 9040. The operation of each module of the broadcast signal receiving apparatus will be described.
  • the synchronization and demodulation module 9000 receives an input signal through m reception antennas, performs signal detection and synchronization on a system corresponding to the broadcast signal receiving apparatus, and performs a reverse process of the procedure performed by the broadcast signal transmitting apparatus. Demodulation can be performed.
  • the frame parsing module 9010 may parse an input signal frame and extract data in which a service selected by a user is transmitted.
  • the frame parsing module 9010 may execute deinterleaving corresponding to the reverse process of interleaving. In this case, positions of signals and data to be extracted are obtained by decoding the data output from the signaling decoding module 9040, so that the scheduling information generated by the broadcast signal transmission apparatus may be restored.
  • the demapping and decoding module 9020 may convert the input signal into bit region data and then deinterleave the bit region data as necessary.
  • the demapping and decoding module 9020 can perform demapping on the mapping applied for transmission efficiency, and correct an error generated in the transmission channel through decoding. In this case, the demapping and decoding module 9020 can obtain transmission parameters necessary for demapping and decoding by decoding the data output from the signaling decoding module 9040.
  • the output processor 9030 may execute a reverse process of various compression / signal processing procedures applied by the broadcast signal transmission apparatus to improve transmission efficiency.
  • the output processor 9030 may obtain necessary control information from the data output from the signaling decoding module 9040.
  • the output of the output processor 8300 corresponds to a signal input to the apparatus for transmitting broadcast signals, and may be MPEG-TS, IP stream (v4 or v6), and GS.
  • the signaling decoding module 9040 may obtain PLS information from the signal demodulated by the synchronization and demodulation module 9000. As described above, the frame parsing module 9010, the demapping and decoding module 9200, and the output processor 9300 may execute the function using data output from the signaling decoding module 9040.
  • FIG. 3 illustrates a structure in which a broadcast signal transmitting apparatus and a broadcast signal receiving apparatus transmit and receive a service according to embodiments of the present invention.
  • the broadcaster may provide a service based on terrestrial (T), cable (Cable, C), and satellite (Satellite, S) channels. Furthermore, the broadcasting station may provide a service based on an internet channel simultaneously with the T channel, the C channel, and the S channel. Accordingly, the apparatus for transmitting broadcast signals and the apparatus for receiving broadcast signals according to the embodiments of the present invention may transmit and receive services based on a T channel, a C channel, an S channel, and an Internet channel. Broadcasting stations, manufacturers, and operators may define authentication methods for each channel. The broadcast signal receiving apparatus according to the embodiments of the present invention may obtain authentication for each service channel based on a rule made by a broadcasting station, a manufacturer, or a service provider. In addition, the broadcast signal transmission apparatus and the broadcast signal reception apparatus according to the embodiments of the present invention may use the Internet channel integrated with the existing linear service.
  • the broadcast signal transmitting apparatus and the broadcast signal receiving apparatus use the service discovery information provided by the existing linear network in order to use the internet channel and the existing linear broadcast channel list in an integrated form. Bootstrapping may be provided.
  • the broadcast signal transmission apparatus can provide a service by extending an existing form of providing a service, and on-demand / multicast service with an existing linear channel network. It can provide additional services such as forms.
  • the broadcast signal transmission apparatus may provide a personalization service through an Internet channel based usage report.
  • the broadcast signal transmission apparatus may provide a channel list integrating existing T-channel, S-channel, and C-channel services and over-the-top (OTT) services.
  • the broadcast signal receiving apparatus may provide various services to a user, and functions of the broadcast signal transmitting apparatus and the broadcast signal receiving apparatus may be extended.
  • a network in which OTT contents may be integrated and provided may be established.
  • the broadcast signal transmission apparatus may dynamically allocate unicast / multicast and provide enhanced delivery performance.
  • the broadcast signal reception apparatus may provide superior performance than a terminal for providing a service based on a non-management network.
  • FIG. 4 illustrates a network structure of a broadcast signal transmitting apparatus and a broadcast signal receiving apparatus according to embodiments of the present invention.
  • the broadcast signal receiving apparatus may correspond to the terminal (TV) 40009.
  • the detailed configuration of the TV 40009 has been described with reference to FIG. 2.
  • the set top box 40008 may be connected to a broadcast signal receiving apparatus.
  • the set top box 40008 may be connected to a broadcast signal receiving apparatus based on the HDMI method.
  • the gateway 40007 receives the content or the service from the broadband network 4005 and provides the content or the service to the set-top box 40008.
  • the broadband network 40005 provides a broadcast signal receiving apparatus with content or service related to the broadband network.
  • the content network 40006 provides data related to the content to the broadband network 40005.
  • the multicast headend 40002 delivers data to the broadband network 40005 based on the multicast scheme.
  • the source DVB-I source 40003 provides data to the broadband network 40005.
  • the data provided by the source may include data according to the DVB-I scheme.
  • the terrestrial network 40004 receives terrestrial-related data from the terrestrial headend 40001 based on the terrestrial channel and provides the set-top box 40008.
  • the broadcast signal transmission apparatus may remove the burden of considering different OS environments for each terminal device in order to provide an OTT service. That is, the apparatus for receiving broadcast signals does not need to separately provide an OTT application.
  • the broadcast signal receiving apparatus may include an industry standard based ecosystem.
  • the broadcast signal receiving apparatus provides a common service interface, thereby providing an effect of extending a form of service access.
  • FIG. 5 illustrates a structure in which a broadcast signal receiving apparatus receives data according to embodiments of the present invention.
  • the broadcast signal receiving apparatus receives a broadcast signal.
  • the TS packet filter 50001 processes a TS packet included in the broadcast signal.
  • the TS packet may mean an MPEG-2 Transport Stream packet.
  • the PES parser 50002 processes the stream included in the TS packet.
  • the stream may mean a packetized elementary stream.
  • the stream may comprise a video stream.
  • the PES parser 50003 processes the stream included in the TS packet.
  • the stream may mean a packetized elementary stream, and the stream may include an audio stream.
  • the data parser 50004 processes data contained in the TS packet.
  • the data may include content related to a broadcast program or an event related to an application.
  • the signaling parser 50005 processes the signaling data included in the TS packet.
  • the signaling data may include a BU (Bouquet Association Table), a network information table (NIT), an event information table (EIT), a service description table (SDT), an identification channel table (ICT), and the like.
  • the signaling parser 50005 may include a BAT parser, an EIT parser, an NIT parser, an SDT parser, an ICT parser, and the like.
  • the video decoder 50006 decodes video data included in the TS packet.
  • the audio decoder 50007 decodes audio data included in the TS packet.
  • the controller 50008 controls synchronization of the decoded video data and the decoded audio data.
  • the controller 50009 controls events for data other than video data and audio data.
  • the controller 50009 may receive signaling data from the signaling parser 50005 and control an event based on the signaling data.
  • the service initialization server 50010 may obtain uniform resource identifier (URI) information for service discovery from the signaling data of the signaling parser 50005.
  • the signaling data includes service bootstrap information for service scanning.
  • the signaling parser 50005 may provide the service discovery information URI to the server 50010 based on the specific table information among the service bootstrap information.
  • Method A of FIG. 5 illustrates a process in which a broadcast signal receiving apparatus obtains an ICT based on a service discovery URI of an NIT among signaling data according to embodiments of the present invention.
  • the apparatus for receiving broadcast signals may obtain ICT information from a server based on service discovery URI information of NIT.
  • the ICT parser of the signaling parser 50005 processes the ICT information obtained from the server.
  • the broadcast signal receiving apparatus may obtain ICT information through a linear channel.
  • Method B of FIG. 5 illustrates a process of obtaining and processing ICT information from signaling data received through a linear channel by the apparatus for receiving broadcast signals according to embodiments of the present invention.
  • the EPG server 50011 may provide service guide information based on the ICT information of the ICT parser to the EPG generator 50012.
  • the DASH server 50012 may provide bootstrap information for the DASH (dynamic adaptive streaming over HTTP) data to the multicast internal server 50013 based on the ICT information.
  • DASH dynamic adaptive streaming over HTTP
  • the DASH client 50014 receives DASH data from the multicast internal server 50013.
  • the DASH client 50014 parses MPD (media presentation description) information included in the DASH data, parses a file included in the DASH data, decodes the video data included in the DASH data, and audio data included in the DASH data. Decode
  • MPD media presentation description
  • the EPG generator 50012 may receive EPG related signaling data from the signaling parser 5005 and receive EPG data from the EPG server 50011 to generate EPG data to be displayed.
  • the render 50015 may receive synchronized video / audio data from the controller 50008 and receive and render DASH video / audio data from the DASH client 50014.
  • Display 50016 may display rendered data and EPG data.
  • the broadcast signal receiving apparatus provides a service discovery method for providing an IP service in which an existing T / S / C channel and an IP channel are integrated.
  • Standalone Linear IP service refers to a service that can provide integrated service guides of existing T / S / C channels and IP channels.
  • the broadcast signal receiving apparatus may receive service bootstrap information for service scanning of an IP channel.
  • the apparatus for receiving broadcast signals may obtain a service operator URI from a specific table or a specific description among service bootstrap information of a T / S / C channel.
  • a service operator can provide service discovery information.
  • the broadcast signal receiving apparatus may obtain the service discovery information URI from a specific table or a specific description among the service bootstrap information of the T / S / C channel (see method A of FIG. 5).
  • the broadcast signal receiving apparatus may obtain a service discovery information file URI transmitted to a non real-time carousel in the same manner as the service bootstrap information of the T / S / C channel.
  • the broadcast signal receiving apparatus may obtain the service discovery information URI based on a specific table or a specific description of the service bootstrap information in CICAM.
  • the broadcast signal receiving apparatus may perform service discovery using hardwired linkage URI information.
  • Hardwired linkage URI can provide hardwired URI through agreement between provider and CE.
  • the broadcast signal receiving apparatus may obtain service discovery information through the URI.
  • the broadcast signal transmission apparatus and the broadcast signal reception apparatus integrate and provide a service guide of an existing channel, information corresponding to service guide information of an existing channel may be used.
  • the broadcast signal receiving apparatus may obtain unique identification information of a service guide on the structure shown in FIG. 5.
  • the TS packet filter 50001 filters TS packets to distinguish service discovery information and audio / video data.
  • the signaling parser 50005 parses service discovery information included in the received broadcast signal and builds service guide data in the DB.
  • the broadcast signal transmitting apparatus and the broadcast signal receiving apparatus may follow the MPEG-2 system based DVB standard.
  • DVB system information according to the DVB standard may be a table or description such as the above-described network information table (NIT), boutt association table (BAT), service description table (SDT), or event information table (EIT). Including information, the broadcast signal transmitting apparatus and the broadcast signal receiving apparatus may perform service discovery using this table and generate EPG information.
  • NIT network information table
  • BAT boutt association table
  • SDT service description table
  • EIT event information table
  • the process of acquiring the service discovery information may be performed based on the NIT, which is a table signaling the receivable networks.
  • the NIT includes service discovery information of the network.
  • the broadcast signal receiving apparatus may obtain an ICT by parsing an NIT (A of FIG. 5) or an ICT channel through a linear channel (B of FIG. 5).
  • NIT network information table
  • the network information section of FIG. 6 means NIT.
  • the information contained in the NIT may follow the definition of the DVB standard.
  • the table identification information table_id may identify the NIT.
  • the section syntax indicator section_syntax_indicator is a 1-bit field and may be set to a value of 1.
  • the section syntax indicator includes information indicating the syntax that identifies the NIT.
  • section length represents the number of bytes in the section.
  • Network identification information may be used to identify the delivery system, and represents a unique identification of the bit stream received via the network.
  • the delivery system refers to the concept of a physical unit that carries a transport stream.
  • the version number (version_number) represents the version number of the sub-table.
  • the current next indicator indicates whether the sub-table is a currently applicable substable.
  • the section number (section_number) represents the number of the section.
  • the last section number last_section_number represents the number of last sections.
  • the network descriptor length (network_descriptors_length) represents the number of byte lengths of the network descriptor.
  • transport_stream_loop_length represents the total number of byte lengths of the TS loop.
  • the transport stream ID transport_strem_id is information used for identification of the TS.
  • the original network ID (original_network_id) is information for identifying network identification information of the original delivery system.
  • the apparatus for receiving broadcast signals distinguishes networks currently being received, for example terrestrial, cable, and satellite channels, based on NIT.
  • the broadcast signal receiving apparatus defines unique identification of bit streams being received in a corresponding network through an original network ID and a transport ID.
  • TSID is a unique ID for identifying TS multiplexed in the current delivery system.
  • the apparatus for transmitting broadcast signals may separately use the actual NIT table for the main stream for the S channel, the T channel, and the C channel currently being received, and the NIT table for the other network.
  • service discovery of the Internet linear channel is possible in a table for other networks in addition to the NIT for the existing main stream.
  • a network ID may be used to distinguish a network.
  • the apparatus for transmitting broadcast signals according to embodiments of the present invention may extend and use a network ID to identify an internet linear channel which is another network.
  • the broadcast signal receiving apparatus extends the network ID included in the NIT of FIG. 6 to use the service discovery URI information to perform service discovery on the Internet lead channel as in the method A of FIG. Can be.
  • the broadcast signal transmission apparatus may transmit an XML file or a binary code in a carousel manner through a broadcast network.
  • the apparatus for receiving broadcast signals may obtain an ICT table through the broadcast network as in the method B of FIG. 5.
  • the NIT may further include a descriptor through a lower loop.
  • the descriptor included in the NIT may include information regarding a service or a service list, and a detailed configuration of the descriptor will be described below.
  • the NIT may be referred to as first signaling information, second signaling information, or the like.
  • the broadcast signal transmission apparatus may bundle a service to generate a service bundle called a bouquet.
  • BAT contains signaling information for the service bundle.
  • various service scenarios may be configured by grouping a plurality of streams / services transmitted from other networks. That is, as shown in FIG. 7, the apparatus for transmitting broadcast signals may bundle services in bouquet units regardless of the reception network and bundle the received TSs and services.
  • the broadcast signal receiving apparatus receives signaling information through a bouquet association section table (BAT) to signal grouped services.
  • BAT bouquet association section table
  • the table ID (table_id) represents information for identifying BAT.
  • section_syntax_indicator indicates information indicating syntax signaling in BAT.
  • the bouquet ID (bouquet_id) represents information for identifying a service bundle.
  • the version number (version_number) represents the version number of the sub-table.
  • the current next indicator indicates whether the sub-table is a currently applicable substable.
  • the section number (section_number) represents the number of the section.
  • the last section number last_section_number represents the number of last sections.
  • the bouquet descriptor length indicates the total number of byte lengths of the bouquet described in the BAT.
  • the transport stream loop length transport_strem_loop_length represents the total number of byte lengths of the TS loop.
  • the transport stream ID (transport_stream_id) represents information for identifying the TS from another multiplex in the delivery system.
  • the original network ID (original_network_id) indicates information for identifying a network ID of the original delivery system.
  • the apparatus for transmitting broadcast signals provides the services of the Internet linear channel as well as the existing main stream or linear channel based on the bouquet ID, the transport stream ID and / or the original network ID included in the BAT. Bundled bouquets can be described and discovered.
  • the bouquet ID may identify the bouquet including the service of the Internet channel.
  • the transport stream ID may identify a transport stream including a service of an internet channel.
  • the original network ID may mean a network ID of an original delivery system and may indicate a network for service of an internet channel.
  • the broadcast signal receiving apparatus may discover a service of an internet channel by parsing a BAT.
  • BAT may further include a descriptor through a lower loop.
  • the descriptor included in the BAT may include information regarding a service or a list of services, and the detailed configuration of the descriptor is described below.
  • BAT may be referred to as first signaling information, second signaling information, or the like.
  • SDT service description table
  • the broadcast signal transmitting apparatus may transmit a broadcast signal including the SDT
  • the broadcast signal receiving apparatus may receive a broadcast signal including the SDT.
  • the table ID (table_id) represents information for identifying the SDT.
  • section_syntax_indicator indicates information indicating syntax signaling in the SDT.
  • the transport stream ID (transport_stream_id) indicates information for identifying a transport stream described by the SDT in the delivery system.
  • the version number (version_number) represents the version number of the sub-table.
  • the current next indicator indicates whether the sub-table is a currently applicable substable.
  • the section number (section_number) represents the number of the section.
  • the last section number last_section_number represents the number of last sections.
  • the original network ID (original_network_id) indicates information for identifying a network ID of the original delivery system.
  • the service ID represents information for identifying a service in the transport stream.
  • the EIT schedule flag indicates whether event information table (EIT) schedule information for a service currently exists in the TS.
  • the EIT present following flag indicates whether EIT present following information for a service currently exists in the TS.
  • Running status indicates the status of the service.
  • the state of the service may include running, starting in a few seconds, pausing, service off-air, and the like.
  • the free state mode indicates whether all component streams of a service are scrambled.
  • the free state mode represents a mode of controlling one or more streams controlled by a CA (conditional access system), which is a system for controlling subscribers accessing a service.
  • CA condition access system
  • the SDT is a table that defines a network that is currently being transmitted, and defines a service description of data transmitted in the TS. Similar to the NIT described above, the SDT may describe a plurality of services based on the TSID and the original network ID.
  • the broadcast signal transmission apparatus may distinguish one service based on an original network ID, a transport stream ID, and / or a service ID. There is no duplicate service ID on the network identified by the original network ID, and the service ID has a unique value. Also, the original network ID typically has the same value as the network ID.
  • the apparatus for transmitting broadcast signals and the apparatus for receiving broadcast signals according to embodiments of the present invention may include service description and service discovery for the Internet channel using information included in a table used for service description and service discovery in an existing linear channel. Can be further extended to define. Accordingly, the apparatus for receiving broadcast signals according to embodiments of the present invention provides an effect of providing a service of an Internet channel to a user while providing backward compatibility with an existing linear channel.
  • the broadcast signal receiving apparatus may provide a user with an EPG in which an existing linear channel and an internet channel are integrated.
  • the broadcast signal transmission apparatus may transmit a broadcast signal including a new table.
  • the ICT table shown in FIG. 5 may include service guide information for a service received on an actual network.
  • the EPG generator 50012 of the broadcast signal receiving apparatus receives ICT information and provides one channel service guide to the user in the form of an integrated EPG.
  • the broadcast signal transmission apparatus may transmit broadcast data including signaling data including signaling information and AV data other than signaling data through a network.
  • the apparatus for transmitting broadcast signals may classify and process signaling data and broadcast data based on the component type.
  • the data parser 50004 of the apparatus for receiving broadcast signals parses Internet data and synchronization data (e.g. MPEG TEMI) transmitted for synchronization in addition to AV data. Accordingly, the apparatus for receiving broadcast signals may provide an event linkage service for an actual channel in accordance with the timing of transmission at a constant rate.
  • synchronization data e.g. MPEG TEMI
  • the ICT may include information about media data to be received in an actual internet channel.
  • ICT contains an MPD URI.
  • the broadcast signal receiving apparatus may obtain an MPD capable of receiving content based on the MPD URI of the ICT.
  • the DASH server has a role of receiving content (content origin). Accordingly, dynamic allocation of multicast and / or unicast servers according to network conditions on the DASH server 50012 may be performed through the MPD URI.
  • the MPD includes a multicast service address having a CDN role close to the client, and the broadcast signal receiving apparatus may receive a service of a unicast / multicast adaptive type.
  • DASH client 50014 receives and decodes A / V DASH segments via MPD. Further, the DASH client 50014 renders media data 50015 and plays on the display 50016, like a linear channel.
  • the SDT may be referred to as first signaling information, second signaling information, or the like.
  • FIG 9 illustrates a process of parsing signaling information by the apparatus for receiving broadcast signals according to embodiments of the present invention.
  • the broadcast signal receiving apparatus may use unique identification information necessary for integrating a service guide for an existing channel as described above.
  • the broadcast signal receiving apparatus according to the embodiments of the present invention may parse identification information on a service guide as follows.
  • the TS demultiplexer 90001 may parse signaling information from the TS included in the broadcast signal.
  • the TS demultiplexer may correspond to the TS packet filter 50001.
  • the TS demultiplexer 90001 may identify a packet based on a packet identifier (PID).
  • PID packet identifier
  • the broadcast signal receiving apparatus parses the PAT.
  • PAT includes identification information (network_PID) for the network.
  • the broadcast signal receiving apparatus parses the NIT.
  • the NIT includes identification information for the NIT table, identification information for the network, identification information for the transport stream, and identification information for the original network.
  • the broadcast signal receiving apparatus parses the NIT.
  • the identification information (table_id) for the NIT table may include information about a main or actual network, and may include information about another network.
  • the broadcast signal receiving apparatus receives the PAT in response to the case where the PID value of the TS packet header is 0x00.
  • the broadcast signal receiving apparatus receives network_PID in response to the PID value 0x01.
  • the table_id of the NIT is 0x40
  • the NIT includes information about the main network
  • the table_id of the NIT is 0x41
  • the NIT includes information about another network.
  • the NIT 9003 for the main network includes an NID (network_id), a TSID (transport_stream_id), and an ONID (original_network_id), and the broadcast signal receiving apparatus is currently based on the NID (network_id), TSID (transport_stream_id), and ONID (original_network_id). You can identify the stream you receive.
  • the broadcast signal transmission apparatus may transmit a TS packet including information 9204 about the NIT in order to bootstrap the service of the Internet channel.
  • the NIT 9204 for the Arthur network may include a network_id, and the network_id may indicate an internet linear channel.
  • the NIT 9204 includes an ONID (original_network_id) and a TSID (transport_stream_id), and the broadcast signal receiving apparatus may uniquely identify a service based on the ONID and the TSID.
  • the data for the Internet channel does not include the TSID. Therefore, information (unique_id) that can replace the TSID is required for data on the Internet channel.
  • the unique identification information of the TSID may be replaced by URI_linkage_descriptor 90005 and 90008.
  • URI_linkage_descriptor contains URI address information. Since each operator has a different URI string, you can replace the TSID with that URIstring.
  • the broadcast signal receiving apparatus may receive discovery information including ICT channel information and MPD URI information capable of receiving an actual DASH segment based on the URI address information. The detailed configuration of the URI_linkage_descriptor will be described in detail with reference to FIG.
  • the broadcast signal receiving apparatus may receive service discovery information for acquiring a linear Internet channel based on broadband and / or broadcast.
  • the descriptor when the acquisition path is broadband is URI_linkage_descriptor 90005
  • the descriptor when the acquisition path is broadcast is URI_linkage_descriptor 90005.
  • the URI_linkage_descriptor 90005 includes private data 90006. A detailed configuration of the broadband-based private data 90006 will be described with reference to FIG. 13.
  • URI_linkage_descriptor 90008 includes private data 90009.
  • the detailed configuration of the broadcast-based private data 90009 will be described with reference to FIG.
  • the apparatus for transmitting broadcast signals may transmit information (service_list_descriptor) for a service or a service list based on broadband or broadcast as sub-configuration information of the NIT 9204.
  • the service list information based on the broadband is service_list_descriptor 90007
  • the service list information based on the broadcast is service_list_descriptor 90010.
  • the service list information 90007 and 90010 provides unique identification information about a service such as a service ID and a service type.
  • the broadcast signal receiving apparatus parses the BAT 90011.
  • the BAT 90011 includes information identifying a bouquet which is a service bundle (bouquet_id), and includes TSID (transport_stream_id) and ONID (original_network_id) which are service description information for a broadcast channel.
  • the broadcast signal transmission apparatus may additionally provide information that can replace the TSID for the linear channel in order to provide a service description for the Internet linear channel.
  • the BAT 90011 may further include a descriptor 90012 for a service discovery URI and a service list descriptor 90013 as sub configuration information. The detailed configuration of the descriptor 9202 and the service list descriptor 9303 will be described with reference to FIG.
  • the broadcast signal receiving apparatus parses the SDT 90014.
  • the specific configuration of the SDT 90014 has been described in FIG.
  • the broadcast signal transmitting apparatus and the broadcast signal receiving apparatus may transmit and receive broadcast signals using various networks.
  • the network may include an S channel, a T channel, and a C channel, and may further include an internet channel.
  • the NIT which is signaling information about the network, includes network_id, and the broadcast signal transmission apparatus may allocate an internet channel to the network_id together with the S channel, the T channel, and the C channel.
  • URI_linkage_descriptor shows the configuration of a URI descriptor (URI_linkage_descriptor).
  • the URI descriptor includes type (uri_linkage_type) information.
  • the broadcast signal transmission apparatus may newly assign a value for service discovery information for an internet channel to type information. The detailed configuration of the type information will be described with reference to FIG.
  • the URI descriptor contains private data.
  • a detailed configuration of private data according to the case where the service discovery acquisition path is broadband or broadcast will be described with reference to FIGS. 13 and 14, respectively.
  • uri_linkage_type a configuration of URI linkage type (uri_linkage_type) information.
  • the URI connection type information of FIG. 12 includes service discovery information for obtaining a linear internet channel.
  • the path through which the broadcast signal receiving apparatus obtains the linear Internet channel includes broadband and / or broadcast.
  • the type of the uri connection information indicates an online SDT (OSDT) for CI Plus. If the value of the uri_linkage_type is 0x01, the type of the uri link information indicates DVB-IPTV SD & S. If the value of the uri_linkage_type is 0x02, the type of the uri link information indicates a material resolution server (MRS) for a companion screen application. If the value of linkage_type is 0x60, the type of uri linkage information indicates an HbbTV operation application.
  • OSDT online SDT
  • MVS material resolution server
  • the broadcast signal transmission apparatus may further define uri_linkage_type.
  • the type of the uri connection information indicates service discovery information for the linear internet channel on the broadband network.
  • the value of the uri_linkage_type is 0x62
  • the type of the uri connection information indicates service discovery information for a linear internet channel on the broadcast network. Therefore, when the value of uri_linkage_type is 0x61, the broadcast signal receiving apparatus obtains service discovery information through the Internet.
  • the broadcast signal receiving apparatus selects the currently received T channel, S channel and / or C channel. The service discovery information can be obtained while being compatible with the DVB SI information.
  • Fig. 13 shows the configuration of private data.
  • the information contained in the private data 90006 transmitted through broadband will be described below.
  • the destination IP address indicates a service discovery IP address.
  • the destination port represents a port number.
  • the service provider ID represents a provider that provides a service.
  • the network operator ID indicates a network operator that provides a service.
  • Instance_TSID indicates a temporary TSID value that replaces the TSID.
  • the broadcast signal transmission apparatus may add URL information for service discovery instead of the destination IP address to the private data 90006.
  • the URL information may correspond to the IP information because the URL information is converted into a string to become a URL.
  • the apparatus for transmitting broadcast signals may add URL information for service discovery instead of the destination port to the private data 90006.
  • the broadcast signal transmission apparatus may include the private data 90006 in the URI_linkage_descriptor 90005 and transmit it based on the broadband.
  • the broadcast signal transmission apparatus may replace Destination_IP_address, Destination_Port, Service_provider_id, Network_operator_id, and Instance_TSID included in the private data 90006 with URI information for service discovery on the Internet linear channel.
  • the broadcast signal receiving apparatus may provide an integrated EPG for a broadcast channel including an internet channel, and perform service discovery for the internet channel using URI information of the URI_linkage_descriptor 90005.
  • the info type indicates whether the service discovery information received by the broadcast signal receiving apparatus is in XML format or binary.
  • the packet identification ID (ICT_PID) indicates the PID of the TS packet including the service discovery table information.
  • the table ID (ICT_table_id) represents an ID of a table capable of identifying the service discovery table.
  • the service discovery URI (Service_discovery_URI) indicates a file URI when the info type is an XML file.
  • the instance TSID represents a temporary TSID replacing the TSID.
  • the broadcast signal receiving apparatus receives an NIT for another network, and parses the URI _linkage_descriptor included in the NIT based on a broadband or broadcast.
  • the broadcast signal reception apparatus obtains a service discovery URI further extended instead of the TSID through private data included in each URI_linkage_descriptor.
  • the lower loop of the NIT 9204 and / or the BAT 90011 may include a service list descriptor or a service_descriptor 90007, 90010, and 90013. It may include.
  • the service list descriptor (service_list_descriptor) or service descriptor (service_descriptor) 90007, 90010, 90013 includes a stream unique ID (stream_unique_id) and a service ID (service_id).
  • BAT90011 collects streams and services in the current receiver regardless of the network and signals them to a service bundle called a bouquet as described above in FIG. 7.
  • the BAT 90011 may provide signaling for logical bundles at the network and transport levels based on the bouquet ID boutiquet, ONID original_network_id, and TSID transport_stream_id.
  • the internet linear channel cannot include the TSID, signaling for the internet linear channel level is required.
  • the broadcast signal transmission apparatus may include private data in the URI_linkage_descriptor 90008 based on the broadcast and transmit it.
  • the apparatus for transmitting a broadcast signal transmits an info type (Info_type), a packet identification ID (ICT_PID), a table ID (ICT_table_id), a table ID (ICT_table_id), a service discovery URI (Service_discovery_URI), and / or an instance TSID (instance_TSID) to an internet linear channel. It can be replaced with URI information for service discovery.
  • the broadcast signal reception apparatus may provide an integrated EPG for a broadcast channel including an internet channel, and perform service discovery for the internet channel using URI information of the URI_linkage_descriptor 90008.
  • the broadcast signal transmission apparatus may add unique information replacing the TSID to the uri_linkage_descriptor or define a descriptor additionally to the BAT as described above.
  • the BAT may include IP_channle_ID_descriptor. The configuration of the IP_channel_ID_descriptor will be described in detail with reference to FIG.
  • IP_channel_ID_descriptor IP_channel_ID_descriptor
  • IP_channel_ID_descriptor 90012 includes unique information about the network and the stream.
  • URI_linkage_descritor 90005 and 90008 also contain unique information about the network and the stream.
  • descriptor tag (descriptor_tag) and descriptor length (descriptor_length) identify the descriptor and indicate the length of the descriptor.
  • the service provider ID represents information for identifying a service provider for an IP channel.
  • the network operator ID represents information for identifying a network operator.
  • IP number represents a number for the IP channel.
  • the port number (Port_number) represents a port number for the IP channel.
  • IP_channel_ID_descriptor 90012 includes a service discovery URI (service_discovery_URI) for service discovery for the Internet linear channel.
  • IP channel ID descriptor (90012) includes an instance TSID (instance_TSID) to replace the TSID.
  • the instance TSID (instance_TSID) may have a value of a temporary TSID replacing the TSID.
  • the service list descriptor 9303 is information for identifying a service for the Internet linear channel, and includes a service ID (service_id) and a service type (service_type) for the service of the Internet linear channel.
  • the apparatus for receiving broadcast signals parses the ONID (original_network_id) of the BAT90011 to identify the network, parses the IP channel ID descriptor (IP_channel_ID_descriptor, 90012), and acquires the service of the Internet linear channel based on the service discovery URI information. can do. Furthermore, the apparatus for receiving broadcast signals may obtain a service ID and a service type based on the service list descriptor 9303.
  • the apparatus for transmitting broadcast signals may include an IP number, a port number, a network operator ID, and a service provider ID (service_provider_ID) included in an IP channel ID descriptor (IP_channel_ID_descriptor, 90012). ) Can be further extended to include URI information for discovering services for Internet linear channels.
  • the broadcast signal reception apparatus may receive the integrated EPG based on the IP channel ID descriptor (IP12_ID_descriptor) 90012 and obtain URI information.
  • the broadcast signal transmission apparatus may configure a service bundle for each logical ID unit to signal service discovery.
  • FIG. 16 illustrates a process of service discovery based on a bouquet.
  • the broadcast signal receiving apparatus may signal a service bundle based on the bouquet identification information.
  • Bouquet 1 (bouquet 1, 16001) and bouquet 2 (bouquet 2, 16005) may be identified based on the bouquet ID (bouquet_id).
  • the bouquet 1 may include a plurality of service bundles (service bundles 16002, 16003, 16003).
  • Bouquet 2 may include a service bundle (16006, 16007, 16008) a plurality of service bundles.
  • the service bundle may be represented by ONID (original_network_id).
  • the service for the T channel, the S channel, and the C channel among various networks may be represented through a TSID (transport_stream_id) (16003 and 16007).
  • a service for an internet linear channel among various networks it may be expressed based on a URI (16002, 16004, 16006, 16008).
  • service bundle 16002 may be service discovered based on URI A.
  • the service bundle 16008 may be service discovered based on URI C.
  • the URI information of FIG. 16 may include an IP number (IP_number), a port number (Port_number), a service provider ID (Service_provider_ID), a network operator ID (Network_operator_id), and / or an instance. Can be replaced by the TSID (instance_TSID).
  • the apparatus for receiving broadcast signals can implement an IP base TV (IP based TV) service that can provide the same user experience as the terrestrial, satellite, and cable linear channels.
  • the broadcast signal receiving apparatus may provide a channel guide integrated with terrestrial, satellite, and cable channels through open internet based native code reception, not an application based linear channel service. Can be.
  • the apparatus for receiving broadcast signals can perform Internet channel scanning, which can provide the same user experience as the existing linear service channel, and is based on MPEG-2 system / DVB SI. You can perform service initialization.
  • the broadcast signal reception apparatus includes signaling information including network, stream, and service unique signaling for internet stream identification. This can be provided via a description, description, or table.
  • the apparatus for transmitting broadcast signals provides a signaling method capable of replacing TSID while maintaining compatibility with TSID information in system information without additionally defining new information.
  • the broadcast signal transmission apparatus extends a service bootstrap method of an existing linear channel network to provide a linear IP based TV service.
  • Unique additional information to be defined for such a linear IP based TV service identification has been described in FIG. Accordingly, the user may be provided with IP based TV channel information added to the existing linear channel EPG.
  • the broadcast signal receiving apparatus may access a service through a UI in which an existing linear service and an OTT service are integrated in a device supporting an RF-based DVB receiver (tuner).
  • the broadcast signal receiving apparatus may support a media service that provides the same UX as existing linear channels through the open Internet without an STB.
  • the traditional IP-based linear channel service is given authentication through a subscription to a specific operator, for example, an ISP or a network operator, and the broadcast signal reception apparatus Receives the IP linear service through the STB provided by the provider.
  • a specific operator for example, an ISP or a network operator
  • the broadcast signal reception apparatus Receives the IP linear service through the STB provided by the provider.
  • STB-less type IP linear service For example, representative standard technologies include ATSC 3.0, IBB, and HbbTV, and clients can receive various linear rich-media services by running an application on an OS platform inside the TV.
  • Various operators provide their own service applications to be installed on the TV platform, and the applications define APIs that enable request / receive and servers that can provide data for services.
  • the client can access the application through the TV UI and receive various services through the application.
  • the broadcast signal receiving apparatus may provide the above-described various services to a user.
  • the broadcast signal receiving apparatus may provide not only a linear TV but also an OTT channel.
  • the OTT market increases the need for essential media applications for IP-based devices.
  • proprietary platforms and OTT's own service ecosystem are increasing the form of proprietary services.
  • unique types of app-ecosystem consumption such as codec, protocol stack, application, and browser provided by each OTT are increasing.
  • the broadcast signal receiving apparatus solves such problems as the proprietary platform of the OTTs, the dependence on the operation of the application, and the like.
  • the broadcast signal reception apparatus which is not in the form of providing UX similar to the linear channel services such as T channel, S channel, and C channel that must execute an application, discovers the service at the receiver native level, and has a client accessible server.
  • the apparatus for receiving broadcast signals integrates OTT's proprietary platform into one unified TV native platform, and eliminates the burden of the user running the OTT application and receives and provides OTT contents in a channel. Suggest how to.
  • the broadcast signal transmission apparatus may provide an IP-based multicast service.
  • the broadcast signal transmission apparatus may provide an adaptive multicast media service using a DASH protocol.
  • a broadcast signal transmission method and a broadcast signal reception method according to embodiments of the present invention for an adaptive bit rate (ABR) multicast service are shown in FIG.
  • the encoder 17001 may compress the content based on the transmission range.
  • the packager 17002 may be included in a container in a format capable of transmitting an access unit (AU) for data in which content is compressed.
  • AU access unit
  • the origin server 17003 represents a server that stores original files for content distribution.
  • CDN cache (CDN cache) 17004 represents a server that stores data in each distributed server to efficiently deliver content.
  • the broadcast signal transceiving device may use the CDN cache 17004 when retransmission of content for a missing packet during multicast.
  • the MABR sender (MABR sender, Multicast Adaptive Bit Rate, 17005) transmits multicast metadata information and services to the home gateway and / or STB based on the content transmitted from the server 17003.
  • the MABR proxy 17006 represents a temporary server for performing HTTP communication with the ABR client 17009. Based on the MABR proxy (17006), DASH clients and proxies can consume services in the form of Unicast services.
  • the network multicast controller 17007 transmits overall control information necessary for providing a multicast ABR service to the home gateway. For example, for slow RAP of multicast, control information can be sent to the home gateway to enable unicast and multicast switching.
  • the host resolve 17008 processes connection information for providing unicast / multicast services.
  • host resolve (17008) can connect MPD url and proxy server through a module acting as a DNS server.
  • ABR client 17009 represents a client that consumes ABR service.
  • the STB 17010 represents a set top box and includes a MABR proxy, a MABR client, and a host resolver for a server for communication.
  • the network multicast controller 17007 transmits control information for transmission to the MABR sender 17005 and receives control information for transmission from the MABR sender 17005. Can be.
  • the controller 17007 may transmit control information about the reception to the MABR proxy 17006 and receive control information about the reception from the MABR proxy 17006.
  • the MABR sender 17005 may transmit multicast metadata and service data to the MABR proxy 17006 and the STB 17010 based on the IP multicast scheme.
  • the CDN cache 17004 may transmit the content related information stored in the server to the MABR proxy 17006 and the STB 17010 based on the IP unicast scheme of HTTP. Communication between the MABR proxy 17006 and the ABR client 17009 may be performed by a unicast scheme. Communication between the host resolve 17008 and the ABR client 17009 may be performed based on DNS.
  • the broadcast signal transmitting apparatus and the broadcast signal receiving apparatus may process data based on the protocol of FIG. 18.
  • the IPTV protocol may be classified into IP protocols & transports and middleware & functions.
  • the service may include a multicast service delivered to a specific number in real time, a unicast service according to a user's request, non-real-time content download and firmware upgrade, and service initialization information transmitted in a carousel form to receive a service. have.
  • the multicast service may represent A.V, SI., PSI, etc. as a structure of the UDP / IP / M2TS protocol.
  • Unicast service may represent a request and response structure based on HTTP.
  • the non-real-time service may represent a service related to downloading multicast content based on FLUTE and a service related to downloading firmware update information.
  • the DVBSTP service may indicate a service related to a protocol for transmitting service discovery information and a service related to a protocol for transmitting broadband content guide information.
  • An apparatus for transmitting broadcast signals has an object of extending and providing IPTV service initialization information to which a DASH protocol is applied to provide an ABR service of an IPTV. That is, by providing additional information for the broadcast signal transmitting apparatus to access the DASH service, the broadcast signal receiving apparatus provides an adaptive streaming service for the multicast real-time service, enabling seamless content consumption without buffering. Provide effect.
  • the broadcast signal receiving apparatus discovers a service provider available at a reference time point.
  • the broadcast signal receiving apparatus receives service discovery entry point information through a structure of DHCP to bootstrap service discovery. Thereafter, the broadcast signal reception apparatus may receive service discovery information for providing an IPTV service by selecting an appropriate service provider among the received SP entry points.
  • the broadcast signal transmitting apparatus and the broadcast signal receiving apparatus may signal a service through the service information of FIG. 20, and a specific configuration of each service information may be expressed according to the DVB-SI standard.
  • the broadcast signal receiving apparatus may receive a service discovery entry by performing IP service initialization through a DHCP service.
  • DHCP Dynamic Host Configuration Protocol
  • HNED Home Network End device
  • HNED defines DNS_domain information and sends it to DHCP through option 15 among DHCP methods.
  • Option 15 may be additionally defined in User Class Options of RFC 3315. The detailed configuration of the User Class Option will be described with reference to FIG.
  • the option information field of DHCP may additionally include domain information.
  • the format of the DHCP will be described in detail with reference to FIG.
  • the apparatus for receiving broadcast signals proceeds with an essential configuration procedure for receiving an IP address and IPTV service of a terminal.
  • the HNED receives RR (Receiver Report) as return information.
  • the RR receives a list of possible networks and services.
  • the HNED receives a list of possible networks and services based on the RR. For example, a service entry corresponding to SD & S1_domainname_IP_SD & S1 through SD & Sn_domainname_IP_SD & Sn is received.
  • the HNED sends request information to DHCP.
  • the request information has a form of HTTP GET and includes a domain name.
  • DHCP sends service provider discovery information to the HNED.
  • the HNED sends request information (HTTP GET) including the domain and hostname to DHCP.
  • request information HTTP GET
  • DHCP sends broadcast discovery information to the HNED. The detailed procedure will be further described with reference to Figs. 22 and 23.
  • Fig. 22 shows the configuration of the user class option.
  • the user class option represents information that the client uses to identify the type or category of the user or application.
  • Use class options may follow the specifications of RFC3315.
  • the option code may indicate option 15, where the option length indicates the length of the user class data field, and the user class data indicates the user classes carried by the client.
  • HNED transmits DNS domain information based on user class option 15 when sending an IP request to DHCP.
  • Figure 23 shows the format of DHCP.
  • the option field of DHCP includes domain information. HNED forwards to DHCP in option 15 by including domain information in the option field of DHCP.
  • the HNED selects an entry among the entries of the service being received to perform service discovery and selection (SD & S).
  • the HNED may obtain domain and IP information for the service through step (1).
  • the HNED performs a procedure for obtaining service provider discovery information. That is, HNED can create XML based on IP and domain information, and can request each service provider information from DHCP at the service level by using HTTP GET. For example, HNED may create XML targeting SD & S1_domainname_IP_SD & S1 and request as follows.
  • the HNED returns an instance from the SD & S server (Service discovery & selection) in response to the HTTP GET request from DHCP.
  • An instance represents an instance that can receive service provider discovery info.
  • HNED can collect all the service providers (SPs) of the service based on the instance.
  • Figure 24 shows a service provider discovery information record.
  • FIG. 24 illustrates embodiments of service provider discovery information described above with reference to FIG. Referring to the schema of FIG. 24, a service may be obtained through two routes to SP1 and SP2.
  • Fig. 25 shows the configuration of data for the service discovery and selection server according to the payload ID value.
  • the payload is an access capable of receiving an instance capable of receiving UDP segments having broadcast discovery information info. Contains the address.
  • service provider discovery information may also be defined as XML composed of two types.
  • ⁇ ServiceProviderType> it includes the configuration of the name, description, and offering of a service provider.
  • Fig. 26 shows the structure of the offering list type information.
  • the offering element includes an offering base and an offering list type as a lower element.
  • the offering element may include location information according to a transmission mode.
  • the HNED may obtain a domain or IP address capable of receiving service specific information of each SP through the service provider discovery information of FIG. 24.
  • the service provider discovery information record of FIG. 24 may describe the bundle of SPs. Therefore, the SP can be described flexibly.
  • FIG. 27 illustrates a schema structure of service provider discovery information.
  • FIG. 27 includes information related to attributes of respective SPs according to a service provider type. Specific elements are as follows.
  • a service provider represents a description of a service provider.
  • Name represents the textual name of the service provider.
  • a description represents a textual description of the service.
  • the Offering represents the delivery method.
  • the offering may provide respective location or IP access information for a push or pull type of service. That is, the apparatus for receiving broadcast signals may receive information through the classification of payloadID as shown in FIG. 25, and obtain an address for receiving XML for receiving information of broadcast discovery information.
  • Fig. 28 shows the configuration of the offering list type.
  • the HNED can describe metadata in push / pull mode according to a delivery method.
  • the metadata may include specific location related information according to a method.
  • the metadata may include payload ID, segment # related information, and location information for receiving service specific information in PayloadList.
  • the metadata in push mode, may include an address of broadcast discovery information capable of receiving a multicast service based on the DVBSTP transport mode type.
  • 29 illustrates the push mode and pull mode for the offering element.
  • the offering element which is a child element of the service provider type, may include other metadata in push mode and pull mode as shown in FIG. 29.
  • the apparatus for transmitting and receiving broadcast signals initializes an ABR service based on adaptive multicast and service provider discovery information records on IP, and accesses broadcast information provided by each SP. Provide information for
  • the push mode of the offering can include an additional AdaptiveStreamingModeType. Based on the AdaptiveStreamingModeType, you can define information accessible to the service.
  • the adaptive multicast mode type indicates a higher unit required to define an ABR multicast service.
  • the adaptive multicast address includes information for acquiring broadcast information related to the ABR multicast service of each SP.
  • the IP address includes access server IP information necessary for obtaining broadcast information.
  • the port number includes access port information necessary for obtaining broadcast information.
  • Delivery format indicates protocol information for encapsulating a file or TS format for ABR multicast.
  • protocol information may mean protocol information such as ROUTE, FLUTE, QUIC, RTP, TS, and the like.
  • the HNED may transmit an HTTP GET request through the XML consisting of the domain of the SP, information to be received (payloadID), and segment #.
  • the HNED may receive specific information of the IP media service corresponding to each service. For example, an HTTP GET request might look like this:
  • Figure 31 illustrates an embodiment of service provider discovery.
  • the service provider discovery information includes the name and offering for the service provider and includes information according to the delivery method of the offering. If the mode of the offering is a push, the push includes adaptive multicast address information and includes a segment ID according to the payload ID. If the mode of the offering is full, the location information includes the segment ID according to the payload ID.
  • the HTTP GET request information of step 5 is received from the server in the form of XML in a return form.
  • XML is an embodiment of broadcast discovery information for SP1.
  • the broadcast discovery information record described above with reference to FIG. 24 is configured in the form of a schema of broadcast offering.
  • the broadcast offering includes initialization information in an element structure as shown in FIG.
  • the broadcast offering provides information for specific broadcast discovery at each service provider level, and specific fields are as follows.
  • the service list includes specific information of IP services provided from the SP and may indicate location information for accessing the IP services.
  • the single service includes specific information about a single IP service and may indicate location information for accessing the single IP service.
  • the service location indicates the location where the service (service) can be found. For example, it may represent a domain, a URL, an IP address, and the like.
  • the DVBTriplet may include three types of information, OriginNetwork_ID, TSID, and serviceID, in the DVB SI.
  • SI represents service information. SI information can be delivered in full or optional SI can be delivered. In the case of optional SI, it must be defined as mandatory.
  • the broadcast offering includes a service list for the IP service list.
  • the IP service list includes a single service corresponding to the IP service.
  • IP services may include service locations, textual identifiers, DVBTriplets, and the like.
  • the IP service provides information for service discovery based on the service location information.
  • lower elements of the IP service illustrated in FIG. 34 correspond to information for single broadcast discovery.
  • the IP service is a child element and includes a service location (ServiceLocation).
  • the service location may include child elements as follows.
  • the broadcast system type indicates a broadcast system such as DVB-C, S, T, ATSC, and ISDB.
  • the IP Multicast Address represents a multicast transport address or a parameter capable of accessing IP multicast.
  • RTSPURL represents the URL to access the RTP streaming service.
  • the broadcast signal transmission and reception apparatus may provide service initialization for the multicast ABR service.
  • service initialization for this service, information and a reception algorithm that can receive an MPD manifest file defined by DASH are described below.
  • the service location may provide ID_multicast_ABR information in the manner of a broadcast system among lower elements.
  • the service location may add the value of ID_multicast_ABR in the manner of broadcast system.
  • the value of ID_multicast_ABR may indicate identification information of a transmission method of a broadcast service. Although the string of ID_multicast_ABR can be changed, the meaning of the identification information of a broadcast service to which ABR technology is applied in the existing multicast method is maintained.
  • a URL or IP information for accessing the IPmulticastABR_address service may be further proposed along with the IP multicast address and the RTSPURL.
  • the URL or IP information for accessing the IPmulticastABR_address service may be used as access information for obtaining an MPD required by the DASH service.
  • additional information for the service may be added. Detailed information of the information that can access the IPmulticastABR_address service will be described with reference to FIG. 36.
  • the service location may include an IP multicast address, an RTSURL, and an IPmulcastABR_address together with a broadcast system.
  • IPmulcastABR_address contains MABRType.
  • MABRType can contain the following elements:
  • FastStartUp includes information for first performing a unicast connection for fast channel change before receiving an IPTV multicast packet. During certain periods of time, unicast packets or low-quality data can be rendered quickly, giving the IPTV the ability to play back data without delay in AV playback.
  • FastStartUp includes accessing information including an IP address.
  • FastStartUp may further include an advertisement of a network operator or an advertisement of a content provider.
  • FastStartUp includes delivery options, and delivery options include streaming and storage media. When the delivery option is streaming, streaming includes address information (startUP_address) and port information (startUP_port), which are access information for fast start. If the delivery option is storage media, the storage media includes information (contentUrl) for content acquisition.
  • the broadcast signal receiving apparatus may receive a faster service in the service and broadcast service discovery phase based on the fast startup information.
  • the delivery option represents a media option when implementing fast startup.
  • Delivery options include storage media that launches AV through pre-downloaded stored files and information about downloading files for fast startup via streaming.
  • the startup address (Startup_IP_address) indicates unicast access IP address information for fast AV playback when the service starts.
  • the startup port address (Startup_port_address) indicates unicast connection port (Port) information for fast AV playback when the service starts.
  • StorageMedia represents a mode of executing a file downloaded in advance before ABR multicast during a delivery option.
  • the content URL represents file url information stored in storage or cache for fast startup.
  • the MABR address represents IP address information that can access an ABR multicast service.
  • the broadcast signal receiving apparatus may consume a service by accessing a location capable of acquiring multicast based on a MABR address after performing FCC or fast AV access through unicast for a predetermined period of time.
  • the MABR address may indicate IP information for acquiring the MPD.
  • the MABR port (MABR_port) represents a port number for receiving ABR multicast service.
  • the maximum bandwidth indicates a bit rate that can be transmitted and reflected by a transmission / reception network condition or a service provider.
  • Maxbandwidth represents the maximum bit rate that can be received in the current transport channel.
  • the maximum bandwidth shows how much data is received per channel packet. The maximum bandwidth can be used to construct a fast object with reference to the buffering of the media data.
  • the delivery mode may be linked with baseURL information of the MPD. According to the delivery mode, baseURL information of the MPD may be used.
  • Delivery modes include unicast services, real-time multicast services, non-real-time multicast services, and the like.
  • Unicast service includes a base pattern.
  • the base pattern of the unicast service has a string type and includes a base URL (@baseURL).
  • Real-time multicast services include a base pattern.
  • the bait pattern has a string type and includes a base URL (@baseURL).
  • Non-real-time multicast services include a base pattern.
  • the bait pattern has a string type and includes a base URL (@baseURL).
  • the broadcast signal receiving apparatus may obtain a service according to each delivery mode based on a base URL (@baseURL).
  • the apparatus for transmitting and receiving broadcast signals requires Url information capable of receiving an MPD from the information of broadcast discovery information in a service initialization step. Do.
  • the broadcast signal reception apparatus receives the MPD and consumes the ABR service. Since there is no identification information on the delivery method on the MPD, an arbitrary string may be included in the MPD. That is, the information of the bit stream may be described through a representation in the MPD, and the URL of which segment is received or which URL should be requested may be defined through the segment URL. .
  • FIG. 37 is an embodiment in which segment naming is defined using a base URL as one of the embodiments of the MPD.
  • the base URL of the upper layer is a string prefixing the segment address.
  • a string in which each representation is uniquely defined may be provided.
  • the base url can be used to define delivery methods.
  • MPD does not have a way to define broadcast, multicast, and unicast. If you define a pattern of base URL and define a pattern of url according to a specific method, MPD can identify delivery method. .
  • the definition of the url pattern may be provided included in the IPTV service initialization information.
  • the apparatus for transmitting and receiving broadcast signals according to the embodiments of the present invention may define url information as shown in FIG. 38 to FIG. 39 based on the above-described broadcast discovery information schema or service discovery information. Through this information, the broadcast signal receiving apparatus can grasp the delivery method, and provide an ABR service by applying a framework having a buffer-model corresponding to the delivery method.
  • 38 illustrates a service discovery configuration for a single service.
  • the service discovery information includes a domain name and a list of services for the domain name.
  • the service list may include sub-configuration information for a single service in the service list as shown in FIG.
  • Single services include service locations, textual identifiers, and DVBTriplets.
  • the service location includes IPMulticastABR_address.
  • IPMulticastABR_address contains the MABR address, MABR port number, maximum lease width, and service status for the MABR.
  • the service location also includes information for fast startup. Fast startup includes delivery options and may include streaming information depending on the delivery options.
  • the streaming information includes a startup address, a startup port address, a MABR address, and MABR port information.
  • the service location includes a delivery mode.
  • the delivery mode may represent ABR multicast video as a base pattern.
  • the broadcast signal receiving apparatus may obtain and consume ABR multicast video.
  • the MPD contains a base URL for ABR multicast video.
  • the adaptation set of the MPD includes content protection, information related to the representation by representation identifier, and a base URL.
  • the broadcast signal receiving apparatus may provide an ABR service based on a base URL.
  • FIG. 40 shows a configuration for providing a service incorporating an Internet channel.
  • the structure diagram of FIG. 40 corresponds to the structure diagram described above in FIG.
  • the apparatus for receiving broadcast signals provides a channel guide integrated with terrestrial, satellite, and cable channels through open internet based native code reception.
  • the European Broadcasting Standard DVB based on the MPEG-2 system describes service discovery methods and EPG information using DVB system information.
  • the DVB SI includes information of tables such as a network information table (NIT), a buoyt association table (BAT), a service description table (SDT), and an event information table (EIT).
  • NIT network information table
  • BAT buoyt association table
  • SDT service description table
  • EIT event information table
  • the NIT includes information for service discovery of the network.
  • the main channel network including the T channel, the S channel, and the C channel provides a path for receiving Internet service discovery information.
  • the service discovery process uses this path.
  • the service discovery information includes an MPD manifest access address capable of receiving an MPEG-DASH segment and information for supporting a protocol for transmitting the segment.
  • Fig. 41 shows the configuration of the integrated channel guide UI.
  • the broadcast signal receiving apparatus may provide the UI / UX to the user by displaying the integrated EPS as shown in FIG. 41.
  • EPG information 41001 may be displayed on the screen of the main device. EPG information 41001 may also be displayed on the screen of the second device. The EPG information 41001 may be displayed in some areas on the screen. The EPG information 41001 may overlap and be displayed on the display area for the service data that the user is watching. The EPG information 41001 may be displayed in an area different from the display area for the service data that the user is watching.
  • the EPG information 41001 may be displayed based on the channel information 40202 and the time information 4003.
  • the channel information 40020 includes the T channel, the S channel, and the C channel, as well as the Internet channel 41040.
  • the channel information 40202 may provide integrated channel information.
  • the channel information 40202 may provide the user with the number of the integrated channel based on the logical channel number. The user can linearly recognize a plurality of integrated channels.
  • the time information 41003 includes the time for the information displayed in the EPG information 41001.
  • the time information 41003 includes all of the current time, past time, and future time.
  • the time information 41003 may display a time for the content, and display information on the current time in UI / UX.
  • Program information 40205 indicates a program included in channel 40202.
  • the program information 40005 may be displayed based on the time information 4003.
  • the program information 40005 may further include information related to a program.
  • the program information 41005 may include information about the application 41006 related to the program.
  • the program information 40005 may include information about a bouquet related to the program 41007.
  • the broadcast signal receiving apparatus may identify a program based on time and channel based on the ESG information, and may inform that the application is executable for each program or may inform that there is a bouquet for each program.
  • FIG. 42 illustrates a method in which a broadcast signal receiving apparatus uses one UI / UX by integrating an Internet dedicated channel and an existing TV channel based on the ESG of FIG. 41.
  • the channel guide information or ESG 41001 may display the internet channel and the terrestrial channel together.
  • the ESG 41001 may indicate a channel reception path.
  • both the terrestrial channel and the Internet channel may include channel 52.
  • the ESG 41001 may display different colors of text or different text forms according to a path of a reception channel.
  • the connected TV may receive an advanced application service while the corresponding program is in progress.
  • the broadcast signal receiving apparatus may display that the advanced application service exists using the EPG information 41001.
  • the application may provide product advertisements associated with the program through additional data during program viewing.
  • the application may provide a function of moving to an interlocking channel.
  • the application may provide rich media, such as preview or replay.
  • the EPG information 41001 may provide a scalable interworking service through information called a bouquet between channels or select a program that provides audio of another language.
  • the user may receive various media services regardless of the channel received via the integrated EPG guide 41001.
  • Display 4201 of FIG. 42 includes a channel number and a path 42002 of the channel.
  • Display 4201 displays 52 programs for the Internet channel.
  • Display 4201 displays information 42003 indicating that an application related to a program can be executed.
  • Display 42002 of FIG. 42 includes a channel number and a path 42005 of the channel.
  • Display 42002 displays 52 programs for the terrestrial channel.
  • Display 42002 includes information 42006 indicating that it may move to channel 56 for the Internet channel.
  • the broadcast signal transmission / reception apparatus may display the DVB channel 42005 using the logical channel number 52, and use the same logical channel number 52 as the Internet channel or the I channel 42002. Can be displayed at the same time.
  • the embodiment of displaying the DVB channel and the I channel may be differently provided to the user according to a specific condition of the service, for example, a country, a region, a user's selection, or a user's preference.
  • 43 shows a network structure for adaptive media streaming.
  • the apparatus for transmitting and receiving broadcast signals supports adaptive media streaming on an IP-based multicast network.
  • Supported networks are as follows.
  • the network includes a content network, an ABR multicast network, a user network, and the like.
  • Each network may further include additional networks to support other functions than adaptive media streaming.
  • the content network is a network for generating, collecting, and storing content, and includes an encoder, a packager, and a content server.
  • An ABR multicast network is a network for transmitting a multicast stream over an IP network and includes a multicast sender, a multicast receiver, and a network multicast controller.
  • the user network is a network for decoding and playing the received multicast stream, and includes a gateway and a decoder device (player).
  • 45 shows the configuration of a content network for broadcasting.
  • the content network 45001 may mainly be responsible for generating, collecting, and packaging content for adaptive multicast streaming.
  • the content network may include various content sources.
  • the content network may include a head-end 45002 of a broadcaster that services terrestrial and cable broadcasting, etc., to service broadcast content.
  • the content network may include a satellite reception network for receiving services that are geographically separated.
  • the content network may include a content server 45003 to service pre-stored content, and may include a CDN for serving media.
  • the content network may generate and transmit a signaling message, a control message, and the like related to the content.
  • a signaling message may be exchanged between the various nodes belonging to the network for proper interaction with the content, signaling, control messages, etc., and may not be transferred to other networks.
  • Such signaling and control messages may be referred to as internal network signaling.
  • the content network may include the head-end of the broadcast.
  • the content generated by the broadcaster may be delivered to the multicast sender 45006 through encoding (45004) and packaging (45005) and multicasted, or may be stored in the content server 45003 and transmitted to the multicast sender if necessary.
  • Encoder 45004 encodes the content.
  • the packager 45005 may convert encoded content and data into a format suitable for multicast transmission, and generate signaling that can be received by a receiver or a device belonging to a network when necessary.
  • the media segment generated by the packager may be directly transmitted to the multicast sender 4506 and multicasted, but the segment is stored in the content server when the segment does not need to be delivered immediately.
  • the broadcaster's head-end 45002 may store media data and associated signaling, and may include a content server 45003 for this purpose.
  • Content server (45003) may utilize a multicast during storage and require third-party content (3 rd party content). In the case of stored content, a separate encoding process may not be necessary. Accordingly, the content server 45003 may store media segments and files that have been encoded or packaged, and may transmit them when requested. According to embodiments, only encoding may be performed, and a packaging process may be required according to the type of network to be transmitted.
  • the operator controller 45008 manages the content production 45007, the content server 45003, and the like, and appropriately manages and controls a series of processes related to multicasting. Control and signaling data can be collected for multiple devices and nodes in the content network and forwarded to the multicast network as needed to enable multicast-related signaling and control.
  • the operation controller 45008 may receive and process unicast information transmitted from an eye decoder device or a player, and may use the multicast.
  • Fig. 46 shows the configuration of a content network for broadcasting of satellites.
  • the broadcaster's head-end 46601 which services terrestrial and cable broadcasts, may include a satellite reception network for receiving services that are geographically separated.
  • the satellite transmitter may also be the head-end of another broadcaster, in which case it may be a network to which the head-ends of a plurality of broadcasters are connected.
  • the content received through the satellite system is transmitted to the multicast sender through encoding and packaging, which can be multicasted, or stored in a content server and delivered to the multicast sender if necessary.
  • An encoder 46002 encodes the content.
  • the encoder 46602 may be connected to a satellite transmitter for relaying broadcast data to a satellite.
  • the broadcast signal transmission / reception apparatus may use a satellite transmission / reception system (eg, overseas sports, concert relay, news, etc.) as shown in FIG. 46 for live broadcasting to a remotely located place.
  • a satellite transmission protocol and transmission scheme may be used.
  • Data passed through the satellite transmission and reception system is delivered to the packager.
  • the packager 46003 may convert content and data received through a satellite receiver into a format suitable for multicast transmission, and generate signaling that can be received by a receiver or a device belonging to a network when necessary.
  • the media segment generated by the packager 46003 may be directly transmitted to the multicast sender and multicasted, but may be stored in the content server when the segment does not need to be delivered immediately.
  • the content server 46004 sends data to the multicast sender immediately when the live broadcaster broadcasts to a remote location.
  • the broadcaster's head-end is used for media data and media for later use.
  • the related signaling may be stored, and a content server may be included for this purpose. Therefore, the content server can store media segments and files that have been encoded or packaged, and transmit them when requested. According to embodiments, only encoded data may be stored, and a packaging process may be required according to the type of network to be transmitted.
  • the operator controller 46005 manages content production, content servers, and the like, and appropriately manages and controls a series of processes related to multicasting. Control and signaling data can be collected for multiple devices and nodes in the content network and delivered to the multicast network as needed to enable multicast related signaling and control. In addition, the operator controller 4605 may receive and process unicast information transmitted from the decoder device or the player and use the multicast.
  • the broadcast signal transmission and reception apparatus may consider an OTT-based content network mainly serving video content using an IP network.
  • the OTT may be connected to the CDN for efficient use of network resources.
  • the contents of the OTT are stored in the content server through encoding and packaging, and thus, the contents held by the OTT can be directly delivered to the multicast sender and multicasted, or the CDN can be delivered to the multicast sender.
  • the encoder 47001 performs encoding of the content.
  • OTT provides a live service or produces content to be stored in a content server.
  • the packager 47002 may convert encoded content and data into a format suitable for multicast transmission, and generate signaling that can be received by a receiver or a device belonging to a network when necessary.
  • the media segment generated by the packager can be directly delivered to the multicast sender and multicasted. However, in case of data that the segment does not need to be delivered immediately, it is stored in the content server.
  • the content server 47003 may store media data to be serviced by the OTT and signaling related thereto.
  • Media data stored in the content server may be 3rd party content, and may be used for multicast if necessary.
  • the content server can store the media segments and files that have been encoded or packaged, and transmit them upon request. According to embodiments, only encoding may be performed, and a packaging process may be required according to the type of network to be transmitted.
  • the operator controller 47004 appropriately manages and controls a series of processes related to multicasting and unicast data transmission of the content server 47703.
  • the operator controller can collect control and signaling data for multiple devices and nodes in the content network and forward them to the multicast network as needed to enable multicast related signaling and control.
  • the operator controller can receive and process unicast information delivered from a decoder device or player and use it for multicast.
  • Operator controllers can be connected to OTT and CDN as separate controllers and can communicate with each other.
  • FIG. 48 shows a configuration of an ABR multicast network for a cable network.
  • the broadcast signal transmission and reception apparatus may use an ABR multicast network.
  • the ABR multicast network is a network that multicasts the content delivered from the content network on an actual IP network.
  • the IP network includes a managed network and an unmanaged network where QoS is managed by a network provider and unauthorized traffic is restricted.
  • IP network is irrelevant to connection method such as wired and wireless.
  • the IP network connected to the content network and the IP network connected to the user network may be different, and the connection protocol between the ISP (Internet Service Provider) providing each network may be different. Can follow.
  • the sender and receiver are transparent for the multicast content. That is, the output data of the sender is the same as the input of the receiver even though it passes through various ISP networks and nodes on the network.
  • the multicast network is a network for transmitting and receiving an actual multicast stream, and may include a multicast sender (server), a multicast receiver (client), and a multicast network controller regardless of the characteristics of the transmitted network. Depending on the location or connection status of the sender and receiver of the network for multicast, it may traverse several networks. In addition, you can use a separate protocol for the path on the network.
  • Multicast streams can generally be delivered over wired IP networks.
  • Multicast senders and receivers can use networks provided by Internet Service Providers (ISPs).
  • ISPs Internet Service Providers
  • the management entity of the multicast sender, receiver, controller, and IP network may be determined according to the access protocol.
  • the multicast sender 48001 transmits content data to each multicast receiver.
  • Packaged contents are received from a content network and transmitted to a plurality of multicast receivers using a multicast protocol.
  • the multicast receiver 48002 receives the content data transmitted by the multicast sender and delivers it to a decoder device capable of playing it.
  • the content data can be cached for efficient play of the decoder device.
  • the multicast receiver may be configured in the same apparatus together with the decoder device.
  • the multicast receiver can receive the multicast stream via a gateway of the user network or the like. In this case, the multicast receiver may be a component of the user network.
  • the multicast network controller 48003 controls the ABR multicast network.
  • the multicast network controller 48003 controls content delivery and related session information of the multicast sender 48001 and manages and delivers signaling information about configuration for each sender and receiver.
  • the multicast network controller 48003 may be configured with a separate protocol from the multicast content and may be connected to each sender and receiver. In order to simplify the connection between the sender and the receiver, signaling information connected to only the sender and transmitted to the receiver may follow the content multicasting protocol.
  • the network cache 48004 refers to a node or a device that performs a network cache function between a multicast sender and a receiver in an IP network.
  • the network cache 48004 stores an appropriate range of contents for efficient use of network resources, and delivers a stream to the receiver.
  • an update procedure may be performed on the multicast sender and the cached content.
  • 49 shows a configuration of an ABR multicast network for a mobile network.
  • the broadcast signal transmission and reception apparatus may use a mobile access network.
  • Multicast streams are typically delivered over a wired IP network, but mobile receivers may additionally use a mobile access network.
  • the mobile access network uses a network that supports IP transport.
  • a mobile network may also support multicast to service a multicast stream to a plurality of mobile receivers.
  • the multicast sender 49001 transmits content data to each multicast receiver.
  • the multicast sender 49001 receives packaged contents from a content network and transmits a plurality of multicasts to a receiver using a multicast protocol.
  • the multicast receiver 49002 receives the content data transmitted by the multicast sender 49001 and delivers it to a decoder device that can play it.
  • the multicast receiver 49002 connected to the mobile access network may receive a radio signal for that mobile access network.
  • Multicast receivers connected to the mobile access network may be connected to the decoder device via another wireless access standard. In this process, the decoder device can catch the content data to enable efficient play.
  • the multicast receiver may be configured in the same apparatus together with the decoder device.
  • the multicast network controller 49003 controls the ABR multicast network.
  • the multicast network controller 49003 controls content transmission and related session information of the multicast sender, and manages and delivers signaling information for configuring each sender and receiver.
  • the multicast network controller 49003 is configured with a separate protocol from the multicast content and can be connected to each sender and receiver. In order to simplify connection between the sender and the receiver, signaling information connected to only the sender and transmitted to the receiver may follow a content multicasting protocol.
  • a multicast controller may be included in the IP network and the mobile access network, respectively, and transmission and reception of control and signaling information for the corresponding network is possible. Communication between multicast controllers can be performed using separate protocols for each multicast controller.
  • the network cache 49004 may include a node or a device that functions as a network cache between the multicast sender and the receiver.
  • the network cache may be configured anywhere in each network and may be configured as a plurality of caches.
  • some nodes of each network may simultaneously act as caches.
  • an update procedure may be performed on the multicast sender and the captured content.
  • 50 shows the configuration of a user network for a home network.
  • a user network may be referred to as a network between devices that receive data over a multicast network and consume content for it.
  • the user network may be variously configured, and the multicast receiver may be part of the user network in some cases.
  • ABR multicast receivers can be configured as part of the user network.
  • the multicast content may be received through a device serving as a gateway or proxy of the user network. In this case, the gateway or proxy may be considered part of the ABR multicast network.
  • the multicast receiver may have the role of another server or sender in the user network.
  • multicast content can be consumed by various decoder devices of the user network, and multicast streaming can be performed even when the decoder device cannot receive the multicast content.
  • the receiver can receive the data transmitted by multicast directly, but if the device belonging to the home network plays the role of the receiver, it can receive the multicast data through the home gateway.
  • the home gateway 50001 may receive data from an ABR multicast network when multiple devices are configured in the home network.
  • the Home GW 50001 may process data transmission and reception with an external network, and simultaneously perform the role of a proxy.
  • multicast receivers can cache data to be received.
  • the multicast receiver 50002 may be a component of the ABR multicast network described above, but may be located inside the home network due to the configuration of the network. Depending on the configuration of the home network, the multicast receiver can act as a proxy. In the case of a multicast receiver that cannot directly play a multicast stream, a decoder device that plays the stream may be additionally connected, and may be connected to a plurality of decoder devices to transmit the multicast stream.
  • the decoder device 50003 may be defined as a device that plays a multicast stream to a user. Multiple decoder devices can connect to a multicast receiver and can send and receive data in unicast or multicast.
  • the decoder device 50003 may be connected to a unicast network separately from a network receiving a multicast stream, and may transmit a request or a report to a content network or an ABR multicast network.
  • the decoding module and the screen may be configured as separate devices. It can also be configured with the same device as the multicast receiver.
  • 51 shows a network structure for adaptive media streaming.
  • Fig. 51 shows an example of the entire network structure for adaptive media streaming.
  • a node or an entity for a broadcast signal transmitting and receiving device may have a logical configuration, and each node may be configured as a separate device. According to embodiments, it may be configured to operate in a device such as an adjacent node.
  • a plurality of networks may be connected to each other and signaling and management information may be exchanged with each other for efficient multicast streaming.
  • 52 illustrates a protocol for adaptive media streaming.
  • the protocol can be broadly classified into a media protocol through which actual media is transmitted, and a signaling protocol for controlling configuration of each node or entity for transmitting media, or for transmitting configuration information about media to various nodes and entities including a receiver.
  • signaling and control information is transmitted using a signaling protocol, but when a receiver receives media content through a single connection, a separate signaling path is not configured. Thus, in this case it can be delivered via the media protocol.
  • 52 is a protocol for adaptive media streaming according to embodiments of the present invention.
  • 52 illustrates a conceptual protocol for delivering media content. This is the case when the multicast receiver is composed of the same devices and modules as the decoder (media player).
  • This protocol can deliver media content created in a content network or stored in a server to a user's decoder device and multicast to deliver it to multiple users.
  • a protocol on a node or an entity may mainly use a protocol that delivers data to the next node more efficiently and in real time than media transmission.
  • a protocol may be referred to as a tunneling protocol. Therefore, tunneling protocol can be defined between server and multicast sender as shown in the figure. At this time, the media content is delivered as a payload of the tunneling protocol, but the tunneling protocol itself may operate regardless of the format of the media content.
  • a protocol that supports adaptive streaming to a multicast receiver can be defined, and the corresponding adaptive streaming can be supported by an IP multicast scheme to be delivered to multiple multicast receivers.
  • IP multicast can also be defined as a combination of TCP / IP and UDP / IP.
  • the multicast receiver When the multicast receiver serves as both a decoder and a player, the multicast receiver receives IP multicast packets to obtain adaptive streaming data, and decodes and plays data corresponding to the media content format from the data.
  • 53 illustrates a protocol for adaptive media streaming.
  • FIG. 53 shows an example of a protocol for delivering media content. This is the case when the multicast receiver and decoder (media player) are composed of separate devices or modules. Media content generated in a content network or stored in a server is intended to be delivered to a user's decoder device via a multicast receiver, and may be transmitted in multicast for delivery to a plurality of multicast receivers or users.
  • a protocol for delivering the generated content to a node or entity (multicast sender in the figure) that performs multicast transmission, and a protocol for multicasting and transmitting the corresponding content in an adaptive streaming format can be defined.
  • content data passes through multiple nodes or entities, and an appropriate protocol is required between each node and entity.
  • a protocol on a node or an entity may mainly use a protocol that delivers data to the next node more efficiently and in real time than media transmission.
  • Such a protocol may be referred to as a tunneling protocol. Therefore, tunneling protocol can be defined between server and multicast sender as shown in the figure. At this time, the media content is delivered as a payload of the tunneling protocol, but the tunneling protocol itself may operate regardless of the format of the media content.
  • IP multicast In the multicast sender, it is possible to define a protocol supporting adaptive streaming in a multicast receiver, and the adaptive streaming can be supported by an IP multicast scheme to be delivered to multiple multicast receivers.
  • IP multicast can also be defined as a combination of TCP / IP and UDP / IP.
  • the multicast receiver may receive IP multicast packets to obtain adaptive streaming data and deliver them to the decoder again.
  • an IP unicast protocol may be defined between the multicast receiver and the decoder.
  • the content data received by the multicast receiver is delivered to the decoder again through IP unicast, and the decoder decodes and plays data corresponding to the received media content format.
  • FIG. 54 illustrates a protocol for signaling and control for the multicast sender on FIG. 52.
  • FIG. 55 shows a protocol for signaling and control for the multicast receiver and decoder on FIG.
  • a control protocol may be defined between an operator controller included in a content network and a network controller included in a multicast network.
  • the network controller can also send a response or report message for the control message to the operator controller to generate the appropriate control and management messages.
  • the tunneling protocol for sending control messages can be configured in both directions.
  • a single operator controller can send and receive control messages to and from multiple multicast controllers.
  • each multicast network controller can be managed by a separate operator.
  • configuration information of the network may be transmitted to the multicast sender and the multicast receiver.
  • the network controller may include configuration information on network resources, mapping information between nodes of the network, routing information, and the like.
  • the configuration information received from the operator controller can be transmitted to the multicast sender or multicast receiver. In this process, the protocol transmitted from the multicast controller to the multicast sender and the protocol transmitted to the multicast receiver may be distinguished.
  • IP multicast may be configured to deliver configuration messages from a single network controller to multiple multicast senders and multicast receivers. Connections, statistical information, and the like collected from the multicast sender and the multicast receiver may be reported to the multicast network controller.
  • This process can be configured as a unicast protocol because each multicast sender and multicast receiver can be performed independently. This set of controls, configuration information, etc. can be updated dynamically and sent immediately or through scheduling.
  • the multicast receiver may define a signaling protocol for sending the received adaptive streaming data back to the decoder device.
  • an IP unicast protocol may be defined.
  • the IP unicast protocol can be used to deliver signaling for the request of the decoder device.
  • it can be defined as a bidirectional protocol between a multicast receiver and a decoder device.
  • FIG. 56 shows a protocol for signaling and control on FIG.
  • Fig. 56 shows a case where the multicast network controller is not directly connected to the multicast receiver but connected via a multicast sender.
  • network configuration information can be delivered to the multicast sender and the multicast receiver.
  • the network controller may include configuration information about network resources, mapping information between nodes of the network, routing information, and the like.
  • configuration information received from the operator controller can be transmitted to a multicast sender or a multicast receiver. In this case, however, since the multicast controller is connected only to the multicast sender and not to the multicast receiver, the multicast sender can forward configuration messages transmitted from the network controller to the multicast receiver.
  • configuration-related protocols (or message sets) may distinguish between protocols transmitted to a multicast sender and protocols transmitted to a multicast receiver.
  • IP multicast may be configured to deliver configuration messages from one network controller to multiple multicast senders and multicast receivers. Connections, statistical information, and the like collected from the multicast sender and the multicast receiver may be reported to the multicast network controller.
  • This process can be configured as a unicast protocol because each multicast sender and multicast receiver can be performed independently. This set of controls, configuration information, etc. can be updated dynamically and sent immediately or through scheduling.
  • Information such as reports sent from the multicast receiver to the multicast network controller can be delivered to the multicast network controller through the multicast sender, and the multicast sender forwards report messages from the multicast receiver to the network controller. Can give The operation of the other protocols is the same as in the case of FIG. 52 described above.
  • 57 shows a protocol stack for IP multicast.
  • 57 shows an example of a protocol for transmitting media data over an IP network.
  • Corresponding protocols and packet formats may be determined for each layer, and each protocol may be configured independently or appropriately combined with specific protocols for interoperability.
  • the encoder compresses the video and audio data, converts it into an appropriate codec, passes it to the packager, and this is mainly done internally by the transmission system.
  • an efficient codec can be used, a video can be used such as HEVC, AVC, etc., audio can be used AAC, AC4, MPEG-H audio codec and the like.
  • Each codec may be packaged in a form suitable for transmission or storage.
  • ISOBMFF, CMAF, and MPEG-2 TS formats can be used. While the content data encoded with the codec is packaged, a DRM may be added to play the corresponding content only to a specific receiver, and an authentication key value used for the DRM may be transmitted through a separate link or channel.
  • the media data configured in the form of a file may be applied with a protocol for directly transmitting a file, such as FLUTE, according to a transmission method.
  • a protocol supporting adaptive streaming such as DASH may be used.
  • the lower layer protocol may be configured according to the configuration of FLUTE or DASH. For example, when DASH is applied, HTTP may be applied as a lower layer protocol, or a DASH segment may be regarded as a file, and FLUTE may be configured as a lower layer protocol.
  • TCP / IP or UDP / IP can be configured according to the configuration of the upper protocol for IP multicast, and IGMP, which can manage the subscription of the IP multicast group in the multicast receiver, can be parallel.
  • Layer2 and Layer1 protocols can be defined according to each transport link. That is, the optimized protocol can be configured according to the link between nodes and entities configured on the network. For example, in a LAN environment, Layer 2 can be defined as Ethernet and Layer 1 as CSMA / CD protocol.
  • 58 shows a media delivery method for IP multicasting.
  • the multicast receiver corresponds to a case where the multicast receiver is composed of the same devices and modules as the decoder (media player).
  • the protocol for content on the server can primarily define the media codec and file format.
  • the media codec may have a video, audio or other encoding format, define a codec such as HEVC or AVC for video, and have a format such as AAC, AC4, MPEG-H audio codec for audio.
  • a protocol for file format a format for transmitting or storing a codec format in a file format can be defined.
  • file formats such as ISOBMFF and CMAF may be used.
  • the file format may be transmitted using the format of MPEG-2 TS.
  • a plurality of formats may be used for streamlining the file format.
  • the protocol between the server and the multicast sender can primarily define a protocol for efficient delivery of file formats. Therefore, the data of the content generated in the server can be delivered using the tunneling protocol.
  • Tunneling protocol can mainly use a real-time transmission protocol such as RTP, and another IP-based tunneling protocol that can be defined in the network. At this time, the existing protocol can be used as it is or the definition of the field can be changed to suit the network.
  • a tunneling protocol may be defined at an input terminal to receive a file transferred from the server using the tunneling protocol. In this case, since the file format transmitted using the tunneling protocol is data to be transmitted to the multicast receiver in the multicast sender, the tunneling protocol may operate regardless of the format for the corresponding data.
  • the protocol between the multicast sender and the multicast receiver can be defined primarily as a protocol for adaptive streaming.
  • a protocol may be composed of a DASH-based protocol.
  • the lower layer protocol is based on IP multicast.
  • a protocol such as HTTP may be configured to operate DASH, and a file transfer protocol such as FLUTE may be configured when the DASH segment is regarded as a file type.
  • TCP / IP can be configured for efficient network connection and multicast transmission of the DASH / HTTP protocol.
  • the multicast receiver may be configured with TCP / IP to receive packet streams transmitted by multicast, and HTTP may be configured for requests for packet streams, responses for received data, and the like.
  • a DASH client can be configured when adaptive streaming using DASH in a multicast sender. Since the data streamed adaptively using DASH is composed of a file format transmitted from a server, a file format related protocol for identifying the file format and a media codec for decoding the identified media format may be configured. .
  • the figure shows a specific embodiment of a protocol according to a path through which media contents are transmitted.
  • the multicast receiver corresponds to a case where a decoder (media player) and a separate device and module are configured. Therefore, the multicast receiver needs to transmit the received multicast stream to the decoder device.
  • the multicast receiver may be configured with TCP / IP to receive a packet stream transmitted through a multicast, and HTTP may be configured for a request for a packet stream and a response for received data.
  • DASH client can be configured.
  • Data that is adaptively streamed using DASH can act as a proxy in a multicast receiver and deliver it back to the decoder device. Since the number of decoder devices connected to the multicast receiver can be limited, the connection can be based on unicast transmissions. Therefore, it can be composed of HTTP and TCP / IP protocol for unicast connection.
  • a unicast protocol for receiving data transmitted from a multicast receiver may be configured. Since the data transmitted through HTTP unicast to the decoder device is composed of a file format transmitted from a server, the corresponding file format can be identified. A media codec capable of decoding a file format related protocol and an identified media format may be configured.
  • 60 shows media delivery for IP multicasting.
  • the protocol scheme for transmitting the DASH segment is shown for the embodiment based on the Quick UDP Internet Connections (QUIC) protocol.
  • QUIC Quick UDP Internet Connections
  • TCP / IP the multicast method using TCP / IP
  • QUIC based protocol is in charge of connection and flow control in QUIC.
  • QUIC can use HTTP / 2, which can improve the transmission delay incurred by the existing HTTP, and can immediately transmit streaming data using UDP / IP.
  • Fig. 61 shows the structure, generation, and parsing sequence of the DASH segment.
  • DASH technology cuts various quality contents into pieces of a certain time unit and stores them in the server, and transmits data units that are cut when media requests from a user device are carried out using the HTTP protocol.
  • the user can receive a seamless adaptive streaming service.
  • the MPD is an XML document in which the truncated segment is given each URL, and an attribute such as when the request should be started and what content is included. Accordingly, the first user of DASH requests an MPD file from the server, and requests a segment file for desired content by recognizing information about the corresponding file stored in the server through the transferred MPD file.
  • Fig. 62 shows the structure of the DASH segment.
  • Fig. 62 is a diagram illustrating a DASH segment structure and generation order.
  • the DASH segment is a data unit of a transport object that divides content to be transmitted into media segments and enables playback for a predetermined duration. Basically, it contains 'styp' box indicating segment type and 'sidx' box containing segment index information. It also contains a 'mdat' box containing the media streams truncated in fragments and a 'moof' box containing metadata about it.
  • the DASH client requests the media segment through each segment url, beginning with the request for the transfer of the MPD file to request the service. To decode media segment, it initializes decoder by parsing initialization segment file including initialization information, and receives the requested segment file and proceeds with media parsing and decoding.
  • the media encoder encodes mdat for the entire play block (MPD + IS + sidx + moof + mdat) and generates a metadata header (styp + sidx + moof) including the encoding information.
  • the IS.mp4 file which is decoder initialization information, is created, and the segment url is created in the MPD and transmitted to the client.
  • the client side receives the MPD file first, parses it, and requests segments based on network conditions.
  • Fig. 63 shows the structure, generation, and parsing order of the DASH segment.
  • the real-time performance of the entire media service framework must be applied. Therefore, seamless service implementation and delay may occur. Can be.
  • a delay may occur during encoding and packetization of real-time content and parsing and decoding of real-time content. In other words, when each file is created and sent through each packetization, there is a delay in waiting for the entire packet to be generated for the reception time and parsing of the packet, and the client takes a long time to buffer.
  • the present invention proposes the following method to solve the above-mentioned problem.
  • the transmitted MPD is a DASH client and unicast, and playback is performed by MPD transmission and segment request according to the conventional conventional model. While running the DASH framework, perform a fast startup on the received packets.
  • the frames of the remaining building blocks can be configured in the following way. Instead of sending the entire frame of the mdat covered by the Moof header, only I frames can be transmitted to reduce the reception delay, and playback starts from I frames, which are random access points (RAPs), to enable fast AV startup.
  • RAPs random access points
  • light MPD is created and transmitted by designating only representation / segment that enables fast startup considering network situation or network operator without making all segments of full quality.
  • the generated light MPD receives and starts playing the fast startup building block immediately. After receiving segments of different quality to proxy, bitstream switching is performed according to the quality of segments.
  • delays can be minimized by only sending and receiving segments considering fast startup, and identifying segments for fast startup even in MPD.
  • the broadcast signal transmission / reception apparatus may implement media content delivery for Fast AV startup through a parsing method as shown in FIG.
  • 64 shows a user network for playback of a DASH segment.
  • the MPD When the client requests DASH content stored in the proxy for service, the MPD does not have this fast startup segment mode. Therefore, when the component is accessed, signaling called segment is needed for quick access.
  • the following describes an MPD that describes DASH content.
  • 65 shows an MPD hierarchical structure.
  • the MPD in FIG. 65 is configured in a hierarchical structure including elements and attributes. Each layer describes structural functions and roles such as elements and attributes that contain information about media content. The description of the video and audio component levels is described from the Adaptation-Set and has one or more Representation entries. Representation assigns URL path of segments and performs bitstream switching.
  • the representation may include a descriptor capable of representing common attributes, and may include a descriptor as shown in FIG. 66. In the common attribute, supplemental property descriptors can be used to define the elements necessary for the framework of the representation in the DASH client. This descriptor type element defines an attribute of what operation to perform with schemeIdUri, and a specific code point for a specific operation may be defined including value attributes.
  • the broadcast signal transmission / reception apparatus may implement a DASH MPD extension for a fast startup segment through an MPD structure.
  • 66 shows a user network for playback of a DASH segment.
  • the present invention intends to define a method for signaling a representation that enables fast startup among representation entries through the extension of a new supplemental property descriptor. A specific signaling method will be described with reference to FIG. 67. FIG.
  • 67 shows a signaling method for fast startup.
  • the MPD includes a schemeIDUri element.
  • the schemeIDUri element represents a URI for the fast startup mode.
  • the MPD contains a value element. value element Indicates segment mode for fast startup mode.
  • the apparatus for transmitting and receiving broadcast signals may propose a method for signaling a fast startup representation among representation entries through extension of a new supplemental property descriptor.
  • the client selects the representation of the appropriate quality according to the DASH model and requests the url of the segment to receive the media.
  • the issue of simultaneous concentration of unicast traffic and guarantee of network bitrate of the best effort network can be efficiently and service-received through a multicast method centering on the proxy server adjacent to the client.
  • 68 is a multicast ABR reference architecture model, and illustrates an ABR service reception model through multicast.
  • the following sequence shows the framework of the latitude plane.
  • Content playback (client) receives manifest through bootstrap, interface B.
  • Client requests media from Y based on information in manifest that contains Y's information (IP address, hostname). 3) Y's information.
  • Y's information IP address, hostname.
  • X the segment file is sent to Y
  • Y starts the service by comparing the manifest file with the actual segment.
  • the representation should be selected. Simultaneous reception with data through multicast can be received as unicast.
  • Manifest defines only one Url that can access a segment, so it is necessary to define an approach based on delivery path.
  • the broadcast signal transmission and reception apparatus may define a delivery path and receive a richmedia service using an alternative network in one MPD using a unicast / multicast network simultaneously.
  • a baseurl can be provided to define a string on which a segment is GETed.
  • 69 shows base url definition according to the Multicast ABR delivery method.
  • 69 is divided into a method defined by the delivery method to baseUrl in the MPD. Manipulate the manifest through the base pattern as shown below, and request the segment based on a string that distinguishes the media segment by path.
  • 70 shows a method of constructing a segment access URL.
  • the broadcast signal transmission / reception apparatus defines an access address as shown in FIG. 70 to download a segment.
  • using multiple base urls determines which base strings are accessible from an alternative perspective. Based on the base string, you can create a full string through a segment template. Based on the configuration shown in Figure 2.17, we create a base string pattern and an address that can access the segment through the base URL and segment template. As shown in FIG. 70, the multicast address of the proxy and the unicast of the richmedia are written in the form of multiple base URLs to allow access according to a network.
  • 71 illustrates a multicast ABR service architecture.
  • a multicast service capable of distributing packet traffic may be simultaneously provided instead of a unicast-only service.
  • a method for distinguishing a delivery method in a manifest file for providing an ABR streaming service is shown in FIG.
  • the baseURL string classification method is presented, but the message to deliver the constraint of this string must be defined in advance.
  • the multicast gateway, the server, and the multicast path string and the unicast path string are delivered in advance.
  • the operation of the Y function can be adaptively handled through the paths of the strings. For example, when the path of a multicast segment url expires or is not available, the content playback module needs to request in the form of round the side and get a new unicast url. This process may cause a service black out issue during live and is a method of causing an increase in latency. Therefore, it is possible to consume adaptive streaming service by defining integrated delivery method in MPD. In the live service, the delivery path may be important because the multicast protocol and the unicast protocol perform different buffer management considering different parsing process and capacity for different reasons.
  • unicast repair service module receives data in the form of Y and unicast request. You can receive lost media segments. At this time, since Y is an operation to receive and process the unicast path through the received MPD, there is a need to distinguish it from segment information of the existing multicast.
  • the multicast network controller defines a unique and distinguished URL pattern of the multicast gateway and server, and a representation in the MPD according to the pattern.
  • a multicast network controller can send a service query or message such as acquisition and initialization of a service to a multicast gateway or server.
  • the string constraint defined in FIG. 68 can be transmitted to control the operation in the multicast gateway.
  • FIG. 72 is a multicast network control message that can be transmitted from a C MR and C MS .
  • Information is defined.
  • the message may be in the format of RESTful HTTP (S).
  • S RESTful HTTP
  • the following access information is not included in a control session in a specific session in the M interface for transmitting multicast media. It is accessible as the IP and port of the session, and the string of the segment URL defined in the media representation can be accessed through the component / adaptation identification information or service entry identification information in the transmitted manifest.
  • the base pattern that distinguishes multicast / unicast service and the base URL in the manifest file can be matched to find out which path the media segment can serve.
  • priority is an optional operation, and priority is given to selecting a path that matches the current network environment in the terminal.
  • a seamless service can be implemented by defining the priority of the multicast / unicast path considering the media segment capacity in the current server and the multicast gateway.
  • a lost packet needs to be received unicast, it can be aligned with the multicast media segment to request a lost packet that matches the current playout time.
  • @serviceId represents a service corresponding to a service entry or an adaptation set of id or MPD id.
  • @servicename represents the name or title of the corresponding service.
  • @servicestatus represents the status of an active or inactive service.
  • @MPDUri represents an updated MPD containing descriptions for the components.
  • the updated MPD may include the location of the alternative adaptation set.
  • @operatoruri represents a globally unique URI that identifies the corresponding service.
  • @originalnetworkid represents identification information of the original network.
  • @AITuri represents the description location for the application trigger.
  • @SIPaddress represents the source IP address of the group multicast session.
  • @dIpAddress represents the destination IP address of the group multicast session.
  • @sport represents the source port of the multicast.
  • @dport represents the destination port of the multicast.
  • the @Mgateway type represents the deployment type of a multicast gateway such as a connected TV, an IP gateway, or an edge server.
  • LS represents a DASH representation delivered on a multicast that includes corresponding media component (s) belonging to the multicast service.
  • @tsi represents the session TSI value of the corresponding service entry or attachment set.
  • DeliverMethod represents a container of transport related information belonging to the contents of a service on multicast and unicast of an access.
  • Multicast_service represents a DASH representation delivered on a multicast that includes corresponding media component (s) belonging to the multicast service.
  • BasePattern represents a characteristic pattern to be used by the multicast ABR receiver to match against the portion of the segment URL used by the DASH client to request the DASH media segment of the parent DASH representation.
  • priority indicates the priority of the DASH representation delivery in consideration of the network and capacity for providing a multicast service.
  • Unicast_service represents a DASH representation delivered on unicast that includes corresponding media component (s) belonging to a unicast service.
  • BastPattern represents a characteristic pattern to be used by the multicast ABR receiver to match against the portion of the segment URL used by the DASH client to request a parent DASH representation.
  • priority indicates the priority of the DASH representation delivery in consideration of the network and capacity for providing a multicast service.
  • the Multicast service is bootstrapping through B and obtains a DASH MPD through B or M.
  • Received MPD basically defines segment information that can receive multicast, but needs property to get additional control information in use case below. The steps are as follows.
  • Step 1 Alternative Unicast data acquisition: During the multicast reception, the error of subscribe may occur, or the situation of seamless service may be difficult due to the surge of traffic. It is necessary to secure the dynamic path of the multicast / unicast path.
  • Step 2 Additional service: In the middle of the multicast service, an additional service may be requested by a user request. For example, if only Korean audio is defined in the multicast MPD, it may be necessary to add a new component with an English representation.
  • Step 3 Ad insertion: When an update of a new advertisement occurs in the middle of a multicast service or when an update of a component is required, update of new information is required.
  • Step 4 Alternate alternative multicast gateway: When a new address is to be received due to the replacement of the current multicast gateway or the change of the connection location, the MPD of the new multicast gateway can be received.
  • Step 5 Providing High-Definition Content: 8K service can be provided through UHD / HD + residual data by utilizing multicast / unicast bandwidth.
  • Multicast gateway defines uri that can receive updated MPD from previously received MPD.
  • @operatoruri represents the unique id of the operator providing the service.
  • @AITuri indicates the location of the description to trigger additional app services in the application or on the linear channel.
  • Multicast gateway means Deployment type. It can be a connected TV, an IP gateway, an edge server, and so on.
  • Service_id, Operatoruri, and originalnetworkID serve as a unique identifier of the service.
  • TSI enables component signaling in the service to be aligned with the adaptation-set in the MPD.
  • AAC Advanced Audio Coding
  • ABR Adaptive Bit Rate
  • CDN Content Delivery Network
  • CMAF Common Media Application Format
  • DASH Dynamic Adaptive Streaming over HTTP
  • HTTP HyperText Transfer Protocol
  • IGMP Internet Group Management Protocol
  • IP Internet Protocol
  • IP ISO Base Media File Format
  • MPEG Moving Picture Experts Group
  • OTT Over The Top
  • QUIC Quick UDP Internet Connection
  • RTP Control Protocol RTP
  • RTP Real-time Transport Protocol
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • the apparatus for transmitting and receiving broadcast signals according to the embodiments of the present invention uses the above-described protocol for adaptive media streaming.
  • the apparatus for transmitting and receiving broadcast signals according to the embodiments of the present invention can shorten the time required for initialization and AV startup when transmitting file-based multicast content in a real-time IP multicast broadcasting environment.
  • the network can be efficiently controlled. Further, control information for such an effect has been described above.
  • Broadcast signal transmission and reception apparatus is a network architecture for IP-based multicast transmission and reception, a structure of a protocol for IP-based multicast transmission and reception, file-based multimedia file segmentation generation and transmission boundary definition in a real-time IP multicast broadcasting environment Real time IP multicast broadcasting environment, delivery frame structure for fast startup, version management method of multicast control information, dynamic allocation of multicast / Unicast, distinction of required constraints and delivery route of MPD, and change of deployment mode of multicast gateway.
  • the apparatus for transmitting and receiving broadcast signals is characterized by extending DASH MPD for fast startup of a real-time IP multicast broadcasting environment, and extending multicast control information for a multicast / unicast dynamic allocation scenario.
  • the apparatus for transmitting and receiving broadcast signals effectively enables multicast transmission between devices belonging to an existing broadcast network, the Internet, a home network, and the like.
  • the network load can be reduced, and the delay of DASH live segment request according to the network situation can be solved when linear service and real time live encoding are performed.
  • it can provide a fast AV startup method in a real time push structure.
  • the apparatus for transmitting and receiving broadcast signals solves a problem of IP multicast real-time broadcasting reflecting the existing DASH scenario, that is, transmitting delay after generating all movie fragments. It provides a structure that sends frame and initialization information with random access point (RAP) to delivery boundary and sends first for fast startup.
  • RAP random access point
  • the apparatus for transmitting and receiving broadcast signals enables a content generation for fast startup with a structure of transmitting a media segment having a low quality, a reception time and a decoding time less first.
  • the broadcast signal transmission and reception apparatus may increase the flexibility of the bandwidth and provide a seamless service to the user through multicast / unicast dynamic allocation.
  • 73 illustrates a broadcast signal transmission method according to embodiments of the present invention.
  • the broadcast signal transmission method generates a packet including service data and signaling information for the service data (S73001), encodes the packet (S73002), and transmits a broadcast signal including the packet. (S73003).
  • Each step of FIG. 73 may be processed according to the components of the broadcast signal transmitting apparatus of FIG.
  • 74 is a view illustrating a broadcast signal receiving method according to embodiments of the present invention.
  • the broadcast signal receiving method receives a broadcast signal (S74001), parsing a packet included in the broadcast signal, and the packet includes service data and signaling information for service data (S74002). In operation S74003, service data and signaling information are decoded. Each step of FIG. 74 is processed by the broadcast signal receiving apparatus of FIG.
  • 75 illustrates a process of a broadcast signal receiving apparatus discovering a service and displaying a service guide according to an embodiment of the present invention.
  • the broadcast signal receiving apparatus parses signaling information about a network or a broadcast channel through the signaling information parsing process illustrated in FIG. 9 (S75001), and applies the signaling information illustrated in FIGS.
  • Signaling information about the Internet linear channel is parsed (S75002), and service data for the Internet linear channel is discovered (S75003).
  • the apparatus for receiving broadcast signals according to embodiments of the present invention displays the integrated service guide information for the broadcast channel including the Internet linear channel as shown in FIGS. 41 to 42 based on the signaling information (S75004).
  • Each step of FIG. 75 may be processed by the broadcast signal receiving apparatus shown in FIGS. 2 and 40.
  • a module or a unit may be processors for executing consecutive processes stored in a memory (or a storage unit). Each step described in the above embodiments may be performed by hardware, software, and processors. Each module / block / unit described in the above embodiments can operate as hardware, software, or processor.
  • the methods proposed by the present invention can be executed as code. This code can be written to a processor readable storage medium and thus read by a processor provided by an apparatus.
  • Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor.
  • Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet.
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention is used in the field of providing a broadcast signal including a series of data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

본 발명의 실시예들에 따른 방송 신호 송신 방법은, 서비스 데이터 및 상기 서비스 데이터를 위한 시그널링 정보를 포함하는 패킷을 생성하는 단계, 상기 패킷을 인코딩하는 단계, 상기 패킷을 포함하는 방송 신호를 전송하는 단계를 포함한다. 나아가, 상기 시그널링 정보는 상기 방송 신호에 대한 네트워크 정보를 포함하고, 상기 네트워크 정보는 메인 네트워크 또는 아더 네트워크에 대한 제1식별 정보를 포함하고, 상기 제1식별 정보가 상기 아더 네트워크를 나타내는 경우, 상기 네트워크 정보는 인터넷 리니어 채널에 대한 제2식별 정보를 포함한다. 또한, 상기 시그널링 정보는 인터넷 리니어 채널에 기반하여 전송되고, 상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 획득하기 위한 서비스 디스커버리 정보를 포함하고, 상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 식별하는 URI(Uniform Resource Identifier)정보를 포함한다.

Description

방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
본 발명은 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치에 관한 것이다.
아날로그 방송 신호 송신이 종료됨에 따라, 디지털 방송 신호를 송수신하기 위한 다양한 기술이 개발되고 있다. 디지털 방송 신호는 아날로그 방송 신호에 비해 더 많은 양의 비디오/오디오 데이터를 포함할 수 있고, 비디오/오디오 데이터뿐만 아니라 다양한 종류의 부가 데이터를 더 포함할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 지상파, 위성, 케이블 리니어 채널과 동일한 유저UX(user UX)를 제공할 수 있는 IP 기반의 TV 서비스를 구현한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 어플리케이션 기반의 리니어 채널 서비스가 아닌, 오픈 인터넷 기반의 네이티브 코드 수신을 통해 지상파, 위성, 케이블 채널과 통합된 채널 가이드 제공한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 지상파(fixed)의 직접수신이 아닌, IP 기반 디바이스들의 OTT, PC등과 IPTV등의 매체들을 통해 방송서비스가 소비되는 상황 및 유니캐스트의 높은 트래픽을 고려하여 실시간/비실시간 미디어 스트리밍 서비스의 심리스(seamless)한 서비스를 제공한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 리니어 IP 어답티브 멀티캐스트 방송환경에서 파일기반 콘텐츠를 전송하기 위한 네트워크 제어 방법 및 정보를 제공한다.
목적 및 이점을 달성하기 위해서, 본 발명의 실시예들에 따른 방송 신호 송신 방법은, 서비스 데이터 및 상기 서비스 데이터를 위한 시그널링 정보를 포함하는 패킷을 생성하는 단계, 상기 패킷을 인코딩하는 단계, 상기 패킷을 포함하는 방송 신호를 전송하는 단계를 포함한다. 나아가, 상기 시그널링 정보는 상기 방송 신호에 대한 네트워크 정보를 포함하고, 상기 네트워크 정보는 메인 네트워크 또는 아더 네트워크에 대한 제1식별 정보를 포함하고, 상기 제1식별 정보가 상기 아더 네트워크를 나타내는 경우, 상기 네트워크 정보는 인터넷 리니어 채널에 대한 제2식별 정보를 포함한다. 또한, 상기 시그널링 정보는 인터넷 리니어 채널에 기반하여 전송되고, 상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 획득하기 위한 서비스 디스커버리 정보를 포함하고, 상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 식별하는 URI(Uniform Resource Identifier)정보를 포함한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 기존 리니어 서비스 및 OTT 서비스가 통합된 UI를 통해 접근되는 서비스를 제공한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, STB 없이, 오픈 인터넷을 통해 기존 리니어 채널 들과 동일한 UX 를 제공하는 미디어 서비스를 실현한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, ABR 서비스를 위한 서비스 디스커버리의 전달 방법을 제안한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 유니캐스트/멀티캐스트/브로드캐스트 등 전송방법을 고려한 파일 식별 방법을 제공한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, IP 기반의 멀티캐스트 송수신을 위한 네트워크의 구조를 제안하고, 멀티캐스트/유니캐스트 동적 할당을 통해, 사용자에게 심리스한 서비스를 제공한다.
본 발명에 대해 더욱 이해하기 위해 포함되며 본 출원에 포함되고 그 일부를 구성하는 첨부된 도면은 본 발명의 원리를 설명하는 상세한 설명과 함께 본 발명의 실시예를 나타낸다.
도 1은 본 발명의 실시예들에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치의 구조를 나타낸다.
도 2는 본 발명의 실시예들에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치의 구조를 나타낸다.
도3은 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치가 서비스를 송신하고 수신하는 구조를 나타낸다.
도4는 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치의 네트워크 구조를 나타낸다.
도5는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 데이터를 수신하는 구조를 나타낸다.
도6은 NIT(Network information table)의 구성을 나타낸다.
도7은 BAT(Bouquet Association Table)의 구성을 나타낸다.
도8은 SDT(Service Description Table)의 구성을 나타낸다.
도9는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 시그널링 정보를 파싱하는 과정을 나타낸다.
도10은 네트워크의 종류를 나타낸다.
도11은 URI디스크립터(URI_linkage_descriptor)의 구성을 나타낸다.
도12는 URI연결 타입(uri_linkage_type) 정보의 구성을 나타낸다.
도13은 프라이빗 데이터의 구성을 나타낸다.
도14는 프라이빗 데이터의 구성을 나타낸다.
도15는 IP채널 아이디 디스크립터(IP_channel_ID_descriptor)의 구성을 나타낸다.
도16은 부케에 기반하여 서비스 디스커버리를 하는 과정을 나타낸다.
도17은 멀티캐스트 ABR 구조를 나타낸다.
도18은 IPTV 프로토콜 스택의 구성을 나타낸다.
도19는 IPTV 서비스 디스커버리 과정을 나타낸다.
도20은 서비스 정보의 구성을 나타낸다.
도21은 서비스 디스커버리 과정을 나타낸다.
도22은 유저 클래스 옵션의 구성을 나타낸다.
도23는 DHCP의 포맷을 나타낸다.
도24는 서비스 프로바이더 디스커버리 정보 레코드를 나타낸다.
도25는 페이로드 ID값에 따른 서비스 디스커버리 및 셀렉션 서버에 대한 데이터의 구성을 나타낸다.
도26은 오퍼링 리스트 타입 정보의 구성을 나타낸다.
도27은 서비스 디스커버리 정보의 구성을 나타낸다.
도28은 오퍼링 리스트 타입의 구성을 나타낸다.
도29는 오퍼링 엘리먼트에 대한 푸쉬 모드 및 풀 모드를 나타낸다.
도30은 AdaptiveStreamingModeType의 구성을 나타낸다.
도31은 서비스 프로바이더 디스커버리에 관한 실시예를 나타낸다.
도32는 브로드캐스트 디스커버리 인포메이션 스키마를 나타낸다.
도33은 브도르캐스트 딜리버리 인포메이션 스키마를 나타낸다.
도34는 싱글 브로드캐스트 디스커버리 인포메이션 스키마를 나타낸다.
도35는 서비스 로케이션의 구성을 나타낸다.
도36은 싱글 서비스를 확장한 구성을 나타낸다.
도37은 딜리버리 모드에 따른 베이스URL정보를 나타낸다.
도38은 싱글 서비스에 대한 서비스 디스커버리 구성을 나타낸다.
도39는 MPD의 구성을 나타낸다.
도40은 인터넷 채널을 통합한 서비스를 제공하기 위한 구성을 나타낸다.
도41은 통합 채널 가이드 UI의 구성을 나타낸다.
도42는 통합 채널 시스템에서 채널 전환 UI 방법을 나타낸다.
도43은 어답티브 미디어 스트리밍(Adaptive Media Streaming)을 위한 네트워크 구조를 나타낸다.
도44는 네트워크의 종류를 나타낸다.
도45는 브로드캐스팅에 대한 컨텐츠 네트워크의 구성을 나타낸다.
도46은 위성의 브로드캐스팅에 대한 컨텐츠 네트워크의 구성을 나타낸다.
도47은 CDN 및 OTT에 대한 컨텐츠 네트워크의 구성을 나타낸다.
도48은 케이블 네트워크에 대한 ABR 멀티캐스트 네트워크의 구성을 나타낸다.
도49는 모바일 네트워크에 대한 ABR 멀티캐스트 네트워크의 구성을 나타낸다.
도50은 홈 네트워크에 대한 유저 네트워크의 구성을 나타낸다.
도51은 어답티브 미디어 스트리밍을 위한 네트워크 구조를 나타낸다.
도52는 어답티브 미디어 스트리밍을 위한 프로토콜을 나타낸다.
도53은 어답티브 미디어 스트리밍을 위한 프로토콜을 나타낸다.
도54는 도52 상의 멀티캐스트 센더에 대한 시그널링 및 제어를 위한 프로토콜을 나타낸다.
도55는 도52상의 멀티캐스트 리시버 및 디코더에 대한 시그널링 및 제어를 위한 프로토콜을 나타낸다.
도56은 도53상의 시그널링 및 컨트롤을 위한 프로토콜을 나타낸다.
도 57은 IP멀티캐스트를 위한 프로토콜 스택을 나타낸다.
도58은 IP멀티캐스팅을 위한 미디어 딜리버리 방법을 나타낸다.
도59는 IP멀티캐스팅을 위한 미디어 딜리버리를 나타낸다.
도60은 IP멀티캐스팅을 위한 미디어 딜리버리를 나타낸다.
도61은 DASH segment 의 구조 및 발생과 파싱 순서를 나타낸다.
도62는 DASH segment 의 구조를 나타낸다.
도63은 DASH segment 의 구조 및 발생과 파싱 순서를 나타낸다.
도64는 DASH segment 의 playback을 위한 user network를 나타낸다.
도65는 MPD 계층적 구조를 나타낸다.
도66은 DASH segment 의 playback을 위한 user network를 나타낸다.
도67은 빠른 스타트업을 위한 시그널링 방법을 나타낸다.
도68은 멀티캐스트 ABR 레퍼런스 구조 모델을 나타낸다.
도69는 Multicast ABR delivery method 에 따른 base url 정의를 나타낸다.
도70은 segment 접근 URL 구성방법을 나타낸다.
도71은 multicast ABR service 아키텍쳐를 나타낸다.
도72는 multicast ABR service control message를 나타낸다.
도73은 본 발명의 실시예들에 따른 방송 신호 송신 방법을 나타낸다.
도74는 본 발명의 실시예들에 따른 방송 신호 수신 방법을 나타낸다.
도75는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 서비스를 디스커버리하고, 서비스 가이드를 디스플레이하는 과정을 나타낸다.
본 발명의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 본 발명의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 본 발명의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 본 발명에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 본 발명이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
본 발명에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 본 발명은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
도 1은 본 발명의 실시예들에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치의 구조를 나타낸다.
본 발명의 실시예들에 따른 차세대 방송 서비스에 대한 방송 신호 송신 장치는 인풋 포맷 블록 (Input Format block) (1000), BICM (bit interleaved coding & modulation) 블록(1010), 프레임 빌딩 블록 (Frame building block) (1020), OFDM (orthogonal frequency division multiplexing) 제너레이션 블록 (OFDM generation block)(1030), 및 시그널링 생성 블록(1040)을 포함할 수 있다. 방송 신호 송신 장치의 각 블록의 동작에 대해 설명한다.
IP 스트림/패킷 및 MPEG2-TS은 주요 입력 포맷이고, 다른 스트림 타입은 일반 스트림으로 다루어진다. 이들 데이터 입력에 추가로, 관리 정보가 입력되어 각 입력 스트림에 대한 해당 대역폭의 스케줄링 및 할당을 제어한다. 하나 또는 다수의 TS 스트림, IP 스트림 및/또는 일반 스트림 입력이 동시에 허용된다.
인풋 포맷 블록(1000)은 각각의 입력 스트림을 독립적인 코딩 및 변조가 적용되는 하나 또는 다수의 데이터 파이프로 디멀티플렉싱 할 수 있다. 데이터 파이프는 견고성(robustness) 제어를 위한 기본 단위이며, 이는 QoS (Quality of Service)에 영향을 미친다. 하나 또는 다수의 서비스 또는 서비스 컴포넌트가 하나의 데이터 파이프에 의해 전달될 수 있다.
데이터 파이프는 하나 또는 다수의 서비스 또는 서비스 컴포넌트를 전달할 수 있는 서비스 데이터 또는 관련 메타데이터를 전달하는 물리 계층(physical layer)에서의 로지컬 채널이다. 데이터 파이프는 물리 계층 파이프(Physicla Layer Pipe, PLP)에 대응될 수 있다.
또한, 데이터 파이프 유닛은 하나의 프레임에서 데이터 셀을 데이터 파이프에 할당하기 위한 기본 유닛이다.
인풋 포맷 블록(1000)에서, 패리티(parity) 데이터는 에러 정정을 위해 추가되고, 인코딩된 비트 스트림은 복소수값 컨스텔레이션 심볼에 매핑된다. 해당 심볼은 해당 데이터 파이프에 사용되는 특정 인터리빙 깊이에 걸쳐 인터리빙 된다. 어드벤스 프로파일에 있어서, BICM 블록(1010)에서 MIMO 인코딩이 실행되고 추가 데이터 경로가 MIMO 전송을 위해 출력에 추가된다.
프레임 빌딩 블록(1020)은 하나의 프레임 내에서 입력 데이터 파이프의 데이터 셀을 OFDM 실볼로 매핑할 수 있다. 매핑 후, 주파수 영역 다이버시티를 위해, 특히 주파수 선택적 페이딩 채널을 방지하기 위해 주파수 인터리빙이 이용된다.
프리앰블을 각 프레임의 시작에 삽입한 후, OFDM 제너레이션 블록(1030)은 사이클릭 프리픽스(cyclic prefix)을 가드 인터벌로 갖는 기존의 OFDM 변조를 적용할 수 있다. 안테나 스페이스 다이버시티를 위해, 분산된(distributed) MISO 방식이 송신기에 걸쳐 적용된다. 또한, PAPR (peak-to-average power ratio) 방식이 시간 영역에서 실행된다. 유연한 네트워크 방식을 위해, 해당 제안은 다양한 FFT 사이즈, 가드 인터벌 길이, 해당 파일럿 패턴의 집합을 제공한다.
시그널링 생성 블록(1040)은 각 기능 블록의 동작에 사용되는 물리 계층(physical layer) 시그널링 정보를 생성할 수 있다. 해당 시그널링 정보는 또한 관심 있는 서비스가 수신기 측에서 적절히 복구되도록 전송된다.
도 2는 본 발명의 실시예들에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치의 구조를 나타낸다.
본 발명의 실시예들에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치는 도 1을 참조하여 설명한 차세대 방송 서비스에 대한 방송 신호 송신 장치에 대응할 수 있다.
본 발명의 실시예들에 따른 차세대 방송 서비스에 대한 방송 신호 수신 장치는 동기 및 복조 모듈 (synchronization & demodulation module) (9000), 프레임 파싱 모듈 (frame parsing module) (9010), 디매핑 및 디코딩 모듈 (demapping & decoding module) (9020), 출력 프로세서 (output processor) (9030), 및 시그널링 디코딩 모듈 (signaling decoding module) (9040)을 포함할 수 있다. 방송 신호 수신 장치의 각 모듈의 동작에 대해 설명한다.
동기 및 복조 모듈(9000)은 m개의 수신 안테나를 통해 입력 신호를 수신하고, 방송 신호 수신 장치에 해당하는 시스템에 대해 신호 검출 및 동기화를 실행하고, 방송 신호 송신 장치에 의해 실행되는 절차의 역과정에 해당하는 복조를 실행할 수 있다.
프레임 파싱 모듈(9010)은 입력 신호 프레임을 파싱하고, 사용자에 의해 선택된 서비스가 전송되는 데이터를 추출할 수 있다. 방송 신호 송신 장치가 인터리빙을 실행하면, 프레임 파싱 모듈(9010)은 인터리빙의 역과정에 해당하는 디인터리빙을 실행할 수 있다. 이 경우, 추출되어야 하는 신호 및 데이터의 위치가 시그널링 디코딩 모듈(9040)로부터 출력된 데이터를 디코딩함으로써 획득되어, 방송 신호 송신 장치에 의해 생성된 스케줄링 정보가 복원될 수 있다.
디매핑 및 디코딩 모듈(9020)은 입력 신호를 비트 영역 데이터로 변환한 후, 필요에 따라 비트 영역 데이터들을 디인터리빙할 수 있다. 디매핑 및 디코딩 모듈(9020)은 전송 효율을 위해 적용된 매핑에 대한 디매핑을 실행하고, 디코딩을 통해 전송 채널에서 발생한 에러를 정정할 수 있다. 이 경우, 디매핑 및 디코딩 모듈(9020)은 시그널링 디코딩 모듈(9040)로부터 출력된 데이터를 디코딩함으로써 디매핑 및 디코딩을 위해 필요한 전송 파라미터를 획득할 수 있다.
출력 프로세서(9030)는 전송 효율을 향상시키기 위해 방송 신호 송신 장치에 의해 적용되는 다양한 압축/신호 처리 절차의 역과정을 실행할 수 있다. 이 경우, 출력 프로세서(9030)는 시그널링 디코딩 모듈(9040)로부터 출력된 데이터에서 필요한 제어 정보를 획득할 수 있다. 출력 프로세서(8300)의 출력은 방송 신호 송신 장치에 입력되는 신호에 해당하고, MPEG-TS, IP 스트림 (v4 또는 v6) 및 GS일 수 있다.
시그널링 디코딩 모듈(9040)은 동기 및 복조 모듈(9000)에 의해 복조된 신호로부터 PLS 정보를 획득할 수 있다. 전술한 바와 같이, 프레임 파싱 모듈(9010), 디매핑 및 디코딩 모듈(9200), 출력 프로세서(9300)는 시그널링 디코딩 모듈(9040)로부터 출력된 데이터를 이용하여 그 기능을 실행할 수 있다.
도3은 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치가 서비스를 송신하고 수신하는 구조를 나타낸다.
방송국(Broadcaster)는 지상 채널(Terrestrial, T), 케이블 채널(Cable, C), 위성 채널(Satellite, S)에 기반하여 서비스를 제공할 수 있다. 나아가, 방송국은 T채널, C채널, S채널과 동시에 인터넷 채널(Internet channel)에 기반하여 서비스를 제공할 수 있다. 따라서, 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 T채널, C채널, S채널, 및 인터넷 채널에 기반하여 서비스를 송신하고 수신할 수 있다. 방송국, 제조자, 사업자는 각 채널에 대한 인증 방법을 규정할 수 있다. 본 발명의 실시예들에 따른 방송 신호 수신 장치는 방송국, 제조사, 사업자가 만든 규정에 기반하여 각 서비스 채널에 대한 인증을 획득할 수 있다. 나아가, 기존 리니어(linear) 서비스와 통합된 인터넷 채널을 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치가 이용할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 인터넷 채널과 기존의 리니어 방송 채널 리스트를 통합된 형태로 이용하기 위해서, 기존 리니어 망에서 제공하는 서비스 디스커버리 정보를 통해 채널 리스트에 대한 부트스트랩(bootstrapping)을 제공할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 서비스를 제공하는 기존의 형태를 확장하여 서비스를 제공할 수 있고, 기존 리니어 채널망과 함께 온 디맨트 및 멀티캐스트(On-demand/multicast) 서비스 형태와 같은 추가적인 서비스를 제공할 수 있다. 또한, 방송 신호 송신 장치는 인터넷 채널 기반의 사용 리포트(Usage report)를 통해 퍼스널(personalization) 서비스를 제공할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 기존의 T채널, S채널, C채널의 서비스와 OTT(Over The Top) 서비스를 통합한 채널 리스트를 제공할 수 있다. 방송 신호 수신 장치는 다양한 서비스를 사용자에게 제공할 수 있고, 방송 신호 송신 장치 및 방송 신호 수신 장치의 기능이 확장될 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치에 연결 가능한 네트워크(Network/ISP)의 경우, OTT콘텐츠가 통합되어 제공될 수 있는 네트워크가 구축될 수 있다. 또한, 방송 신호 송신 장치는 유니캐스트/멀티캐스트(unicast/multicast)를 동적으로 할당하고(dynamic allocation), 인핸스드(enhanced)된 딜리버리 퍼포먼스(delivery performance)를 제공할 수 있다. 방송 신호 수신 장치는 논-매니지먼트(non-management)의 네트워크에 기반한 서비스를 제공하는 단말보다 우수한 퍼포먼스를 제공할 수 있다.
도4는 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치의 네트워크 구조를 나타낸다.
방송 신호 수신 장치는 단말(TV, 40009)에 대응될 수 있다. TV(40009)의 구체적인 구성은 도2에서 상술하였다.
셋톱박스(40008)는 방송 신호 수신 장치에 연결될 수 있다. 예들 들어, 셋톱박스(40008)는 HDMI 방식에 기반하여 방송 신호 수신 장치에 연결될 수 있다.
게이트웨이(40007)는 브로드밴드 네트워크(40005)로부터 컨텐츠 또는 서비스를 수신하여, 셋톱박스(40008)에 컨텐츠 또는 서비스를 제공한다.
브로드밴드 네트워크(40005)는 브로드밴드 네트워크에 관련된 컨텐츠 또는 서비스를 방송 신호 수신 장치에 제공한다.
컨텐츠 네트워크(Content Dlivery Network, 40006)는 컨텐츠에 관련된 데이터를 브로드밴드 네트워크(40005)에 제공한다.
멀티캐스트 해드엔드(40002)는 멀티캐스트 방식에 기반하여 데이터를 브로드밴드 네트워크(40005)에 전달한다.
소스(DVB-I source, 40003)는 데이터를 브로드밴드 네트워크(40005)에 제공한다. 소스가 제공하는 데이터는 DVB-I 방식에 따른 데이터를 포함할 수 있다.
지상파 네트워크(40004)는 지상 채널에 기반하여 지상파 헤드엔트(40001)로부터 지상파 관련 데이터를 수신하고, 셋톱박스(40008)에 제공한다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 OTT 서비스를 제공하기 위해서, 단말 장치마다 다른 OS 환경을 고려해야 하는 부담을 제거할 수 있다. 즉, 방송 신호 수신 장치는 OTT 어플리케이션을 별도로 제공할 필요가 없다. 방송 신호 수신 장치는 인더스트리 스탠다드 기반 에코시스템(industry standard based ecosystem)을 포함할 수 있다. 방송 신호 수신 장치는 공통의 서비스 인터페이스를 제공함으로써, 서비스 접근의 형태를 확장할 수 있는 효과를 제공한다.
도5는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 데이터를 수신하는 구조를 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 방송 신호를 수신한다.
TS 패킷 필터(50001)는 방송 신호에 포함된 TS 패킷을 처리한다. TS 패킷은 MPEG-2 Transport Stream packet을 의미할 수 있다.
PES 파서(50002)는 TS 패킷에 포함된 스트림을 처리한다. 스트림은 Packetized Elementary Stream을 의미할 수 있다. 스트림은 비디오 스트림을 포함할 수 있다.
PES 파서(50003)는 TS패킷에 포함된 스트림을 처리한다. 스트림은 Packetized Elementary Stream을 의미할 수 있고, 스트림은 오디오 스트림을 포함할 수 있다.
데이터 파서(50004)는 TS 패킷에 포함된 데이터를 처리한다. 데이터는 방송 프로그램에 관련된 컨텐츠 또는 어플리케이션에 관련된 이벤트 등을 포함할 수 있다.
시그널링 파서(50005)는 TS패킷에 포함된 시그널링 데이터를 처리한다. 시그널링 데이터는 BAT(Bouquet Association Table), NIT(Network Information Table), EIT(Event Information Table), SDT(Service Description Table), ICT(Identification Channel Table) 등을 포함할 수 있다. 시그널링 파서(50005)는 BAT파서, EIT파서, NIT파서, SDT파서, ICT파서 등을 포함할 수 있다.
비디오 디코더(50006)는 TS패킷에 포함된 비디오 데이터를 디코딩한다.
오디오 디코더(50007)는 TS 패킷에 포함된 오디오 데이터를 디코딩한다.
제어부(50008)는 디코딩된 비디오 데이터 및 디코딩된 오디오 데이터의 동기를 제어한다.
제어부(50009)는 비디오 데이터 및 오디오 데이터 외의 데이터에 대한 이벤트를 제어한다. 제어부(50009)는 시그널링 파서(50005)으로부터 시그널링 데이터를 수신하고, 시그널링 데이터에 기반하여 이벤트를 제어할 수 있다.
서비스 초기화 서버(Service Initialization Server, 50010)는 시그널링 파서(50005)의 시그널링 데이터로부터 서비스 디스커버리를 위한 URI(Uniform Resource Identifier)정보를 획득할 수 있다. 구체적으로, 시그널링 데이터는 서비스 스캐닝을 위한 서비스 부트스트랩 정보를 포함한다. 시그널링 파서(50005)는 서비스 부트스트랩 정보 중 특정 테이블 정보에 기반하여 서비스 디스커버리 정보 URI를 서버(50010)에 제공할 수 있다. 도5의 방법A는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 시그널링 데이터 중 NIT의 서비스 디스커버리 URI에 기반하여 ICT를 획득하는 과정을 나타낸다.
구체적으로, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 NIT의 서비스 디스커버리 URI 정보에 기반하여 서버로부터 ICT 정보를 획득할 수 있다. 시그널링 파서(50005)의 ICT파서는 서버로부터 획득한 ICT정보를 처리한다.
한편, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 리니어 채널을 통해서 ICT정보를 획득할 수 있다. 도5의 방법B는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 리니어 채널을 통해 수신한 시그널링 데이터로부터 ICT정보를 획득하여 처리하는 과정을 나타낸다.
EPG서버(50011)는 ICT 파서의 ICT정보에 기반한 서비스 가이드 정보를 EPG생성기(50012)에 제공할 수 있다.
DASH서버(50012)는 ICT정보에 기반하여 DASH(dynamic adaptive streaming over HTTP) 데이터를 위한 부트스르랩 정보를 멀티캐스트 인터널 서버(50013)에 제공할 수 있다.
DASH클라이언트(50014)는 멀티캐스트 인터널 서버(50013)으로부터 DASH데이터를 수신한다. DASH클라이언트(50014)는 DASH데이터에 포함된 MPD(미디어 Presentation Description) 정보를 파싱하고, DASH데이터에 포함된 파일을 파싱하고, DASH데이터에 포함된 비디오 데이터를 디코딩하고, DASH데이터에 포함된 오디오 데이터를 디코딩한다.
EPG생성기(50012)는 시그널링 파서(5005)로부터 EPG 관련 시그널링 데이터를 수신하고, EPG서버(50011)로부터 EPG데이터를 수신하여 디스플레이할 EPG 데이터를 생성할 수 있다.
렌더(50015)는 제어부(50008)으로부터 동기화된 비디오/오디오 데이터를 수신하고, DASH클라이언트(50014)로부터 DASH 비디오/오디오 데이터를 수신하여 렌더링할 수 있다.
디스플레이(50016)는 렌더링된 데이터 및 EPG 데이터를 디스플레이할 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 기존의 T/S/C 채널 및 IP 채널이 통합된 IP 서비스를 제공하기 위한 서비스 디스커버리 방법을 제공한다.
스탠드얼론 리니어 IP 서비스(Standalone Linear IP service)란, 기존의 T/S/C채널 및 IP 채널의 통합된 서비스 가이드를 제공할 수 있는 서비스를 의미한다. 방송 신호 수신 장치는 IP채널의 서비스 스캐닝을 위해서 서비스 부트스트랩 정보를 수신할 수 있다.
구체적으로, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 T/S/C 채널의 서비스 부트스트랩 정보 중 특정 테이블 또는 특정 디스크립션에서 서비스 오퍼레이터 URI(service operator URI)을 획득할 수 있다. 예를 들어, 서비스 오퍼레이터가 서비스 디스커버리 정보를 제공할 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 T/S/C 채널의 서비스 부트스트랩 정보 중 특정 테이블 또는 특정 디스크립션에서 서비스 디스커버리 정보 URI 을 획득할 수 있다 (도5의 방법A 참조).
본 발명의 실시예들에 따른 방송 신호 수신 장치는 T/S/C 채널의 서비스 부트스트랩 정보와 동일한 방법으로 비 실시간 carousel 로 전송되는 서비스 디스커버리 정보 파일 URI 을 획득할 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는CICAM 에서 서비스 부트스트랩 정보 중 특정 테이블 또는 특정 디스크립션에 기반하여 서비스 디스커버리 정보 URI 을 획득할 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 Hardwired linkage URI 정보를 시용하여 서비스 디스커버리를 할 수 있다. Hardwired linkage URI는 사업자 및 CE 간 합의(agreement) 를 통해, hardwired 된 URI 을 제공할 수 있다. 방송 신호 수신 장치는 해당 URI 을 통해, 서비스 디스커버리 정보를 획득할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 기존의 채널의 서비스 가이드를 통합하여 제공하기 때문에, 기존 채널의 서비스 가이드 정보에 대응되는 정보를 사용할 수 있다. 방송 신호 수신 장치는 서비스 가이드의 식별(unique identification) 정보를 도5에 도시된 구조 상에서 획득할 수 있다. TS 패킷 필터(50001)는 TS 패킷을 필터링하여 서비스 디스커버리 정보 및 오디오/비디오 데이터를 구분한다. 시그널링 파서(50005)는 수신한 방송 신호에 포함된 서비스 디스커버리 정보를 파싱하여 서비스 가이드 데이터를 DB에 구축한다.
본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 MPEG-2 system 기반 DVB 표준을 따를 수 있다. 예를 들어, DVB 표준에 따른 DVB 시스템 정보(system information)은 상술한 NIT(Network information table), BAT(Bouquet Association Table), SDT(Service description Table), EIT(Event information table) 등의 테이블 또는 디스크립션 정보를 포함하고, 방송 신호 송신 장치 및 방송 신호 수신 장치는 이러한 테이블을 사용하여 서비스 디스커버리를 수행하고, EPG 정보를 생성할 수 있다.
서비스 디스커버리 정보를 획득하는 과정은 수신 가능한 네트워크들을 시그널링하는 테이블인 NIT에 기반하여 수행될 수 있다. NIT는 네트워크의 서비스 디스커버리 정보를 포함한다. 본 발명의 실시예들에 따른 방송 신호 수신 장치는 NIT를 파싱하여 ICT를 획득하거나(도5의A) 리니어 채널을 통해 ICT 채널을 획득할 수 있다(도5의B).
도6은 NIT(Network information table)의 구성을 나타낸다.
도6의 네트워크 인포메이션 섹션(network information section)은 NIT를 의미한다. NIT에 포함된 정보는 DVB표준의 정의를 따를 수 있다.
테이블 식별 정보(table_id)는 NIT를 식별할 수 있다.
섹션 신택스 인디케이터(section_syntax_indicator)는 1비트의 필드이고 1의 값으로 설정될 수 있다. 섹션 신택스 인디케이터는 NIT에서 식별하는 신택스를 지시하는 정보를 포함한다.
리저브드 사용(reserved_future_use) 및 리저브드(reserved) 미래 사용을 위해 리저브드된 필드이다.
섹션 길이(section_length)는 섹션의 바이트 수를 나타낸다.
네트워크 식별정보(network_id)는 딜리버리 시스템을 식별하기 위해 사용될 수 있고, 네트워크를 통해 수신된 비트 스트림의 식별 정보(unique identification)를 나타낸다. 딜리버리 시스템이란, 트랜스포트 스트림을 전달하는 물리적 단위 개념을 의미한다.
버전 넘버(version_number)는 서브-테이블의 버전 넘버를 나타낸다.
커런트 넥스트 인디케이터(current_next_indicator)는 서브-테이블이 현재 적용 가능한 섭스 테이블인지 여부를 나타낸다.
섹션 넘버(section_number)는 섹션의 번호를 나타낸다.
라스트 섹션 넘버(last_section_number)는 라스트 섹션의 수를 나타낸다.
네트워크 디스크립터 길이(network_descriptors_length)는 네트워크 디스크립터의 바이트 길이 수를 나타낸다.
트랜스포트 스트림 루프 길이(transport_stream_loop_length)는 TS 루프의 총 바이트 길이 수를 나타낸다.
트랜스포트 스트림 아이디(transport_strem_id)는 TS의 식별을 위해 사용되는 정보이다.
오리지날 네트워크 아이디(original_network_id)는 오리지날 딜리버리 시스템의 네트워크 식별정보를 식별하는 정보이다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는NIT에 기반하여 현재 수신하고 있는 network, 예를 들어 지상(terrestrial), 케이블(cable), 위성(satellite) 채널의 네트워크들을 구별한다. 방송 신호 수신 장치는 해당 network 에서 수신 중인 비트 스트림들의 식별정보(unique identification)를 original network ID, Transport ID 를 통해 정의한다. TSID 는 현재 딜리버리 시스템 내에 멀티플렉싱(multiplexed) 된 TS 를 확인하기 위한 unique ID 이다.
나아가, 방송 신호 송신 장치는 현재 수신중인 S채널, T채널, C채널에 대한 메인 스트림을 위한 actual NIT 테이블과 다른 네트워크(other network)에 대한 NIT 테이블을 따로 사용할 수 있다. 따라서, 기존의 메인 스트림에 대한NIT 외에 다른 네트워크에 대한 테이블에서 인터넷 리니어 채널의 서비스 디스커버리가 가능하다. 이러한 메인 스트림 외의 다른 딜리버리 시스템에서는 네트워크 아이디(network ID)를 사용하여 네트워크를 구별할 수 있다. 따라서 본 발명의 실시예들에 따른 방송 신호 송신 장치는 다른 네트워크(other network)인 인터넷 리니어 채널을 확인하기 위해서 네트워크 아이디를 확장하여 사용할 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 도6의 NIT에 포함된 네트워크 아이디를 확장하여 서비스 디스커버리 URI 정보로 사용하여, 인터넷 리디어 채널에 대한 서비스 디스커버리를 도5의 A방법과 같이 수행할 수 있다.
또한, 본 발명의 실시예들에 따른 방송 신호 송신 장치는 방송망을 통해 carousel 방식으로 XML 파일 또는 바이너리 코드(binary code)을 전송할 수 있다. 이러한 경우, 방송 신호 수신 장치는 ICT테이블을 방송망을 통해 도5의 B방법과 같이 획득할 수 있다.
NIT는 하위 루프(loop)를 통해서 디스크립터를 추가로 포함할 수 있다. NIT에 포함된 디스크립터는 서비스 또는 서비스 리스트에 관한 정보를 포함할 수 있고, 디스크립터의 구체적인 구성은 이하에서 설명한다.
한편, 본 명세서에서 NIT는 제1시그널링 정보, 제2시그널링정보 등으로 호칭될 수 있다.
도7은 BAT(Bouquet Association Table)의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 서비스들을 묶어서 부케(bouquet)라는 서비스 번들(bundle)을 생성할 수 있다. BAT는 서비스 번들에 대한 시그널링 정보를 포함한다.
이러한 서비스 번들 또는 서비스 그룹핑을 통해 다른 네트워크에서 전송되는 다수의 스트림/서비스도 그룹핑하여 다양한 서비스 시나리오를 구성할 수 있다. 즉, 도7과 같이 방송 신호 송신 장치는 수신 네트워크에 상관 없이 bouquet 단위로 서비스들을 묶고, 수신되는 TS와 서비스들을 묶을 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 그룹핑된 서비스를 시그널링하기 위해서 부케 어쏘시에이션 섹션(Bouquet Association section Table, BAT)를 통해 시그널링 정보를 수신한다.
테이블 아이디(table_id)는 BAT를 식별하는 정보를 나타낸다.
섹션 신택스 인디케이터(section_syntax_indicator)는 BAT에서 시그널링하는 신택스를 지시하는 정보를 나타낸다.
부케 아이디(bouquet_id)는 서비스 번들을 식별하는 정보를 나타낸다.
버전 넘버(version_number)는 서브-테이블의 버전 넘버를 나타낸다.
커런트 넥스트 인디케이터(current_next_indicator)는 서브-테이블이 현재 적용 가능한 섭스 테이블인지 여부를 나타낸다.
섹션 넘버(section_number)는 섹션의 번호를 나타낸다.
라스트 섹션 넘버(last_section_number)는 라스트 섹션의 수를 나타낸다.
부케 디스크립터 길이(bouquet_description_length)는 BAT에서 기술하는 부케의 총 바이트 길이 수를 나타낸다.
트랜스포트 스트림 루프 길이(transport_strem_loop_length)는 TS루프의 총 바이트 길이 수를 나타낸다.
트랜스포트 스트림 아이디(transport_stream_id)는 딜리버리 시스템 내에 다른 멀티플렉스된 것으로부터 TS를 식별하는 정보를 나타낸다.
오리지날 네트워크 아이디(original_network_id)는 오리지날 딜리버리 시스템의 네트워크 아이디를 식별하는 정보를 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 BAT에 포함된 부케 아이디, 트랜스포트 스트림 아이디 및/또는 오리지날 네트워크 아이디에 기반하여 기존의 메인 스트림 또는 리니어 채널의 서비스 뿐만 아니라 인터넷 리니어 채널의 서비스를 번들한 부케를 디스크립션하고 디스커버리할 수 있다.
구체적으로, 부케 아이디는 인터넷 채널의 서비스가 포함된 부케를 식별할 수 있다. 트랜스포트 스트림 아이디는 인터넷 채널의 서비스를 포함하는 트랜스포트 스트림을 식별할 수 있다. 오리지날 네트워크 아이디는 오리지날이 되는 딜리버리 시스템의 네트워크 아이디를 의미하고, 인터넷 채널의 서비스에 대한 네트워크를 나타낼 수 있다. 본 발명의 실시예들에 따른 방송 신호 수신 장치는 BAT를 파싱하여 인터넷 채널의 서비스를 디스커버리할 수 있다.
BAT는 하위 루프(loop)를 통해서 디스크립터를 추가로 포함할 수 있다. BAT에 포함된 디스크립터는 서비스 또는 서비스 리스트에 관한 정보를 포함할 수 있고, 디스크립터의 구체적인 구성은 이하에서 설명한다.
한편, 본 명세서에서 BAT는 제1시그널링 정보, 제2시그널링 정보 등으로 호칭될 수 있다.
도8은 SDT(Service Description Table)의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 SDT를 포함한 방송 신호를 송신할 수 있고, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 SDT를 포함한 방송 신호를 수신할 수 있다.
테이블 아이디(table_id)는 SDT를 식별하는 정보를 나타낸다.
섹션 신택스 인디케이터(section_syntax_indicator)는 SDT에서 시그널링하는 신택스를 지시하는 정보를 나타낸다.
트랜스포트 스트림 아이디(transport_stream_id)는 딜리버리 시스템 내에서 SDT가 기술하는 트랜스포트 스트림을 식별하는 정보를 나타낸다.
버전 넘버(version_number)는 서브-테이블의 버전 넘버를 나타낸다.
커런트 넥스트 인디케이터(current_next_indicator)는 서브-테이블이 현재 적용 가능한 섭스 테이블인지 여부를 나타낸다.
섹션 넘버(section_number)는 섹션의 번호를 나타낸다.
라스트 섹션 넘버(last_section_number)는 라스트 섹션의 수를 나타낸다.
오리지날 네트워크 아이디(original_network_id)는 오리지날 딜리버리 시스템의 네트워크 아이디를 식별하는 정보를 나타낸다.
서비스 이이디(service_id)는 트랜스포트 스트림 내의 서비스를 식별하는 정보를 나타낸다.
EIT 스케쥴 플래그(EIT_schedule_flag)는 서비스에 대한 EIT(Event Information Table) 스케쥴 정보가 현재 TS에 존재하는지 여부를 나타낸다.
EIT 프레젠트 팔로잉 플래그(EIT_present_following_flag)는 서비스를 위한 EIT 프레젠트 팔로잉 정보가 현재 TS에 존재하는지 여부를 나타낸다.
러닝 스태이터스(running_status)는 서비스의 상태를 나타낸다. 서비스의 상태란 러닝(running) 여부, 스타트(starts in a few seconds) 여부, 멈춤(pausing) 여부, 서비스 오프-에어(service off-air) 여부 등을 포함할 수 있다.
프리 씨에이 모드(free_CA_mode)는 서비스의 모든 컴포넌트 스트림이 스크램블되는지 여부를 나타낸다. 프리 씨에이 모드는 서비스에 접속하는 구독자(subscriber)를 제어하기 위한 시스템인 CA 시스템(conditional Access system)에 의해 제어되는 하나 또는 하나 이상의 스트림들에 제어하는 모드를 나타낸다.
SDT는 현재 전송되고 있는 네트워크를 정의하고, TS 내에 전송되는 데이터의 서비스 디스크립션을 정의하는 테이블이다. SDT는 상술한 NIT와 유사하게, TSID 와 오리지날 네트워크 아이디에 기반하여 다수의 서비스를 기술할 수 있다. 방송 신호 송신 장치는 오리지날 네트워크 아이디, 트랜스포트 스트림 아이디 및/또는 서비스 아이디에 기반하여 하나의 서비스를 구별할 수 있다. 오리지날 네트워크 아이디가 식별하는 네트워크 상에서 중복되는 서비스 아이디는 없고, 서비스 아이디는 유니크한 값을 가진다. 또한, 통상적으로 오리지날 네트워크 아이디는 네트워크 아이디와 같은 값을 가진다.
상술한 도6내지8은 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치가 송수신하는 시그널링 정보를 나태나고, 각 테이블에 정의된 필드는 DVB-SI 표준의 정의를 따를 수 있다. 나아가, 본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 기존의 리니어 채널에서 서비스 디스크립션 및 서비스 디스커버리를 위해서 사용되는 테이블에 포함된 정보를 인터넷 채널을 위한 서비스 디스크립션 및 서비스 디스커버리를 위해 추가 확장하여 정의할 수 있다. 따라서, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 기존의 리니어 채널과의 하위 호환성(backward compatibility)을 제공하면서 인터넷 채널의 서비스를 사용자에게 제공할 수 있는 효과를 제공한다. 방송 신호 수신 장치는 기존 리니어 채널 및 인터넷 채널이 통합된 EPG를 사용자에게 제공할 수 있다.
한편, 본 발명의 실시예들에 따른 방송 신호 송신 장치는 새로운 테이블을 포함한 방송 신호를 송신할 수 있다. 도5에 도시된 ICT 테이블은 네트워크(actual network) 상에서 수신되는 서비스에 대한 서비스 가이드 정보를 포함할 수 있다. 방송 신호 수신 장치의 EPG생성기(50012)는 ICT 정보를 수신하여 하나의 채널 서비스 가이드를 통합된 EPG형태로 사용자에게 제공한다.
방송 신호 송신 장치는 네트워크를 통해 시그널링 정보를 포함한 시그널링 데이터 및 시그널링 데이터가 아닌 AV데이터를 포함하는 방송 데이터를 송신할 수 있다. 방송 신호 송신 장치는 컴포넌트 타입에 기반하여 시그널링 데이터 및 방송 데이터를 구분하여 처리할 수 있다.
방송 신호 수신 장치의 데이터 파서(50004)는 AV 데이터 이외에 인터넷 데이터 및 동기화를 위해 전송되는 동기화 데이터(e.g. MPEG TEMI) 등을 파싱한다. 따라서, 방송 신호 수신 장치는 일정한 레이트로 전송되는 타이밍에 맞추어 실제 채널(actual channel)에 대한 이벤트 링키지(event linkage) 서비스를 제공할 수 있다.
본 발명의 실시예들에 따른 ICT는 실제 인터넷 채널에서 수신할 미디어 데이터에 관한 정보를 포함할 수 있다. ICT는 MPD URI 를 포함한다. 방송 신호 수신 장치는 ICT의 MPD URI에 기반하여 콘텐츠를 수신할 수 있는 MPD를 획득할 수 있다. DASH 서버는 콘텐츠를 수신할 수 있는 역할(content origin)을 가진다. 따라서, DASH 서버(50012) 상에서 네트워크 상태에 따른 멀티캐스트 및/또는 유니캐스트 서버의 동적 할당(dynamic allocation)이 MPD URI를 통해서 수행될 수 있다. 멀티캐스트의 경우, MPD는 클라이언트와 가까운 CDN 역할을 갖는 멀티캐스트 서비스 주소를 포함하고, 방송 신호 수신 장치는 유니캐스트/멀티캐스트 어답티브 형태의 서비스를 수신할 수 있다.
DASH클라이언트(50014)는 MPD를 통해 A/V DASH 세그먼트(segment)를 수신하고 디코딩한다. 나아가, DASH클라이언트(50014)는 리니어 채널과 같이 미디어 데이터를 렌더링(50015)하고 디스플레이(50016)에서 플레이한다.
한편, 본 명세서에서 SDT는 제1시그널링 정보, 제2시그널링 정보 등으로 호칭될 수 있다.
도9는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 시그널링 정보를 파싱하는 과정을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 기존의 채널에 대한 서비스 가이드를 통합하기 위해서 필요한 유니크한 식별 정보를 상술한 바와 같이 사용할 수 있다. 본 발명의 실시예들에 따른 방송 신호 수신 장치는 서비스 가이드에 대한 식별 정보를 다음과 같이 파싱할 수 있다.
TS디멀티플렉서(90001)는 방송 신호에 포함된 TS로부터 시그널링 정보를 파싱할 수 있다. TS디멀티플렉서는 TS패킷필터(50001)에 대응될 수 있다. TS디멀티플렉서(90001)는 PID(packet identifier)에 기반하여 패킷을 식별할 수 있다.
TS패킷이 PAT에 대한 정보(90002)를 포함하는 경우, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 PAT를 파싱한다. PAT는 네트워크에 대한 식별정보(network_PID)를 포함한다.
TS패킷이 NIT에 대한 정보(90003)를 포함하는 경우, 방송 신호 수신 장치는 NIT를 파싱한다. NIT는 NIT테이블에 대한 식별 정보, 네트워크에 대한 식별 정보, 트랜스포트 스트림에 대한 식별 정보, 오리지날 네트워크에 대한 식별 정보를 포함한다.
나아가, TS패킷이 NIT에 대한 정보(90004)를 포함하는 경우, 방송 신호 수신 장치는 NIT를 파싱한다. NIT테이블에 대한 식별정보(table_id)는 메인 또는 실제(main or actual) 네트워크에 대한 정보를 포함할 수 있고, 다른(other) 네트워크에 대한 정보를 포함할 수 있다.
예를 들어, 서비스 가이드 정보가 MPEG-2 PSI(Program Specific Information)의 양식을 따르는 경우, 방송 신호 수신 장치는 TS패킷 헤더의 PID값이 0x00인 경우에 대응하여 PAT를 수신한다. 방송 신호 수신 장치는 PID값이 0x01인 경우에 대응하여 network_PID를 수신한다. NIT의 table_id가 0x40인 경우, NIT는 메인 네트워크에 대한 정보를 포함하고, NIT의 table_id가 0x41인 경우, NIT는 아더 네트워크(other network)에 대한 정보를 포함한다.
메인 네트워크에 대한 NIT(90003)는 NID(network_id), TSID(transport_stream_id), ONID(original_network_id) 를 포함하고, 방송 신호 수신 장치는 NID(network_id), TSID(transport_stream_id), ONID(original_network_id)에 기반하여 현재 수신하는 스트림을 식별할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 인터넷 채널의 서비스를 부트스트랩핑하기 위해서 NIT에 대한 정보(90004)를 포함하는 TS패킷을 송신할 수 있다.
아더 네트워크에 대한 NIT(90004)는 network_id를 포함할 수 있고, network_id는 인터넷 리니어 채널을 나타낼 수 있다. NIT(90004)는 ONID(original_network_id), TSID(transport_stream_id)를 포함하고, 방송 신호 수신 장치는 ONID 및 TSID에 기반하여 서비스를 유니크하게 식별할 수 있다.
한편, 인터넷 채널에 대한 데이터는 TSID를 포함하지 않는다. 따라서, 인터넷 채널에 대한 데이터를 위해서 TSID를 대체할 수 있는 정보(unique_id)가 필요하다. TSID의 유니크한 식별 정보는 URI_linkage_descriptor(90005, 90008)에 의해 대체될 수 있다. URI_linkage_descriptor는 URI주소 정보를 포함한다. 각 오퍼레이터마다 다른 URI 스트링(string)을 가지므로, 해당 URI스트링으로 TSID를 대체할 수 있다. 추가적으로, 방송 신호 수신 장치는 URI주소 정보에 기반하여 ICT채널 정보를 포함하는 디스커버리 정보 및 실제 DASH 세크먼트를 수신할 수 있는 MPD URI 정보를 수신할 수 있다. URI_linkage_descriptor의 구체적인 구성은 도11에서 구체적으로 설명한다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 리니어 인터넷 채널을 획득하기 위한 서비스 디스커버리 정보를 브로드밴드 및/또는 브로드캐스트에 기반하여 수신할 수 있다. 획득 경로가 브로드밴드인 경우의 디스크립터는 URI_linkage_descriptor(90005)이고, 획득 경로가 브로드캐스트인 경우의 디스크립터는 URI_linkage_descriptor(90005)이다.
획득 경로가 브로드밴드인 경우, URI_linkage_descriptor(90005)는 프라이빗 데이터(90006)를 포함한다. 브로드밴드에 기반한 프라이빗 데이터(90006)의 구체적인 구성은 도13에서 설명한다.
획득 경로가 브로드캐스트인 경우, URI_linkage_descriptor(90008)는 프라이빗 데이터(90009)를 포함한다. 브로드캐스트에 기반한 프라이빗 데이터(90009)의 구체적인 구성은 도14에서 설명한다.
추가로, 본 발명의 실시예들에 따른 방송 신호 송신 장치는 NIT(90004)의 하위 구성 정보로써, 서비스 또는 서비스 리스트에 대한 정보(service_list_descriptor)를 브로드밴드 또는 브로드캐스트에 기반하여 송신할 수 있다. 브로드밴드에 기반한 서비스 리스트 정보는 service_list_descriptor(90007)이고, 브로드캐스트에 기반한 서비스 리스트 정보는 service_list_descriptor(90010)이다. 서비스 리스트 정보(90007, 90010)는 서비스 아이디 및 서비스 타입과 같은 서비스에 대한 유니크 식별 정보를 제공한다.
TS패킷이 BAT에 대한 정보(90011)를 포함하는 경우, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 BAT(90011)를 파싱한다. BAT(90011)는 서비스 번들인 부케를 식별하는 정보(bouquet_id)를 포함하고, 방송 채널에 대한 서비스 디스크립션 정보인 TSID(transport_stream_id) 및 ONID(original_network_id)를 포함한다. 방송 신호 송신 장치는 인터넷 리니어 채널에 대한 서비스 디스크립션을 제공하기 위해서, 리니어 채널에 대한 TSID를 대체할 수 있는 정보를 추가로 제공할 수 있다. BAT(90011)은 하위 구성 정보로써, 서비스 디스커버리 URI를 위한 디스크립터(90012) 및 서비스 리스트 디스크립터(90013)를 추가적으로 포함할 수 있다. 디스크립터(90012) 및 서비스 리스트 디스크립터(90013)의 구체적인 구성은 도15에서 설명한다.
TS패킷이 SDT에 대한 정보(90014)를 포함하는 경우, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 SDT (90014)를 파싱한다. SDT(90014)의 구체적인 구성은 도8에서 설명하였다.
도10은 네트워크의 종류를 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 다양한 네트워크를 사용하여 방송 신호를 송신하고 수신할 수 있다. 네트워크는 S채널, T채널, C채널을 포함할 수 있고, 나아가, 인터넷 채널을 포함할 수 있다. 네트워크에 대한 시그널링 정보인 NIT는 network_id를 포함하고, 방송 신호 송신 장치는 network_id에 S채널, T채널, C채널과 함께 인터넷 채널을 할당할 수 있다.
도11은 URI디스크립터(URI_linkage_descriptor)의 구성을 나타낸다.
URI디스크립터는 타입(uri_linkage_type) 정보를 포함한다. 방송 신호 송신 장치는 인터넷 채널에 대한 서비스 디스커버리 정보에 대한 값을 타입 정보에 새롭게 할당할 수 있다. 타입 정보의 구체적인 구성은 도12를 참조하여 설명한다.
URI디스크립터는 프라이빗 데이터를 포함한다. 서비스 디스커버리 획득 경로가 브로드밴드 또는 브로드캐스트인 경우에 따른 프라이빗 데이터의 구체적인 구성은 도13 및 도14에서 각각 설명한다.
도12는 URI연결 타입(uri_linkage_type) 정보의 구성을 나타낸다.
도12의 URI연결 타입 정보는 리니어 인터넷 채널을 획득하기 위한 서비스 디스커버리 정보를 포함한다. 방송 신호 수신 장치가 리니어 인터넷 채널을 획득하는 경로는 브로드밴드 및/또는 브로드캐스트를 포함한다.
예를 들어, uri_linkage_type의 값이 0x00인 경우, uri 연결 정보의 타입은 CI Plus를 위한 온라인 SDT(OSDT)을 나타낸다. uri_linkage_type의 값이 0x01인 경우, uri 연결 정보의 타입은 DVB-IPTV SD&S를 나타낸다. uri_linkage_type의 값이 0x02인 경우, uri 연결 정보의 타입은 컴패니언 스크린 어플리케이션을 위한 MRS(Material Resolution Server)를 나타낸다. linkage_type의 값이 0x60인 경우, uri 연결 정보의 타입은 HbbTV 오퍼레이션 어플리케이션을 나타낸다.
나아가, 본 발명의 실시예들에 따른 방송 신호 송신 장치는 uri_linkage_type을 추가 확장하여 정의할 수 있다. 예를 들어, uri_linkage_type의 값이 0x61인 경우, uri 연결 정보의 타입은 브로드밴드 네트워크 상의 리니어 인터넷 채널에 대한 서비스 디스커버리 정보를 나타낸다. uri_linkage_type의 값이 0x62인 경우, uri 연결 정보의 타입은 브로드캐스트 네트워크 상의 리니어 인터넷 채널에 대한 서비스 디스커버리 정보를 나타낸다. 따라서, uri_linkage_type의 값이 0x61인 경우 방송 신호 수신 장치는 인터넷을 통해서 서비스 디스커버리 정보를 획득하고, uri_linkage_type의 값이 0x62인 경우 방송 신호 수신 장치는 현재 수신 중인 T채널, S채널 및/또는 C채널을 통한 DVB SI정보와 호환하면서 서비스 디스커버리 정보를 획득할 수 있다.
도13은 프라이빗 데이터의 구성을 나타낸다.
브로드밴드를 통해 전송되는 프라이빗 데이터(90006)에 포한된 정보를 설명하면 다음과 같다.
데스트니네이션 아이피 어드레스(Destination_IP_address)를 포함한다. 데스트니네이션 아이피 어드레스는 서비스 디스커버리 아이피 어드레스(service discovery IP address)를 나타낸다. 데스트니네이션 포트(Destination_Port)는 포트 넘버(port number)를 나타낸다. 서비스 프로바이더 아이디(Service_provider_id)는 서비스를 제공하는 사업자를 나타낸다. 네트워크 오퍼레이터 아이디(Network_operator_id)는 서비스를 제공하는 네트워크 오퍼레이터를 나타낸다. 인스턴스TSID(Instance_TSID)는 TSID를 대체하는 임시 TSID 값을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 프라이빗 데이터(90006)에 데스트네이션 아이피 어드레스 대신에 서비스 디스커버리를 위한 URL 정보를 추가할 수 있다. IP정보를 스트링(string)으로 변환하여 URL이 되기 때문에 URL정보는 IP 정보에 대응될 수 있다.
마찬가지로, 본 발명의 실시예들에 따른 방송 신호 송신 장치는 프라이빗 데이터(90006)에 데스트네이션 포트 대신에 서비스 디스커버리를 위한 URL정보를 추가할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 브로드밴드에 기반하여 프라이빗 데이터(90006)를 URI_linkage_descriptor(90005)에 포함시켜서 전송할 수 있다. 방송 신호 송신 장치는 프라이빗 데이터(90006)에 포함된 Destination_IP_address, Destination_Port, Service_provider_id, Network_operator_id, Instance_TSID를 인터넷 리니어 채널에 대한 서비스 디스커버리를 위한 URI 정보로 대체할 수 있다. 방송 신호 수신 장치는 인터넷 채널을 포함하는 방송 채널에 대한 통합 EPG를 제공할 수 있고, URI_linkage_descriptor(90005)의 URI 정보를 사용하여 인터넷 채널에 대한 서비스 디스커버리를 할 수 있다.
도14는 프라이빗 데이터의 구성을 나타낸다.
브로드캐스트를 통해 전송되는 프라이빗 데이터(90009)에 포함된 정보를 설명하면 다음과 같다.
인포 타입(Info_type)은 방송 신호 수신 장치가 수신하는 서비스 디스커버리 정보가 XML 형태인지, binary 인지 여부를 나타낸다.
패킷 식별 아이디(ICT_PID)는 서비스 디스커버리 테이블 정보를 포함하는 TS패킷의 PID를 나타낸다.
테이블 아이디(ICT_table_id)는 서비스 디스커버리 테이블을 식별할 수 있는 테이블의 아이디를 나타낸다.
서비스 디스커버리 URI(Service_discovery_URI)는 인포 타입이 XML 파일일 경우 파일 URI를 나타낸다.
인스턴스 TSID(instance_TSID)는 TSID를 대체하는 임시TSID를 나타낸다.
도9 내지 도14를 통해 방송 신호 수신 장치가 인터넷 채널에 대한 서비스 디스커버리 정보를 획득하는 방법을 설명하였다. 방송 신호 수신 장치가 아더 네트워크(other network)에 대한 NIT를 수신하고, NIT에 포함된 URI _linkage_descriptor를 브로드밴드 또는 브로드캐스트에 기반하여 파싱한다. 그리고 방송 신호 수신 장치는 각URI _linkage_descriptor에 포함된 프라이빗 데이터를 통해 TSID 대신에 추가 확장 정의된 서비스 디스커버리 URI를 획득한다.
나아가, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 NIT(90004) 및/또는 BAT(90011)의 하위 루프는 서비스 리스트 디스크립터(service_list_descriptor) 또는 서비스 디스크립터(service_descriptor)(90007, 90010, 90013)를 포함할 수 있다. 서비스 리스트 디스크립터(service_list_descriptor) 또는 서비스 디스크립터(service_descriptor)(90007, 90010, 90013)는 스트림 유니크 아이디(stream_unique_id) 및 서비스 아이디(service_id)를 포함한다.
BAT(90011)는 도7에서 상술한 바와 같이 네트워크와 관계없이 현재 수신기 내 스트림(stream) 및 서비스(service)를 모아서 부케(bouquet)이라는 서비스 번들(bundle)에 대하여 시그널링한다. BAT(90011)는 부케 아이디(bouquet_id), ONID(original_network_id), TSID(transport_stream_id)에 기반하여 네트워크 및 트랜스포트 레벨의 논리적인 번들에 대한 시그널링을 제공할 수 있다. 한편, 인터넷 리니어 채널은 TSID를 포함할 수 없기 때문에, 인터넷 리니어 채널 레벨에 대한 시그널링이 필요하다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 브로드캐스트에 기반하여 프라이빗 데이터를 URI_linkage_descriptor(90008)에 포함시켜서 전송할 수 있다. 방송 신호 송신 장치는 인포 타입(Info_type), 패킷 식별 아이디(ICT_PID), 테이블 아이디(ICT_table_id), 테이블 아이디(ICT_table_id), 서비스 디스커버리 URI(Service_discovery_URI), 및/또는 인스턴스 TSID(instance_TSID)를 인터넷 리니어 채널에 대한 서비스 디스커버리를 위한 URI 정보로 대체할 수 있다. 방송 신호 수신 장치는 인터넷 채널을 포함하는 방송 채널에 대한 통합 EPG를 제공할 수 있고, URI_linkage_descriptor(90008)의 URI 정보를 사용하여 인터넷 채널에 대한 서비스 디스커버리를 할 수 있다.
따라서, 본 발명의 실시예들에 따른 방송 신호 송신 장치는 상술한 바와 같이 uri_linkage_descriptor에 TSID를 대체하는 유니크한 정보를 추가하거나, BAT에 추가적으로 디스크립터를 정의할 수 있다. 구체적으로, BAT는 IP_channle_ID_descriptor를 포함할 수 있다. IP_channel_ID_descriptor의 구성을 도15에서 구체적으로 설명한다.
도15는 IP채널 아이디 디스크립터(IP_channel_ID_descriptor)의 구성을 나타낸다.
IP채널 아이디 디스크립터(IP_channel_ID_descriptor, 90012)는 네트워크 및 스트림에 대한 유니크한 정보를 포함한다. 마찬가지로, URI_linkage_descritor(90005, 90008) 역시 네트워크 및 스트림에 대한 유니크한 정보를 포함한다.
디스크립터 태그(descriptor_tag) 및 디스크립터 길이(descriptor_length)는 디스크립터를 식별하고, 디스크립터의 길이를 나타낸다.
서비스 프로바이더 아이디(service_provider_ID)는 IP채널에 대한 서비스 제공자를 식별하는 정보를 나타낸다.
네트워크 오퍼레이터 아이디(network_operator_ID)는 네트워크 오퍼레이트를 식별하는 정보를 나타낸다.
아이피 넘버(IP_number)는 IP채널에 대한 번호를 나타낸다.
포트 넘버(Port_number)는 IP채널에 대한 포트 번호를 나타낸다.
IP채널 아이디 디스크립터(IP_channel_ID_descriptor, 90012)는 인터넷 리니어 채널에 대한 서비스 디스커버리를 위한 서비스 디스커버리 URI(service_discovery_URI)를 포함한다. 또한, IP채널 아이디 디스크립터(90012)는 TSID를 대체하는 인스턴스 TSID(instance_TSID)를 포함한다. 인스턴스 TSID(instance_TSID)는 TSID를 대체하는 임시 TSID의 값을 가질 수 있다.
서비스 리스트 디스크립터(90013)는 인터넷 리니어 채널에 대한 서비스를 식별하기 위한 정보로서, 인터넷 리니어 채널의 서비스에 대한 서비스 아이디(service_id) 및 서비스 타입(service_type)을 포함한다.
따라서, 방송 신호 수신 장치는 BAT(90011)의 ONID(original_network_id)를 파싱하여 네트워크를 식별하고, IP채널 아이디 디스크립터(IP_channel_ID_descriptor, 90012)를 파싱하여 서비스 디스커버리 URI 정보에 기반하여 인터넷 리니어 채널의 서비스를 회득할 수 있다. 나아가, 방송 신호 수신 장치는 서비스 리스트 디스크립터(90013)에 기반하여 서비스 아이디 및 서비스 타입을 획득할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 IP채널 아이디 디스크립터(IP_channel_ID_descriptor, 90012)에 포함된 아이피 넘버(IP_number), 포트 넘버(Port_number), 네트워크 오퍼레이터 아이디(network_operator_ID), 서비스 프로바이더 아이디(service_provider_ID)를 추가 확장 정의하여 인터넷 리니어 채널에 대한 서비스를 디스커버리하기 위한 URI 정보를 포함시킬 수 있다. 방송 신호 수신 장치는 IP채널 아이디 디스크립터(IP_channel_ID_descriptor, 90012)에 기반하여 통합된 EPG를 수신할 수 있고, URI정보를 획득할 수 있다.
또한, 방송 신호 송신 장치는 논리적인 부케 아이디 단위 별로 서비스 번들을 구성하여 서비스 디스커버리를 시그널링할 수 있다.
도16은 부케에 기반하여 서비스 디스커버리를 하는 과정을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 부케 식별 정보에 기반하여 서비스 번들을 시그널링 할 수 있다.
부케1(bouquet 1, 16001) 및 부케2(bouquet 2, 16005)는 부케 아이디(bouquet_id)에 기반하여 식별될 수 있다.
부케1(bouquet 1, 16001)은 복수의 서비스 묶음인 서비스 번들(16002, 16003, 16003)을 포함할 수 있다. 부케2(bouquet 2, 16005)는 복수의 서비스 묶음인 서비스 번들(16006, 16007, 16008)을 포함할 수 있다. 도7에서 상술한 바와 같이, 부케는 다양한 네트워크에서 전송되는 다수의 스트림 또는 서비스들의 그룹을 포함한다. 서비스 번들은 ONID(original_network_id)에 의해 표현될 수 있다. 다양한 네트워크 중 T채널, S채널, C채널에 대한 서비스의 경우 TSID(transport_stream_id)를 통해서 표현될 수 있다(16003, 16007). 다양한 네트워크 중 인터넷 리니어 채널에 대한 서비스의 경우 URI에 기반하여 표현될 수 있다(16002, 16004, 16006, 16008). 예를 들어, 서비스 번들(16002)는 URI A에 기반하여 서비스 디스커버리될 수 있다. 서비스 번들(16008)은 URI C에 기반하여 서비스 디스커버리될 수 있다. 또한, 도9 내지 도15에서 상술한 바와 같이, 도16의 URI정보는 IP 넘버(IP_number), 포트 넘버(Port_number), 서비스 프로바이더 아이디(Service_provider_ID), 네트워크 오퍼레이터 아이디(Network_operator_id), 및/또는 인스턴스 TSID(instance_TSID)에 의해 대체될 수 있다.
상술한 본 발명의 실시예들에 따르면, 방송 신호 수신 장치는 지상파, 위성, 케이블 리니어 채널과 동일한 유저 경험(user UX)을 제공할 수 있는 IP베이스TV(IP based TV) 서비스를 구현할 수 있다. 나아가, 방송 신호 수신 장치는 어플리케이션 베이스 리니어(App based linear) 채널 서비스가 아닌, 오픈 인터넷(open internet) 기반 네이티브 코드(native code) 수신을 통해 지상파, 위성, 케이블 채널과 통합된 채널 가이드를 제공할 수 있다. 또한, 방송 신호 수신 장치는 기존 리니어 서비스(linear service) 채널과 동일한 사용자 경험(user UX) 를 제공할 수 있는 인터넷 채널 스캐닝(Internet channel scanning) 을 수행할 수 있고, MPEG-2 시스템/DVB SI 기반의 service 초기화를 수행할 수 있다. 방송 신호 수신 장치는 이러한 기존 리니어 채널과 통합된 서비스 가이드를 제공하기 위해, 인터넷 스트림 식별(Internet stream identifying)을 위한 네트워크, 스트림, 서비스 유니크 시그널링(Network/stream/service unique signaling)을 상술한 시그널링 정보, 디스크립션, 또는 테이블 등을 통해서 제공할 수 있다. 방송 신호 송신 장치는 새로운 정보를 추가적으로 정의하지 않고, 현재 시스템 정보(System information) 내에서 TSID 정보와 호환성을 유지하면서 TSID를 대체 할 수 있는 시그널링 방법을 제공한다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 리니어 IP 기반(Linear IP based TV) 서비스를 제공하기 위해, 기존 리니어 채널망의 서비스 부트스트랩(service bootstrap) 방식을 확장한다. 이러한 리니어 IP 기반 TV 서비스 식별(Linear IP based TV Service identification)을 위해 정의되어야 하는 유니크한 추가 정보들을 도9에서 설명하였다. 따라서, 사용자는 기존 리니어 채널 EPG 에 추가된 IP based TV channel 정보를 제공받을 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 RF 기반의 DVB 수신기(tuner)를 지원하는 장치에서 기존 리니어 서비스와 OTT 서비스가 통합된 UI를 통해 서비스에 접근할 수 있다. 또한, 방송 신호 수신 장치는 STB 없이, 오픈 인터넷을 통해 기존 리니어 채널들과 동일한 UX 를 제공하는 미디어 서비스를 지원할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는, 전통적인 IP 기반 리니어 채널 서비스는 특정 사업자, 예를 들어, ISP 또는 네트워크 오퍼레이터에 대한 가입을 통해, 인증(authentication) 을 부여 받고, 방송 신호 수신 장치는 사업자가 제공하는 STB 를 통해 IP 리니어 서비스를 받는다. 또한 최근에는, 커넥트 TV(connectivity TV)의 등장으로 STB-less 형태의 IP 리니어 서비스를 소비할 수 있다. 예를 들어, 대표적인 표준 기술로는 ATSC 3.0, IBB, HbbTV가 있고, 클라이언트는 TV 내부의 OS 플랫폼 위의 어플리케이션을 동작시켜서 다양한 리니어 리치 미디어(linear rich-media) 서비스를 받을 수 있다. 다양한 오퍼레이터들은 자체적으로 개발한 서비스 어플리케이션을 TV 플랫폼 위에 설치 할 수 있게 제공하고, 어플리케이션에서는 서비스를 위한 데이터들을 제공 받을 수 있는 서버와 요청/수신을 가능하게 하는 API 들을 정의하고 있다. 이러한 라이프 사이클 기반 위에 클라이언트는 TV UI 를 통해, 어플리케이션에 접근하고 어플리케이션을 통해 다양한 서비스를 수신할 수 있다. 본 발명의 실시예들에 따른 방송 신호 수신 장치는 상술한 다양한 서비스를 사용자에게 제공할 수 있다.
또한, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 리니어 TV 뿐만 아니라, OTT채널을 제공할 수 있다. OTT 시장은 IP기반의 장치의 필수적인 미디어 어플리케이션의 필요를 증가시킨다. OTT 시장에서 독자적인 플랫폼과 OTT만의 서비스 에코-시스템으로 독점적 서비스의 형태가 증가하고 있다. 다시 말해, 각 OTT 만이 제공하는 코덱(codec), 프로토콜 스택(protocol stack), 어플리케이션(application), 브라우저(browser) 등 독자적인 app-ecosystem 소비형태가 늘고 있다. 본 발명의 실시예들에 따른 방송 신호 수신 장치는 이러한 OTT 들의 독점적 플랫폼, 어플리케이션의 동작에 대한 의존도 등의 문제점을 해결한다. 나아가, 어플리케이션을 반드시 실행해야 하는 T채널, S채널, C 채널 등 리니어 채널 서비스와 유사한 UX를 제공하는 형태가 아닌, 방송 신호 수신 장치는 수신기 네이티브 레벨에서 서비스를 디스커버리하고, 클라이언트가 접근 가능한 서비스 서버에 접근하여 리니어 서비스를 수신하는 방법을 제안한다.
또한, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 OTT의 독자적인 플랫폼을 하나의 통일된 TV 네이티브 플랫폼으로 통합하고, 사용자가 OTT 어플리케이션을 실행하는 부담을 없애고, 채널 내의 OTT 콘텐츠를 수신하여 제공하는 방법을 제안한다.
도17은 멀티캐스트 ABR 구조를 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 IP기반의 멀티캐스트 서비스를 제공할 수 있다. 구체적으로, 방송 신호 송신 장치는 DASH프로토콜을 사용하여 적응형 멀티캐스트 미디어 서비스를 제공할 수 있다. ABR(Adaptive Bit Rate) Multicast 서비스를 위한 본 발명의 실시예들에 따른 방송 신호 송신 방법 및 방송 신호 수신 방법은 도17과 같다.
인코더(Encoder, 17001)는 콘텐츠를 전송 범위에 기반하여 압축할 수 있다.
패키져(Packager, 17002)는 컨텐츠를 압축한 데이터에 대한 AU(Access Unit)를 전송 할 수 있는 포맷(format) 으로 컨테이너(container)에 담을 수 있다.
오리진 서버(Origin server, 17003)는 콘텐츠 배포를 위한 원본 파일을 저장하고 있는 서버를 나타낸다.
CDN캐쉬(CDN cache, 17004)는 콘텐츠를 효율적으로 전달하기 위해 각 분산 서버에 데이터를 저장하는 서버를 나타낸다. 방송 신호 송수신 장치는 멀티캐스트 중 미싱 패킷(missing packet)에 대한 콘텐츠의 재전송(retransmission) 시에 CDN캐쉬(CDN cache, 17004)를 사용할 수 있다.
MABR 센더(MABR sender, Multicast Adaptive Bit Rate, 17005)는 서버(17003)로부터 전송된 콘텐츠에 기초하여 멀티캐스트 메타데이터 정보와 서비스를 홈 게이트웨이 및/또는 STB에 전송한다.
MABR 프록시(MABR proxy, 17006)는 ABR 클라이언트(17009)와 HTTP 커뮤니케이션을 수행하기 위한 임시 서버를 나타낸다. MABR 프록시(MABR proxy, 17006)에 기반하여 DASH 클라이언트와 프록시는 Unicast 서비스형태로 서비스를 소비할 수 있다.
네트워크 멀티캐스트 컨트롤러(Network multicast controller, 17007)는 멀티캐스트 ABR(multicast ABR) 서비스를 제공하기 위해 필요한 서비스 전반의 제어 정보를 홈 게이트웨이에 전송한다. 예를 들어, 멀티캐스트의 느린 RAP를 위해, unicast 및 multicast 전환을 가능하게 하는 control 정보를 홈 게이트웨이에 전송할 수 있다.
호스트 리솔브(Host resolve, 17008)는 unicast/multicast 서비스를 제공하기 위한 접속 정보를 처리한다. 예를 들어 호스트 리솔브(Host resolve, 17008)는 DNS 서버 역할을 하는 모듈을 통해, MPD url과 proxy 서버를 연결할 수 있다.
ABR 클라이언트(17009)는 ABR 서비스를 소비하는 클라이언트를 나타낸다.
STB(17010)는 셋톱박스를 나타내고, 커뮤니케이션을 위한 서버를 위한 MABR 프록시, MABR클라이언트, 호스트 리솔버(Host resolver)를 포함한다.
도17의 멀티캐스트를 위한 데이터 처리 과정을 보면, 네트워크 멀티캐스트 컨트롤러(17007)는 MABR 센더(17005)에 송신에 대한 제어정보를 전송하고, MABR 센더(17005)로부터 송신에 대한 제어정보를 수신할 수 있다. 컨트롤러(17007)는 MABR 프록시(17006)에 수신에 대한 제어정보를 전송하고, MABR 프록시(17006)로부터 수신에 대한 제어정보를 수신할 수 있다. MABR 센더(17005)는 MABR 프록시(17006) 및 STB(17010)에 IP멀티캐스트 방식에 기반하여 멀티캐스트 메타데이터 및 서비스 데이터를 전송할 수 있다. CDN캐쉬(17004)는 MABR 프록시(17006) 및 STB(17010)에 HTTP의 IP유니캐스트 방식에 기반하여 서버에 저장된 컨텐츠 관련 정보를 전송할 수 있다. MABR 프록시(17006) 및 ABR 클라이언트(17009) 간의 통신은 유니캐스트 방식에 의해 수행될 수 있다. 호스트 리솔브(Host resolve, 17008) 및 ABR 클라이언트(17009) 간의 통신은 DNS에 기반하여 수행될 수 있다.
도18은 IPTV 프로토콜 스택의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 도18의 프로토콜에 기반하여 데이터를 처리할 수 있다. 구체적으로 IPTV프로토콜은 IP 프로토콜 및 전송(IP Protocols & Transport)와 미들웨어 및 펑션(Middleware & functions)으로 분류되어 정의될 수 있다. 서비스는 실시간으로 특정 다수에게 전달되는 multicast 서비스, 사용자 요청에 따른 unicast 서비스, 비실시간 콘텐츠 다운로드 및 펌웨어 업그레이드(firmware upgrade), 서비스 초기화 정보가 카루셀 형태로 전송되어 갱신하여 서비스를 받는 형태를 포함할 수 있다.
다시 말해, Multicast 서비스는 UDP/IP/M2TS 프로토콜의 구조로 A.V, SI., PSI 등을 나타낼 수 있다. Unicast 서비스는 HTTP에 기반하여 요청 및 응답(request & response) 구조의 서비스를 나타낼 수 있다. 비실시간 서비스는 FLUTE에 기반한 multicast content 다운로드에 관련된 서비스 및 펌웨어 업데이트(firmware update) 정보 다운로드에 관련된 서비스를 나타낼 수 있다. DVBSTP 서비스는 서비스 디스커버리(Service discovery) 정보를 전송하는 프로토콜에 관련된 서비스 및 브로드밴드 컨텐츠 가이드(Broadband content guide) 정보를 전송 위한 프로토콜에 관련된 서비스를 나타낼 수 있다.
본 발명의 실시예들에 따른 방송 신호 송신 장치는 IPTV의 ABR 서비스를 제공하기 위해, DASH 프로토콜이 적용된 IPTV 서비스 초기화 정보를 확장하여 제공하는 것에 그 목적이 있다. 즉, 방송 신호 송신 장치가DASH 서비스에 접근 할 수 있는 정보를 추가 제공함으로써, 방송 신호 수신 장치가multicast 실시간 서비스를 위해 적응적인 스트리밍 서비스를 제공하여 버퍼링 없이 심리스(seamless)한 콘텐츠 소비를 가능하게 하는 효과를 제공한다.
도19는 IPTV 서비스 디스커버리 과정을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 기준 시점에서 이용가능한 서비스 프로바이더를 디스커버리한다. 방송신호 수신 장치는 서비스 디스커버리를 부트스트랩하기 위해서, 서비스 디스커버리 엔트리 포인트 정보를 DHCP의 구조를 통해 수신한다. 이후, 방송 신호 수신 장치는 각 수신된 SP 엔트리포인트 중, 적절한 서비스 제공자를 선택하여 IPTV 서비스를 제공하기 위한 서비스 디스커버리 정보를 수신할 수 있다.
도20은 서비스 정보의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 장치 및 방송 신호 수신 장치는 도20의 서비스 정보를 통해 서비스를 시그널링할 수 있고, 각 서비스 정보의 구체적인 구성은 DVB-SI표준에 따라서 표현될 수 있다.
도21은 서비스 디스커버리 과정을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 DHCP 의 서비스를 통해 IP 서비스 초기화를 진행함으로써, 서비스 디스커버리 엔트리를 수신할 수 있다.
단계(1) 관련하여, DHCP(Dynamic Host Configuration Protocol)는 terminal 이 network 에 접속하면, 서버가 자신의 목록에서 IP주소를 선택하여 할당한다.
STB와 DHCP 서버 간 handshake 하는 방법들 중 하나로써, DHCP 의 DNS server를 통해 HNED(Home Network End device)가 IP 주소를 할당 받는다.
HNED는 DHCP 방법 중 option 15의 방법을 통해, DNS_domain 정보를 정의하여 DHCP 에 전송한다. Option15 는 RFC 3315문서의 User Class Option 에서 추가 확정 정의될 수 있다. User Class Option의 구체적인 구성은 도22에서 설명한다.
DHCP의option information field는 domain정보를 추가적으로 포함할 수 있다. DHCP의 포맷은 도23에서 구체적으로 설명한다.
단계(2) 관련하여, 방송 신호 수신 장치는 터미널의 IP주소 및 IPTV서비스를 받기위한 필수적인 configuration 절차를 진행한다. 그리고, HNED는 RR(Receiver Report)를 return 정보로 수신한다. RR은 가능한 네트워크 및 서비스 리스트를 수신 한다. HNED는 RR에 기반하여 가능한 네트워크 및 서비스 리스트를 수신 한다. 예를 들어 SD&S1_domainname_IP_SD&S1 부터, SD&Sn_domainname_IP_SD&Sn까지에 대응되는 service entry를 수신한다. 구체적으로, 단계(3) 관련하여, HNED는 DHCP에 요청 정보를 전송한다. 요청 정보는 HTTP GET의 형태를 가지며, 도메인 네임을 포함한다. 단계(4) 관련하여, DHCP는 HNED에 서비스 프로바이더 디스커버리 정보를 전송한다. 단계(5) 관련하여, HNED는 DHCP에 도메인과 호스트네임을 포함한 요청 정보(HTTP GET)을 전송한다. 단계(6) 관련하여, DHCP는 HNED에 브로드캐스트 디스커버리 정보를 전송한다. 상세 과정은 도22 및 도23에서 더 설명한다.
도22은 유저 클래스 옵션의 구성을 나타낸다.
유저 클래스 옵션은 유저 또는 어플리케이션의 타입 또는 카테고리를 식별하기 위해서 클라이언트가 사용하는 정보를 나타낸다. 유즈 클래스 옵션은 RFC3315의 규격을 따를 수 있다. 옵션 코드는 옵션15를 나타낼 수 있고, 옵션 길이는 유저 클래스 데이터 필드의 길이를 나타내고, 유저 클래스 데이터는 클라이언트에 의해 전달되는 유저 클래스들을 나타낸다. 도21에서 HNED가 DHCP에 IP 요청을 전송 시에 유저 클래스 옵션 15에 기반하여 DNS 도메인 정보를 전송한다.
도23는 DHCP의 포맷을 나타낸다.
DHCP의 옵션 필드는 도메인 정보를 포함한다. HNED는 DHCP의 옵션 필드에 도메인 정보를 포함시켜서 옵션15방법으로 DHCP에 전송한다.
도21 내지 도23을 참조하여 서비스 디스커버리 과정을 이어서 설명하면 다음과 같다. HNED는 수신 중인 서비스의 엔트리들 중 엔트리를 선택하여 SD&S(service discovery and selection) 를 수행한다. HNED는 단계(1)을 통해서 서비스를 위한 도메인 및 IP 정보를 획득할 수 있다. 이후, 단계(3) 관련하여, HNED는 서비스 프로바이더 디스커버리 인포메이션을 획득하는 절차를 수행한다. 즉, HNED는 IP 및 도메인 정보에 기반하여 XML를 작성하고, HTTP GET의 방법으로 서비스 레벨에서 각 서비스 프로바이더(service provider) 정보를 DHCP에 요청할 수 있다. 예를 들어, HNED는 SD&S1_domainname_IP_SD&S1을 타겟으로 XML을 작성하고, 아래와 같이 요청할 수 있다.
GET /dvb/sdns/sp_discovery?id=ALL HTTP/1.1 CRLF
Host: SD&S1_DomainName CRLF
단계(4) 관련하여, HNED는 DHCP로부터 HTTP GET 요청에 대한 응답으로 SD&S server (Service discovery & selection) 로부터 인스턴스(instance)를 리턴 받는다. 인스턴스는 서비스 프로바이더 딜리버리 정보(service provider discovery info)를 받을 수 있는 인스턴스를 나타낸다. HNED는 인스턴스에 기반하여 해당 서비스의 모든 서비스 프로바이더(SP)들을 수집할 수 있다.
도24는 서비스 프로바이더 디스커버리 정보 레코드를 나타낸다.
도24는 도23에서 상술한 서비스 프로바이더 디스커버리 인포메이션(service provider discovery information)에 대한 실시예들을 도시한다. 도24의 스키마(schema)를 참조하면, SP1 및 SP2에 대한 두 가지 루트를 통해 서비스가 획득될 수 있다.
도25는 페이로드 ID값에 따른 서비스 디스커버리 및 셀렉션 서버에 대한 데이터의 구성을 나타낸다.
예를 들어, 페이로드ID의 값이 2인 경우, 페이로드는 브로드캐스트 디스커버리 인포케이션(broadcast discovery information info) 을 가지는 UDP 세그먼트(segment)들을 수신할 수 있는 인스턴스(instance)를 수신할 수 있는 접근주소를 포함한다.
따라서, HNED가 인스턴스에서 서비스 소비하고자 하는 SP의 페이로드의 세그먼트를 HTTP GET을 통해 요청하면, 서비스에 접속할 수 있는 XML이 리턴된다.
도24를 참조하면, 또한, 서비스 프로바이더 디스커버리 인포메이션(service provider discovery information)은 두 가지로 구성된 XML로 정의가 될 수 있다.
구체적으로, <serviceproviderListType> 와 <ServiceProviderType> 의 상위 요소로 구성된 문서로 정의된다. <ServiceProviderType> 의 경우, 서비스 프로바이더(Serviceprovider)의 이름(name), 디스크립션(description) 및 오퍼링(offering)의 구성을 포함한다.
도26은 오퍼링 리스트 타입 정보의 구성을 나타낸다.
오퍼링 엘리먼트(offering element)는 오퍼링 베이스(offeringbase)와 오퍼링리스트타입(offerlingListType)를 하위 엘리먼트(element)로 포함한다. 오퍼링 엘리먼트는 전송 모드에 따른 위치(location) 정보를 포함할 수 있다. HNED는 도24의 서비스 프로바이더 디스커버리 정보를 통해 각 SP의 서비스 specific 정보를 받을 수 있는 도메인 또는 IP 주소를 획득할 수 있다.
도27은 서비스 디스커버리 정보의 구성을 나타낸다.
도24의 서비스 프로바이더 디스커버리 인포메이션 레코드는 SP들을 묶어서 기술할 수 있다. 따라서, SP에 대해 플렉서블(flexible)하게 기술할 수 있다. 도27은 서비스 프로바이더 디스커버리 인포메이션(service provider discovery information)의 스키마(schema) 구조를 나타낸다.
도27은 서비스 프로바이더 타입(service provider type)에 따라서 각 SP들의 속성에 관련된 정보를 포함한다. 구체적인 엘리먼트는 다음과 같다.
서비스 프로바이더(Serviceprovider)는 서비스 프로바이더의 디스크립션을 나타낸다.
이름(Name)은 서비스 프로바이더의 텍스트 상의 이름을 나타낸다.
디스크립션(Description)은 서비스의 텍스트 상의 디스크립션(textual description)을 나타낸다.
오퍼링(Offering)은 딜리버리 방법을 나타낸다. 오퍼링은 푸쉬(Push) 또는 풀(Pull) 형태의 서비스에 대해 각각의 위치(location) 또는 IP 접근 정보를 제공할 수 있다. 즉, 방송 신호 수신 장치는 도25와 같이payloadID 의 분류를 통한 정보를 수신할 수 있고 그 중 broadcast discovery information 의 정보를 받을 수 있는 XML을 수신 받을 수 있는 주소를 획득할 수 있다.
도28은 오퍼링 리스트 타입의 구성을 나타낸다.
HNED는 딜리버리 방법(delivery method)에 따라 푸쉬모드/풀모드(push/pull mode)로 메타데이터(metadata)를 기술 할 수 있다. 또한, 메타데이터는 방법(method)에 따라 구체적인 위치(url location) 관련 정보를 포함할 수 있다. 예를 들어, 풀 모드(pull mode) 시 메타데이터는PayloadList 내 서비스 specific한 정보를 수신 받을 수 있는 payload ID 와 segment # 관련 정보, 그리고 위치(location) 정보를 포함할 수 있다. 또한, 푸쉬(push) 모드 시 메타데이터는 DVBSTP transport mode type에 기반하여 multicast 서비스를 받을 수 있는 브로드캐스트 디스커버리 인포메이션(broadcast discovery information) 의 주소를 포함할 수 있다.
도29는 오퍼링 엘리먼트에 대한 푸쉬 모드 및 풀 모드를 나타낸다.
서비스 프로바이더 타입의 하위 엘리먼트인 오퍼링 엘리먼트는 푸쉬 모드 및 풀 모드에 다른 메타데이터를 도29와 같이 포함할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 IP 상의 어답티브 멀티캐스트(adaptive multicast) 및 서비스 프로바이더 디스커버리 인포메이션 레코드에 기반하여 ABR 서비스를 초기화하고, 각 SP가 제공하는 브로드캐스트 인포메이션에 접근하기 위한 정보를 제공한다.
offering 의 push 모드는 AdaptiveStreamingModeType 추가로 포함할 수 있다. AdaptiveStreamingModeType에 기반하여, 서비스에 접근가능한 정보를 정의할 수 잇다.
도30은 AdaptiveStreamingModeType의 구성을 나타낸다.
어답티브 멀티캐스트 모드 타입(AdaptiveMulticastmodeType)은 ABR multicast 서비스를 정의하기 위해, 필요한 상위 단위를 나타낸다.
어답티브 멀티캐스트 어드레스(AdaptivemulticastAddress)는 각 SP의 ABR multicast 서비스가 가능한 브로드캐스트 인포메이션(broadcasting information) 관련 정보를 획득하기 위한 정보를 포함한다.
IP 어드레스(IP address)는 브로드캐스트 인포메이션 획득을 위해 필요한 접근(access) 서버 IP 정보를 포함한다.
포트 번호(Port No)는 브로드캐스트 인포메이션 획득을 위해 필요한 접근 포트(access port) 정보를 포함한다.
딜리버리 포맷(Delivery format)은 ABR 멀티캐스트(ABR multicast)를 위한 파일 또는 TS 포맷을 인캡슐레이션*encapsulation)하는 프로토콜 정보를 나타낸다. 예를 들어, ROUTE, FLUTE, QUIC, RTP, TS 등과 같은 프로토콜 정보를 의미할 수 있다.
도21의 단계(5) 관련하여, SP의 domain과 받으려는 정보(payloadID) 와 segment #로 구성된 XML을 통해 HNED는 HTTP GET의 요청은 전송할 수 있다. HNED는 각 서비스에 해당하는 IP 미디어 서비스의 구체적 정보를 수신 할 수 있다. 예를 들어, HTTP GET 요청은 다음과 같을 수 있다.
GET/dvb/sdns/service_discovery?id=SP1_DomainName&Payload=02&Segment=0000 HTTP/1.1 CRLF
Host= sdns.SP1.com CRLF
GET/dvb/sdns/service_discovery?id=SP1_DomainName&Payload=02&Segment=0001 HTTP/1.1 CRLF
Host= sdns.SP1.com CRLF
GET/dvb/sdns/service_discovery?id=SP1_DomainName&Payload=02&Segment=0002 HTTP/1.1 CRLF
Host= sdns.SP1.com CRLF
도31은 서비스 프로바이더 디스커버리에 관한 실시예를 나타낸다.
서비스 프로바이더 디스커버리 정보는 서비스 프로바이더에 대한 네임 및 오퍼링을 포함하고, 오퍼링의 딜리버리 방법에 따른 정보를 포함한다. 오퍼링의 모드가 푸쉬인 경우, 푸쉬는 어답티브 멀티캐스트 어드레스 정보를 포함하고, 페이로드ID에 따른 세그먼트ID를 포함한다. 오퍼링의 모드가 풀인 경우 위치 정보, 페이로드ID에 따른 세그먼트ID를 포함한다.
도21의 단계(6) 관련하여, 단계(5)의 HTTP GET 요청한 정보를 서버로부터 XML을 리턴 형태로 수신한다. 여기서 XML은 SP1의 대한 브로드캐스트 디스커버리 인포메이션(broadcast discovery information)의 실시예 이다.
도32는 브로드캐스트 디스커버리 인포메이션 스키마를 나타낸다.
도24에서 상술한 브로드캐스트 디스커버리 인포메이션 레코드(Broadcast Discovery information Record)는 브로드캐스트 오퍼링(broadcastOffering) 의 스키마 형태로 구성되는데, 브로드캐스트 오퍼링은 도32와 같은 엘리먼트(element) 구조로 초기화 정보를 포함한다. 브로드캐스트 오퍼링은 각 서비스 제공자 레벨에서 구체적인 브로드캐스트 디스커버리를 위한 정보를 제공하고, 구체적인 필드들은 다음과 같다.
서비스 리스트(serviceList)는 SP로부터 제공된 IP서비스(IP service)들의 구체적인 정보들을 포함하고, IP서비스들에 접근할 수 있는 위치(location) 정보를 나타낼 수 있다.
싱글서비스(SingleService)는 싱글 IP 서비스(single IP service)에 대한 구체적인 정보를 포함하고, 싱글IP서비스에 접근할 수 있는 위치(location) 정보를 나타낼 수 있다.
서비스 로케이션(ServiceLocation)은 서비스(service)를 찾을 수 있는 위치를 나타낸다. 예를 들어, 도메인( domain), URL, IP 어드레스 등을 나타낼 수 있다.
DVBTriplet은 DVB SI에 있는 OriginNetwork_ID, TSID, serviceID 의 3가지 정보를 포함할 수 있다.
SI는 service Information 을 나타낸다. SI정보를 전체(Full)로 전달 할 수도 있고, 선택적으로( Optional) SI만 전달 할 수 있는데, optional SI의 경우 mandatory로 정의해야 설정된다.
도33은 브도르캐스트 딜리버리 인포메이션 스키마를 나타낸다.
브로드캐스트 오퍼링은 IP서비스 리스트에 대한 서비스 리스트를 포함한다. IP서비스 리스트는 IP서비스에 해당하는 싱글 서비스를 포함한다. IP서비스는 서비스 로케이션, 텍스튜얼 아이덴티파이어, DVBTriplet 등을 포함할 수 있다.
도34는 싱글 브로드캐스트 디스커버리 인포메이션 스키마를 나타낸다.
IP서비스는 서비스 로케이션 정보에 기반하여 서비스 디스커버리를 위한 정보를 제공한다. 또한, 도34에 도시된 IP서비스의 하위 엘리먼트는 싱글 브로드캐스트 디스커버리를 위한 정보에 해당한다.
도35는 서비스 로케이션의 구성을 나타낸다.
IP서비스는 하위 엘리먼트로써, 서비스 로케이션(ServiceLocation)을 포함한다. 서비스 로케이션은 다음과 같이 하위 엘리먼트를 포함할 수 있다.
브로드캐스트 시스템 타입(broadcastsystemtype)은 DVB-C,S,T 와 ATSC, ISDB 등 의 방송 방식을 나타낸다.
IP 멀티캐스트 어드레스(IPMulticastAddress)는 멀티캐스트 트랜스포트 어드레스(multicast transport address) 또는 IP 멀티캐스트에 접근할 수 있는 파라메터를 나타낸다.
RTSPURL는 RTP 스트리밍 서비스에 접근할 수 있는 URL 을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 멀티캐스트 방식의 ABR 서비스를 위한 서비스 초기화를 제공할 수 있다. 이러한 서비스를 위해서, DASH가 정의한 MPD 마니페스트(manifest) 파일을 수신할 수 있는 정보 및 수신 알고리즘을 이하에서 설명한다.
서비스 로케이션은 하위 엘리먼트 중 브로드캐스트 시스템(Broadcastsystem)의 방식에서 ID_multicast_ABR 정보를 제공할 수 있다. 서비스 로케이션은 브로드캐스트 시스템의 방식에서 ID_multicast_ABR의 값을 추가할 수 있다.
ID_multicast_ABR의 값은 방송 서비스의 전송 방법의 식별정보를 나타낼 수 있다. ID_multicast_ABR의 string은 변경이 가능하나, 기존의 멀티캐스트 방식에서 ABR 기술을 적용한 방송 서비스라는 식별 정보의 의미는 유지된다. 또한, IP 멀티캐스트 어드레스(IPMulticastAddress) 및 RTSPURL과 함께 IPmulticastABR_address 서비스에 접근할 수 있는 URL 또는 IP 정보가 추가 제안될 수 있다. IPmulticastABR_address 서비스에 접근할 수 있는 URL 또는 IP 정보는 DASH 서비스에서 필요한 MPD를 가져올 수 있는 접근정보로써 사용될 수 있다. 또한 그 서비스를 위한 부가 정보들도 추가 될 수 있다. IPmulticastABR_address 서비스에 접근할 수 있는 정보의 구체적인 정보는 도36에서 설명한다.
도36은 싱글 서비스를 확장한 구성을 나타낸다.
서비스 로케이션은 브로드캐스트 시스템과 함께 IP멀티캐스트 어드레스(IPMulticastAddress), RTSURL, IPmulcastABR_address를 포함할 수 있다. IPmulcastABR_address는 MABRType을 포함한다. MABRType은 다음과 같은 엘리먼트를 포함할 수 있다.
패스트스타트업(FastStartUp)은 멀티캐스트(IPTV multicast) 패킷을 수신하기 전, 패스트 채널 체인지(Fast channel change)를 위해 유니캐스트(unicast) 접속을 먼저 하기 위한 정보를 포함한다. 특정 기간(period) 동안은 유니캐스트(unicast) 패킷 또는 저화질로 구성된 데이터를 빠르게 랜더링하여, IPTV가 AV 재생의 지연 없이 데이터를 재생할 수 있는 효과를 제공한다. 패스트스타트업(FastStartUp)은 IP 주소를 포함하는 접근(accessing) 정보를 포함한다. 패스트스타트업(FastStartUp)은 네트워크 사업자의 광고 또는 컨텐츠 사업자의 광고를 더 포함할 수 있다. 구체적으로, 패스트스타트업(FastStartUp)은 딜리버리 옵션을 포함하고, 딜리버리 옵션은 스트리밍 및 스토리지 미디어를 포함한다. 딜리버리 옵션이 스트리밍인 경우, 스트리밍은 패스트 스타트를 위한 접근 정보인 주소 정보(startUP_address) 및 포트 정보(startUP_port)를 포함한다. 딜리버리 옵션이 스토리지 미디어인 경우, 스토리지 미디어는 컨텐츠 획득을 위한 정보(contentUrl)를 포함한다. 방송 신호 수신 장치는 패스트 스타트업 정보에 기반하여 서비스 및 방송서비스 디스커버리 단계에서 보다 빠른 서비스를 받을 수 있다.
딜리버리 옵션(Delivery option)은 패스트 스타트업을 구현하는 경우의 미디어 옵션을 나타낸다. 딜리버리 옵션은 미리 다운로드 된 저장된 파일을 통해 AV를 실행하는 스토리지 미디어(storagemedia)와 스트리밍(streaming)을 통해 패스트 스타트업을 위한 파일을 다운로드 받을 수 있는 정보를 포함한다.
스타트업 어드레스(Startup_IP_address)는 서비스 시작 시, 빠른 AV 재생을 위한 유니캐스트 접속 IP 주소 정보를 나타낸다.
스타트업 포트 어드레스(Startup_port_address)는 서비스 시작 시, 빠른 AV 재생을 위한 unicast 접속 포트(Port) 정보를 나타낸다.
스토리지 미디어(StorageMedia)는 딜리버리 옵셥 중ABR 멀티캐스트(multicast) 전에 미리 다운로드된 파일을 실행시키는 모드를 나타낸다.
컨텐츠URL(ContentUrl)은 패스트 스타트업을 위한 스토리지 또는 캐쉬(cache)에 저장된 파일 url 정보를 나타낸다.
MABR 어드레스(MABR_address)는 ABR 멀티캐스트(multicast) 서비스에 접속할 수 있는 IP 어드레스 정보를 나타낸다. 방송 신호 수신 장치는 일정 기간 동안 유니캐스트를 통한 FCC 또는 빠른 AV 접속(accessing)을 한 후, MABR 어드레스에 기반하여 멀티캐스트를 획득할 수 있는 위치로 접속하여 서비스를 소비할 수 있다. 또한, MABR 어드레스는 MPD를 획득할 수 있는 IP 정보를 나타낼 수 있다.
MABR 포트(MABR_port)는 ABR multicast 서비스를 수신하기 위한 port 번호를 나타낸다.
최대 대역폭(Maxbandwidth)은 송수신 네트워크 컨디션 또는 서비스 제공자가 반영하여 전송할 수 있는 비트 레이트(bit-rate)를 나타낸다. 최대 대역폭(Maxbandwidth)은 현재 전송 채널에서 수신할 수 있는 최대 비트 레이트를 나타낸다. 최대 대역폭(Maxbandwidth)을 통해 채널 패킷당 얼마의 데이터를 수신하는지를 알 수 있다. 최대 대역폭(Maxbandwidth)은 미디어 데이터의 버퍼링의 참고하여 빠른 오브젝트(object)를 구성하는데 사용될 수 있다.
딜리버리 모드(Deliverymode)는 MPD의 베이스URL(baseURL) 정보와 연결될 수 있다. 딜리버리 모드에 따라서 MPD의 베이스URL(baseURL) 정보가 사용될 수 있다.
도37은 딜리버리 모드에 따른 베이스URL정보를 나타낸다.
딜리버리 모드는 유니캐스트 서비스, 리얼 타임의 멀티캐스트 서비스, 논-리얼 타임의 멀티 캐스트 서비스 등을 포함한다. 유니캐스트 서비스는 베이스패턴을 포함한다. 유니캐스트 서비스의 베이스패턴은 스트링 타입을 가지고, 베이스URL(@baseURL)을 포함한다. 리얼 타임의 멀티캐스트 서비스는 베이스 패턴을 포함한다. 베이트패턴은 스트링 타입을 가지고, 베이스URL(@baseURL)을 포함한다. 논-리얼 타임의 멀티캐스트 서비스는 베이스 패턴을 포함한다. 베이트패턴은 스트링 타입을 가지고, 베이스URL(@baseURL)을 포함한다. 방송 신호 수신 장치는 베이스URL(@baseURL)에 기반하여 각 딜리버리 모드에 따른 서비스를 획득할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치가 멀티캐스트(multicast) ABR(Adaptive Bit Rate) 서비스를 제공하기 위해서는 서비스 초기화 단계에서 브로드캐스트 디스커버리 인포메이션의 정보에서 MPD 을 수신할 수 있는 Url정보가 필요하다. 방송 신호 수신 장치가 MPD를 수신하여 ABR 서비스를 소비하는데, MPD 상에는 딜리버리 메소드에 대한 식별 정보가 없어 임의의 스트링이 MPD에 포함될 수 있다. 즉, MPD 내 레프리젠테이션(representation)을 통해 비트 스트림의 정보를 기술할 수 있고, 세그먼트(segment) URL을 통해, 어떤 세그먼트가 수신되고 있는지, 또는 어떤 URL로 요청해야하는지의 URL이 정의될 수 있다.
프로토콜 또는 방송방식에 따른 접근 주소가 다르기 때문에 url의 형태로서 딜리버리 메소드(delivery method)가 구별될 수 있다. 도37은 MPD 의 실시예들 중 하나로서 베이스(base) URL을 사용하여 세그먼트 네임(naming)을 정의한 실시예다.
상위 레이어의 베이스 URL은 세그먼트 주소의 앞에 붙는 스트링이며, 레프리젠테이션의 추가 베이스url을 정의 함으로써, 각 레프리젠테이션이 unique하게 정의되는 string이 제공될 수 있다. 베이스url이 딜리버리 메소드를 정의하는 방법으로 사용할 수 있다.
현재 MPD에는 브로드캐스트, 멀티캐스트, 유니캐스트를 정의할 수 있는 방법이 부재한데, 이를 베이스URL의 패턴을 정의하여, 특정 방법에 따라 url의 패턴을 정해주면, MPD는 딜리버리 메소드를 식별할 수 있다. url 패턴의 정의는 IPTV 서비스 초기화 정보에 포함되어 제공될 수 있다. 본 발명의 실시예들에 따른 방송 신호 송수신 장치는 url 정보를 상술한 브로드캐스트 디스커버리 인포메이션 스키마 또는 서비스 디스커버리 인포메이션의 정보에 기반하여 도38내지 도39와 같이 정의할 수 있다. 이러한 정보를 통해, 방송 신호 수신 장치는 딜리버리 메소드를 파악하고, 딜리버리 메소드에 부합하는 버퍼-모델을 갖는 프레임워크를 적용하여 ABR 서비스를 제공할 수 있다.
도38은 싱글 서비스에 대한 서비스 디스커버리 구성을 나타낸다.
서비스 디스커버리 인포메이션은 도메인 네임을 포함하고, 도메인 네임에 대한 서비스 리스트를 포함한다. 서비스 리스트는 서비스 리스트 중 싱글 서비스에 대하여 하위 구성 정보를 도38과 같이 포함할 수 있다.
싱글 서비스는 서비스 로케이션, 텍스츄얼 아이덴티파이어, DVBTriplet을 포함한다. 서비스 로케이션은 IPMulticastABR_address를 포함한다. IPMulticastABR_address는 MABR을 위한 MABR 어드레스, MABR 포트 넘버, 최대대여폭, 서비스상태 를 포함한다. 또한, 서비스 로케이션은 패스트 스타트업을 위한 정보를 포함한다. 패스트 스타트업은 딜리버리 옵션을 포함하고, 딜리버리 옵션에 따라서 스트리밍 정보를 포함할 수 있다. 스트리밍 정보는 스타트업 어드레스, 스타트업 포트 어드레스, MABR 어드레스, MABR 포트 정보를 포함한다. 서비스 로케이션은 딜리버리 모드를 포함한다. 딜리버리 모드는 베이스패턴으로써 ABR 멀티캐스트 비디오를 나타낼 수 있다. 방송 신호 수신 장치는 ABR 멀티캐스트 비디오를 획득하여 소비할 수 있다.
도39는 MPD의 구성을 나타낸다.
MPD는 ABR멀티캐스트 비디오를 위한 베이스URL을 포함한다. MPD의 어답테이션 세트는 컨텐츠 프로텍션, 레프리젠테이션 식별자 별로 레프리젠테이션에 관련된 정보 및 베이스URL를 포함한다. 방송 신호 수신 장치는 베이스URL에 기반하여 ABR 서비스를 제공할 수 있다.
도40은 인터넷 채널을 통합한 서비스를 제공하기 위한 구성을 나타낸다.
도40의 구조도는 도5에서 상술한 구조도에 대응된다. 본 발명의 실시예들에 따른 방송 신호 수신 장치는 오픈 인터넷(open internet) 기반의 네이티브 코드 수신을 통해 지상파, 위성, 케이블 채널과 통합된 채널 가이드를 제공한다. MPEG-2 system 기반의 유럽 방송 표준 DVB 에서는 DVB 시스템 인포메이션(system information)을 사용하여 서비스 디스커버리 방법 및 EPG 정보를 설명한다. 여기서 DVB SI는 NIT(Network information table), BAT(Bouquet Association Table), SDT(Service description Table), EIT(Event information table) 등의 테이블(table)들의 정보를 포함한다.
NIT는 수신 가능한 네트워들을 시그널링한다. NIT는 네트워크의 서비스 디스커버리를 위한 정보를 포함한다. T채널, S채널, C채널을 포함하는 메인 채널망은 인터넷 서비스 디스커버리 정보를 받을 수 있는 경로를 제공한다. 서비스 디스커버리 과정은 이러한 경로를 사용한다. 서비스 디스커버리 정보는 MPEG-DASH 세그먼트(segment) 를 받을 수 있는 MPD 마니페스트(manifest) 접근 주소와 세그먼트를 전송하기 위한 프로토콜을 지원하기 위한 정보들을 포함한다.
도41은 통합 채널 가이드 UI의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 도41과 같이 통합 EPS를 디스플레이하여 사용자에게 UI/UX를 제공할 수 있다.
EPG 정보(41001)는 메인 디바이스의 스크린 상에 디스플레이될 수 있다. 또한, EPG 정보(41001)는 세컨드 디바이스의 스크린 상에 디스플레이될 수 있다. EPG 정보(41001)는 스크린 상의 일부 영역에 표시될 수 있다. EPG 정보(41001)는 사용자가 시청 중인 서비스 데이터에 대한 디스플레이 영역 상에 오버랩 되어 표시될 수 있다. EPG 정보(41001)는 사용자가 시청 중인 서비스 데이터에 대한 디스플레이 영역과 다른 영역에 표시될 수 있다.
EPG 정보(41001)는 채널정보(41002) 및 시간정보(41003)에 기반하여 디스플레이될 수 있다.
채널정보(41002)는 T채널, S채널, C채널 뿐만 아니라 인터넷 채널(41004)을 포함한다. 채널정보(41002)는 통합 채널 정보를 제공할 수 있다. 채널정보(41002)는 로지컬 채널 번호에 기반하여 통합 채널의 번호를 사용자에게 제공할 수 있다. 사용자는 복수의 통합된 채널들을 리니어하게 인식할 수 있다.
시간정보(41003)는 EPG 정보(41001)에 표시되는 정보에 대한 시간을 포함한다. 시간정보(41003)는 현재시간, 과거시간, 미래시간을 모두 포함한다. 시간정보(41003)는 컨텐츠에 대한 시간을 표시하고, 현재 시간에 대한 정보를 UI/UX로 표시할 수 있다.
프로그램 정보(41005)는 채널(41002)에 포함된 프로그램을 나타낸다. 프로그램 정보(41005)는 시간정보(41003)에 기반하여 표시될 수 있다. 프로그램 정보(41005)는 프로그램에 관련된 정보를 추가로 포함할 수 있다. 프로그램 정보(41005)는 프로그램에 관련된 어플리케이션에 대한 정보(41006)를 포함할 수 있다. 프로그램 정보(41005)는 프로그램에 관련된 부케에 대한 정보(41007)를 포함할 수 있다. 방송 신호 수신 장치는ESG정보에 기반하여 시간 및 채널에 기반한 프로그램을 식별할 수 있고, 프로그램 별로 어플리케이션이 실행 가능하다는 정보를 알려주거나 프로그램 별로 부케가 있다는 정보를 알려줄 수 있다.
도42는 통합 채널 시스템에서 채널 전환 UI 방법을 나타낸다.
도42는 도41의 ESG에 기반하여, 방송 신호 수신 장치가 인터넷 전용 채널 및 기존 TV 채널을 통합하여 하나의 UI/UX를 이용하는 방법을 나타낸다.
채널 가이드 정보 또는 ESG(41001)는 인터넷 채널 및 지상파 채널을 함께 디스플레이할 수 있다.
인터넷 채널의 번호 및 지상파 채널의 번호가 동일한 경우, ESG(41001)는 채널 수신 경로를 표시할 수 있다. 예를 들어, 지상파 채널 및 인터넷 채널 모두 52번 채널을 포함할 수 있다. 도41과 같이, ESG(41001)는 수신 채널의 경로에 따라서 글자의 색을 다르게 표시하거나 텍스트 형태를 다르게 표시할 수 있다.
커넥티드 TV는 해당 프로그램 진행 중 어드밴스드 어플리케이션 서비스를 수신할 수 있다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 어드밴스드 어플리케이션 서비스가 존재함을 EPG정보(41001)를 사용하여 디스플레이할 수 있다. 어플리케이션은 프로그램 시청 중 부가적인 데이터를 통해서 프로그램과 연관된 상품 광고를 제공할 수 있다. 어플리케이션은 연동 채널로 이동할 수 있는 기능을 제공할 수 있다. 어플리케이션은 미리보기 또는 다시보기 등의 리치 미디어를 제공할 수 있다.
EPG정보(41001)는 채널 간 부케(bouquet)라는 정보를 통해 스케일러블 연동서비스를 제공하거나, 다른 언어의 오디오를 제공하는 프로그램을 선택 가능하도록 제공할 수 있다. 사용자는 통합된 EPG 가이드(41001)를 통해 수신되는 채널의 관계없이 다양한 미디어 서비스를 수신할 수 있다.
도42의 디스플레이(42001)는 채널 번호 및 채널의 경로(42002)를 포함한다. 디스플레이(42001)은 인터넷 채널에 대한 52번의 프로그램을 디스플레이한다. 디스플레이(42001)는 프로그램에 관련된 어플리케이션을 실행할 수 있음을 나타내는 정보(42003)를 표시한다.
도42의 디스플레이(42002)는 채널 번호 및 채널의 경로(42005)를 포함한다. 디스플레이(42002)는 지상파 채널에 대한 52번의 프로그램을 디스플레이한다. 디스플레이(42002)는 인터넷 채널에 대한 56번 채널로 이동할 수 있음을 나타내는 정보(42006)를 포함한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 로지컬 채널 넘버52를 사용하여 DVB채널(42005)를 디스플레이할 수 있고, 이와 함께 인터넷 채널 또는 I채널(42002)를 같은 로지컬 채널 넘버52를 사용하여 동시에 디스플레이할 수 있다. DVB채널 및 I채널을 디스플레이하는 실시예는 서비스의 특정조건, 예를 들어, 국가, 지역, 사용자의 선택, 또는 사용자의 선호도 등에 따라서 사용자에게 다르게 제공할 수 있다.
도43은 어답티브 미디어 스트리밍(Adaptive Media Streaming)을 위한 네트워크 구조를 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 IP 기반의 멀티캐스트 네트워크(Multicast Network) 상 어답티브 미디어 스트리밍(adaptive media streaming)을 지원한다. 지원되는 네트워크는 기능별로 다음과 같다.
어답티브 멀티캐스트에 대한 기능적인 측면 및 네트워크의 접속 등을 고려하여, 네트워크는 컨텐츠 네트워크, ABR 멀티캐스트 네트워크, 유저 네트워크 등을 포함한다. 각각의 네트워크는 어답티브 미디어 스트리밍 이외의 다른 기능을 지원하기 위한 부가적인 네트워크를 더 포함할 수 있다.
도44는 네트워크의 종류를 나타낸다.
컨텐츠 네트워크는 컨텐츠의 생성, 수집, 저장을 위한 네트워크이고, 인코더, 패키저, 컨텐트 서버를 포함한다.
ABR 멀티캐스트 네트워크는 IP네트워크를 통한 멀티캐스트 스트림을 전송하기 위한 네트워크이고, 멀티캐스트 센더, 멀티캐스트 리시버, 네트워크 멀티캐스트 컨트롤러를 포함한다.
유저 네트워크는 수신된 멀티캐스트 스트림을 디코딩 및 플레이하기 위한 네트워이고, 게이트웨어, 디코더 디바이스(플레이어)를 포함한다.
도45는 브로드캐스팅에 대한 컨텐츠 네트워크의 구성을 나타낸다.
컨텐츠 네트워크(45001)는 주로 어답티브 멀티캐스트 스트리밍 을 위한 컨텐츠의 생성, 수집, 패키징 등의 기능을 담당할 수 있다. 컨텐츠 네트워크는 다양한 컨텐츠 소스를 포함할 수 있다. 컨텐츠 네트워크는 방송 컨텐츠를 서비스 하기 위해, 지상파 및 케이블 방송등을 서비스 하는 브로드캐스터의 헤드-엔드(45002) 등을 포함 할 수 다.
컨텐츠 네트워크는 지역적으로 떨어진 서비스를 수신하기 위한 위성 수신 네트워크를 포함 할 수 있다. 또한 컨텐츠 네트워크는 미리 저장된 컨텐츠를 서비스 하기 위해 컨텐츠 서버(45003)를 포함 할 수 있으며, 이와 함께, 미디어를 서비스하는 CDN 등을 포함할 수 있다.
이를 위해 컨텐츠 네트워크는 컨텐츠와 관련된 시그널링 메시지, 제어 메시지 등을 생성, 전송 할 수 있다. 컨텐츠와 시그널링, 제어 메시지 등의 적절한 상호동작을 위해 네트워크에 속하는 여러 노드 사이에 별도의 시그널링 또는 제어 메시지가 교환될 수 있으며, 다른 네트워크로 전달되지 않을 수 있다. 이러한 시그널링 및 제어 메시지는 인터널 네트워크 시그널링이라 할 수 있다.
컨텐츠 네트워크는 브로드캐스트의 헤드-앤드를 포함할 수 있다. 브로드캐스터에서 생성된 컨텐츠는 인코딩(45004) 및 패키징(45005)을 거쳐 멀티캐스트 센더(45006)로 전달되어 멀티캐스팅되거나, 컨텐츠 서버(45003)에 저장 되어 필요 시 멀티캐스트 센더로 전달 할 수 있다.
인코더(45004)는 컨텐츠를 인코딩한다.
패키저(Packager, 45005)는 인코딩된 컨텐츠 및 데이터를 멀티캐스트 전송에 적합한 포맷으로 변환 하고, 필요시 수신기 또는 네트워크에 소속된 장치에서 수신할 수 있는 시그널링을 생성할 수 있다. 패키저에서 생성한 미디어 세그먼트는 직접 멀티캐스트 센더(45006)로 전달되어 멀티캐스트될 수 있으나, 해당 세그먼트는가 즉시 전달될 필요가 없는 경우 컨텐츠 서버에 저장된다.
브로드캐스터의 헤드-앤드(45002)는 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있고, 이를위해 컨텐츠 서버 (45003)를 포함할 수 있다. 컨텐츠 서버 (45003)는 3번째 파티 컨텐츠(3 rd party content)를 저장하고 필요 시 멀티캐스트에 활용할 수 있다. 저장되어 있는 컨텐츠 의 경우 별도의 인코딩 과정이 필요 없을 수 있다. 따라서 컨텐츠 서버 (45003)는 컨텐츠를 인코딩 또는 패키징을 거친 미디어 세그먼트 및 파일을 저장해 두고 요청이 있을시, 전송할 수 있다. 실시예들에 따라서 인코딩만 될 수 있으며, 전송하여야 할 네트워크의 형태에 따라 패키징 과정이 필요할 수 있다.
오퍼레이트 컨트롤러(Operator Controller, 45008)는 컨텐츠 프로덕션(Content production, 45007) 및 컨텐츠 서버 (45003) 등을 관리하고, 멀티캐스팅과 관련한 일련의 과정을 적절히 관리, 제어한다. 컨텐츠 네트워크 내의 여러 디바이스 및 노드에 대해 컨트롤 및 시그너링 데이터 를 수집 하고, 필요시 멀티캐스트 네트워크로 전달하여 멀티캐스트 관련 시그널링 및 컨트롤을 가능하게 할 수 있다. 또한 오퍼레이트 컨트롤러(45008)눈 디코더 디바이스 또는 플레이어에서 전달하는 유니캐스트 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다.
도46은 위성의 브로드캐스팅에 대한 컨텐츠 네트워크의 구성을 나타낸다.
지상파 및 케이블 방송등을 서비스 하는 브로드캐스터의 헤드-앤드(46001)는, 지역적으로 떨어진 서비스를 수신하기 위한 위성 수신 네트워크를 포함 할 수 있다. 위성 송신 측 역시 또 다른 브로드캐스터의 헤드-앤드가 될 수 있으며, 이러한 경우 복수의 브로드캐스터의 헤드-앤드가 연결되어 있는 네트워크가 될 수 있다. 위성 시스템을 통해 수신된 컨텐츠는 인코딩 및 패키징을 거쳐 멀티캐스트 센더로 전달되어 멀티캐스팅 되거나, 컨텐츠 서버에 저장 되어 필요 시 멀티캐스트 센더로 전달 할 수 있다.
인코더(Encode, 46002)는 컨텐츠를 인코딩한다. 인코더(46002)는 위성으로 방송 데이터를 중계하기 위한 위성 송신 장치와 연결될 수 있다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 지역적으로 멀리 떨어진 장소에 대한 라이브 방송을 위해서 (ex. 해외 스포츠, 콘서트 중계, 뉴스 등) 위성 송수신 시스템을 도46과 같이 이용할 수 있다. 이를 위해 별도의 위성 송신관련 프로토콜 및 전송 방식을 이용할 수 있다. 위성 송수신 시스템을 거친 데이터는 패키저로 전달된다.
패키저(Packager, 46003) 는 위성 수신기를 통해 수신된 컨텐츠 및 데이터를 멀티캐스트 전송에 적합한 포캣으로 변환 하고, 필요시 수신기 또는 네트워크에 소속된 장치에서 수신할 수 있는 시그널링을 생성할 수 있다. 패키저(46003)가 생성한 미디어 세그먼트는 직접 멀티캐스트 센더 로 전달되어 멀티캐스트 될 수 있으나, 해당 세그먼트가 즉시 전달될 필요가 없는 데이터인 경우에는 컨텐츠 서버에 저장된다.
컨텐츠 서버(Content Server, 46004)는 지역적으로 멀리 떨어진 장소에 대한 라이브 방송시 패키저를 거친 데이터는 곧 바로 멀티캐스트 센더로 전송 되지만, 브로드캐스터의 헤드-앤드는 추후 해당 컨텐츠의 활용을 위해 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있고, 이를위해 컨텐츠 서버를 포함할 수 있다. 따라서 컨텐츠 서버는 컨텐츠를 인코딩 또는 패키징을 거친 미디어 세그먼트 및 파일을 저장해 두고 요청이 있을 시, 전송할 수 있다. 실시예들에 따라서 인코딩만 되어 있는 데이터를 저장할 수 있으며, 전송하여야 할 네트워크의 형태에 따라 패키징과정이 필요할 수 있다.
오퍼레이터 컨트롤러(Operator Controller, 46005)는 컨텐츠 프로덕션 및 컨텐츠 서버 등을 관리하고, 멀티캐스팅과 관련한 일련의 과정을 적절히 관리, 제어한다. 컨텐츠 네트워크 내의 여러 디바이스 및 노드에 대해 컨트롤 및 시그널링 데이터를 수집 하고, 필요시 멀티캐스트 네트워크로 전달하여 멀티캐스트 관련 시그널링 및 컨트롤을 가능하게 할 수 있다. 또한 오퍼레이터 컨트롤러(46005)는 디코더 디바이스나 플레이어에서 전달하는 유니케스트 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다.
도47은 CDN 및 OTT에 대한 컨텐츠 네트워크의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 IP 네트워크를 이용하여 주로 비디오 컨텐츠를 서비스하는 OTT기반의 컨텐츠 네트워크를 고려할 수 있다. 또한, OTT는 효율적인 네트워크 자원의 활용 등을 위해 CDN이 연결 될 수 있다. OTT의 컨텐츠는 인코딩 및 패키징을 거쳐 컨텐츠 서버에 저장되고, 따라서, OTT에서 보유하고 있는 컨텐츠를 직접 멀티캐스트 센더로 전달하여 멀티캐스팅 되거나, CDN을 거쳐 멀티캐스트 센더로 전달 될 수 있다.
인코더(Encoder, 47001)는 컨텐츠의 인코딩을 수행한다. OTT는 라이브 서비스를 제공하거나, 컨텐츠 서버에 저장될 컨텐츠를 제작한다.
패키저(Packager, 47002)는 인코딩된 컨텐츠 및 데이터를 멀티캐스트 전송에 적합한 포맷으로 변환 하고, 필요시 수신기 또는 네트워크에 소속된 장치에서 수신할 수 있는 시그널링을 생성할 수 있다. 패키저가 생성한 미디어 세그먼트는 직접 멀티캐스트 센더로 전달되어 멀티캐스트 될 수 있으나, 해당 세그먼트가 즉시 전달될 필요가 없는 데이터의 경우에는 컨텐츠 서버로 저장된다.
컨텐츠 서버(Content Server, 47003)는 OTT가 서비스할 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 컨텐츠 서버에 저장되는 미디어 데이터는 3rd party content가 될 수 있으며, 필요 시 멀티캐스트에 활용할 수 있다. 저장되어 있는 컨텐츠의 경우 별도의 인코딩 과정이 필요 없다. 따라서 컨텐츠 서버는 컨텐츠를 인코딩 또는 패키징을 거친 미디어 세그먼트 및 파일을 저장해 두고 요청이 있을시, 전송할 수 있다. 실시예들에 따라서 인코딩만 되어 있을 수 있으며, 전송하여야 할 네트워크의 형태에 따라 패키징 과정이 필요할 수 있다.
오퍼레이터 컨트롤러(Operator Controller, 47004)는 컨텐츠 서버(47003)의 멀티캐스팅 및 유니캐스트 데이터 전송 관련한 일련의 과정을 적절히 관리, 제어한다. 오퍼레이터 컨트롤러는 컨텐츠 네트워크 내의 여러 디바이스 및 노드에 대해 컨트롤 및 시그널링 데이터를 수집 하고, 필요시 멀티캐스트 네트워크로 전달하여 멀티캐스트 관련 시그널링 및 컨트롤을 가능하게 할 수 있다. 또한 오퍼레이터 컨트롤러는 디코더 디바이스나 플레이어에서 전달하는 유니캐스트 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다. 오퍼레이터 컨트롤러는 OTT와 CDN에 별도의 컨트롤러로 연결될 수 있고, 서로 커뮤니케이션할 수 있다.
도48은 케이블 네트워크에 대한 ABR 멀티캐스트 네트워크의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 ABR 멀티캐스트 네트워크를 이용할 수 있다. ABR 멀티캐스트 네트워크는 컨텐츠 네트워크로부터 전달된 컨텐츠를 실제 IP 네트워크에서 멀티캐스트 전송하는 네트워크이다. 이때 IP 네트워크는 네트워크 제공자에 의해 QoS 등이 관리되며 비 인가 트래픽이 제한될 수 있는 매니징 네트워크(managed network)와 그렇지 않은 언매니징 네트워크(unmanaged network)를 포함한다.
또한 IP 네트워크는 유선, 무선등의 접속방식에 무관하다. 멀티캐스트를 위한 IP 네트워크를 이용하는데 있어서, 컨텐츠 네트워크와 접속되어 있는 IP 네트워크와 유저 네트워크와 접속하고 있는 IP 네트워크가 다를수 있으며, 이에 대해서는 각각의 네트워크를 제공하는 ISP (Internet Service Provider) 간의 접속 규약을 따를 수 있다. 이러한 경우에도, 멀티캐스트 컨텐츠에 대해 센더와 리시버 사이는 트랜스패런트(transparent)하다. 즉, 센더의 아웃풋 데이터는 네트워크 상의 여러 ISP 네트워크 및 노드를 거치더라도, 리시버의 인풋과 동일하다.
멀티캐스트 네트워크는 실제 멀티캐스트 스트림의 송수신을 위한 네트워크로, 전송되는 네트워크의 특성과는 무관하게, 멀티캐스트 센더(서버), 멀티캐스트 리시버(클라이언트), 멀티캐스트 네트워크 컨트롤러를 포함할 수 있다. 멀티캐스트를 위한 네트워크의 센더 및 리시버의 위치 또는 접속 상태에 따라, 여러 네트워크를 거칠 수 있다. 또한 이에 대해 해당 네트워크 상의 경로에 맞는 별도의 프로토콜을 사용할 수 있다.
멀티캐스트 스트림은 일반적으로 유선 IP 네트워크를 거쳐 전달 될 수 있다. 멀티캐스트 센더와 리시버는 ISP (Internet Service Provider )에서 제공하는 네트워크를 이용 할 수 있다. 실시예들에 따라 복수의 ISP가 관리하는 IP 네트워크가 있을 수 있다. 접속 프로토콜에 따라서 멀티캐스트 센더, 리시버, 컨트롤러, IP 네트워크의 관리 주체가 정해질 수 있다.
멀티캐스트 센더(Multicast sender, 48001)는 각 멀티캐스트 리시버에 컨텐츠 데이터를 전송 한다. 컨텐츠 네트워크로 부터 패키징된 컨테츠(packaged contents)를 수신하여 멀티캐스트 프로토콜을 이용하여 다수의 멀티캐스트 리시버로 전송한다.
멀티캐스트 리시버(Multicast receiver, 48002)는 멀티캐스트 센더가 전송한 컨텐츠 데이터를 수신하고, 이를 플레이할 수 있는 디코더 디바이스에 전달한다. 디코더 디바이스의 효율적인 플레이를 위해 컨텐츠 데이터를 캐쉬(cache)할 수 있다. 실시예들에 따라서, 멀티캐스트 리시버는 디코더 디바이스와 함께 동일한 장치로 구성될 수 있다. 멀티캐스트 리시버는 멀티캐스트 스트림을 유저 네트워크의 게이트웨이 등을 거쳐서 수신할 수 있다. 이때 멀티캐스트 리시버는 유저 네트워크의 구성 요소가 될 수 있다.
멀티캐스트 네트워크 컨트롤러(Multicast network controller, 48003)는 ABR 멀티캐스트 네트워크를 제어한다. 멀티캐스트 네트워크 컨트롤러(48003)는 멀티캐스트 센더(48001)의 컨텐츠 전송 및 관련 세션 정보를 제어하고 각각의 센더 및 리시버에 대한 구성에 관한 시그널링 정보를 관리 및 전달한다. 멀티캐스트 네트워크 컨트롤러(48003)는 멀티캐스트 컨텐츠와 별도의 프로토콜로 구성되고, 각각의 센더 및 리시버와 연결될 수 있다. 센더 및 리시버의 연결을 단순화하기 위해서, 센더에만 연결되고, 리시버로 전송되는 시그널링 정보 등은 컨텐츠 멀티캐스팅 프로토콜을 따를 수 있다.
네트워크 캐쉬(Network Cache, 48004)는 IP 네트워크 내에서, 멀티캐스트 센더 및 리시버 사이에 네트워크 캐쉬 기능을 하는 노드 또는 장치를 의미한다.
네트워크 캐쉬(48004)는 멀티캐스트 전송 시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐츠를 저장하고, 리시버에 스트림을 전달 한다. 실시예들에 따라 멀티캐스트 센더와 캐쉬(cache) 된 컨텐츠에 대한 갱신 절차를 수행할 수 있다.
도49는 모바일 네트워크에 대한 ABR 멀티캐스트 네트워크의 구성을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 모바일 어세스 네트워크(mobile access network)를 이용할 수 있다. 멀티캐스트 스트림은 일반적으로 유선 IP 네트워크를 거쳐 전달 되지만, 모바일 수신기는 추가적으로 모바일 어세스 네트워크를 이용될 수 있다. IP 멀티캐스트를 위해 모바일 어세스 네트워크는 IP 전송을 지원하는 네트워크를 이용한다. 또한 복수의 모바일 수신기에 멀티캐스트 스트림을 서비스 하기 위해 모바일 네트워트 또한 멀티캐스트를 지원할 수 있다.
멀티캐스트 센더(Multicast sender, 49001)는 각 멀티캐스트 리시버에 컨텐츠 데이터를 전송한다. 멀티캐스트 센더(49001)는 컨텐츠 네트워크로부터 패키징된 컨텐츠(packaged contents)를 수신하여 멀티캐스트 프로토콜을 이용하여 다수의 멀티캐스트를 리시버에 전송한다.
멀티캐스트 리시버(Multicast receiver, 49002)는 멀티캐스트 센더(49001)가 전송한 컨텐츠 데이터를 수신 하고, 이를 플레이할 수 있는 디코더 디바이스에 전달한다. 모바일 어세스 네트워크에 접속되어 있는 멀티캐스트 리시버(49002)는 해당 모바일 어세스 네트워크에 대한 무선 신호를 수신할 수 있다. 모바일 어세스 네트워크에 접속되어 있는 멀티캐스트 리시버는 또다른 무선 접속 규격을 통해 디코더 디바이스와 연결 될 수 있다. 이 과정에서, 디코더 디바이스가 효율적인 플레이가 가능하도록 컨텐츠 데이터를 캐취할 수 있다. 실시예들에 따라, 멀티캐스트 리시버는 디코더 디바이스와 함께 동일한 장치로 구성될 수 있다.
멀티캐스트 네트워크 컨트롤러(Multicast network controller, 49003)는ABR 멀티캐스트 트워크를 제어한다. 멀티캐스트 네트워크 컨트롤러(49003)는 멀티캐스트 센더의 컨텐츠 전송 및 관련 세션 정보를 컨트롤하고 각각의 센더 및 리시버에 대한 구성을 위한 시그널링 정보를 관리, 전달 한다. 멀티캐스트 네트워크 컨트롤러(49003)는 멀티캐스트 컨텐츠와는 별도의 프로토콜 로 구성 되어 각각의 센더 및 리시버와 연결 될 수 있다. 센더 및 리시버의 연결 단순화를 위해, 센더에만 커넥션 되고, 리시버로 전송되는 시그널링 정보 등은 컨텐츠 멀티캐스팅 프로토콜을 따를 수 있다.
또한, IP 네트워크와 모바일 어세스 네트워크에 각각 멀티캐스트 컨트롤러가 포함될 수 있고, 해당하는 네트워크에 대한 컨트롤 및 시그널링 정보의 송수신이 가능하다. 각각의 멀티캐스트 컨트롤러에 대해서 별도의 프로토콜을 이용해 멀티캐스트 컨트롤러 간 커뮤니케이션을 수행할 수 있다.
네트워크 캐쉬(Network Cache, 49004)는 멀티캐스트 센더 및 리시버 사이에 네트워크 캐쉬 기능을 하는 노드 또는 장치를 포함할 수 있다. 네트워크 캐쉬는 각각의 네트워크 어디에도 구성될 수 있으며 복수개의 캐쉬로도 구성될 수 있다. 또한, 각각의 네트워크의 일부 노드가 캐쉬 역할을 동시에 수행할 수 있다. 멀티캐스트 전송시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐츠를 저장하고, 리시버에 스트림을 전달 한다. 실시예들에 따라 멀티캐스트 센더와 캐취된 컨텐츠에 대한 갱신 절차를 수행할 수 있다.
도50은 홈 네트워크에 대한 유저 네트워크의 구성을 나타낸다.
유저 네트워크는 멀티캐스트 네트워크를 거친 데이터를 수신하고 이에 대한 컨텐츠를 소비하는 디바이스 사이의 네트워크라 할 수 있다. 유저 네트워크의 구성 및 멀티캐스트를 통한 서비스에 따라 유저 네트워크는 다양하게 구성 될 수 있으며, 멀티캐스트 리시버가 경우에 따라 유저 네트워크의 일부가 될 수 있다. ABR 멀티캐스트 리시버가 유저 네트워크의 일부분으로 구성될 수 있다. 멀티캐스트 리시버가 유저 네트워크 내에 포함된 경우에는 유저 네트워크의 게이트웨이 또는 프록시 역할을 하는 장치를 통해 멀티캐스트 컨텐츠를 수신 할 수 있다. 이러한 경우, 해당 게이트웨이 또는 프록시 는 ABR 멀티캐스트 네트워크의 일부로 간주될 수 있다.
멀티캐스트 리시버는 유저 네트워크 내의 또 다른 서버 또는 센더의 역할을 가질 수 있다. 이로 인해, 유저 네트워크의 다양한 디코더 디바이스에서 멀티캐스트 컨텐츠를 소비 할 수 있으며, 디코더 디바이스에 멀티캐스트 컨텐츠의 수신이 불가한 경우에도 멀티캐스트 스트리밍이 가능하게 한다.
멀티캐스트로 전송되는 데이터는 리시버가 직접 수신 할 수도 있지만, 홈 네트워크에 속해있는 디바이스가 리시버의 역할을 하는 경우에는 홈 게이트웨이를 통해 멀니캐스트 데이터를 수신 할 수 있다.
홈 게이트웨이(Home Gateway, 50001)는 홈 네트워크에 여려 디바이스가 구성되어 있는 경우 ABR 멀티캐스트 네트워크로부터 데이터를 수신할 수 있게 한다. Home GW(50001)는 외부 네트워크와 데이터 송수신을 처리할 수 있고, 프록시의 역할을 동시에 수행할 수 있다. 프록시의 역할을 하는 경우 멀티캐스트 리시버가 수신할 데이터를 캐쉬할 수 있다.
멀티캐스트 리시버(Multicast Receiver, 50002)는 앞서 기술한 ABR 멀티캐스트 네트워크의 구성 요소가 될 수 있으나, 네트워크의 구성상 홈 네트워크의 내부에 위치할 수 있다. 홈 네트워크의 구성에 따라 멀티캐스트 리시버가 프록시 역할을 겸할 수 있다. 멀티캐스트 스트림을 직접 플레이할 수 없는 멀티캐스트 리시버의 경우 해당 스트림을 플레이하는 디코더 디바이스가 추가적으로 연결될 수 있으며, 복수의 디코더 디바이스와 연결되어 멀티캐스트 스트림을 전송할 수 있다.
디코더 디바이스(Decoder Device, 50003)는 멀티캐스트 스트림을 사용자에게 플레이하는 디바이스로 정의할 수 있다. 복수의 디코더 디바이스가 멀티캐스트 리시버에 접속할 수 있으며 유니캐스트 또는 멀티캐스트로 데이터를 송수신 할 수 있다. 디코더 디바이스(50003)는 멀티캐스트 스트림을 수신하는 네트워크 와 별도로 유니캐스트 네트워크에 접속할 수 있으며, 컨텐츠 네트워크 또는 ABR 멀티캐스트 네트워크에 리퀘스트 또는 리포트 등을 전송할 수 있다. 구성에 따라 디코딩 모듈과 스크린 등이 별도의 장치로 구성될 수 있다. 또한 멀티캐스트 리시버와 동일한 장치로 구성될 수 있다.
도51은 어답티브 미디어 스트리밍을 위한 네트워크 구조를 나타낸다.
도51은 Adaptive Media Streaming을 위한 전체 네트워크 구조 예를 보여 준다. 본 발명의 실시예들에 따른 방송 신호 송수신 장치에 대한 노드 또는 엔티티는 논리적인 구성이 될 수 있고, 각각의 노드는 별도의 장치로 구성될 수 있다. 실시예들에 따라 인접 노드와 같은 장치에서 동작하도록 구성될 수 있다. 복수개의 네트워크가 서로 연결될 수 있으며 효율적인 멀티캐스트 스트리밍을 위해 시그널링 및 매니지먼트 정보를 서로 교환할 수 있다.
도52는 어답티브 미디어 스트리밍을 위한 프로토콜을 나타낸다.
프로토콜은 크게 실제 미디어가 전송되는 미디어 프로토콜과, 미디어를 전송하기 위해 각각의 노드 또는 엔티티를 제어하거나, 수신기를 포함하는 여러 노드 및 엔티티에 미디어에 대한 구성 정보를 전송하기 위한 시그널링 프로토콜로 구분할 수 있다. 일반적으로, 시그널링 및 컨트롤 정보는 시그널링 프로토콜을 이용하여 전달 되지만, 수신기가 단일 연결에 의해 미디어 컨텐츠를 수신하는 경우에는 별도의 시그널링 경로가 구성되지 않게 된다. 따라서, 이러한 경우에 미디어 프로토콜을 통해 전달 될 수 있다.
도52는 본 발명의 실시예들에 따른 어답티브 미디어 스트리밍을 위한 프로토콜이다. 도 52는 미디어 컨텐츠를 전달하기 위한 개념적인 프로토콜을 도시한다. 멀티캐스트 리시버가 디코더 (미디어 플레이어)와 동일한 장치 및 모듈로 구성되어 있는 경우에 해당 한다. 이 프로토콜은 컨텐츠 네트워크 에서 생성되거나 서버에 저장되어 있는 미디어 컨텐츠를 사용자의 디코더 디바이스에 전달 하고, 이를 다수의 사용자에게 전달 하기 위해 멀티캐스트로 전송할 수 있다.
어답티브 스트리밍환경에서, 컨텐츠의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 생성된 컨텐츠를 멀티캐스트 전송을 수행하는 노드(node) 및 엔티티(entity) (그림에서는 멀티캐스트 센터)로 전달 하기 위한 프로토콜과, 해당 컨텐츠를 어답티브 스트리밍 형식으로 멀티캐스트 송수신 하는 프로토콜이 정의 될 수 있다. 또한, 컨텐츠 데이터는 여러 노드 또는 엔티티를 거치게 되며 각각의 노드 및 엔티티사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔티티상의 프로토콜은 미디어 전송보다는 데이터를 효율적이면서 실시간으로 다음 노드 로 전달하는 프로토콜을 주로 사용 할 수 있으며, 이러한 프로토콜을 터널링(tunneling) 프로토콜이라 부를 수 있다. 따라서 그림과 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의 될 수 있다. 이때, 터널링 프로토콜의 페이로드로 미디어 컨텐츠가 전달 되지만, 터널링 프로토콜 자체는 해당 미디어 컨텐츠가 어떠한 형식인지 무관하게 동작할 수 있다.
멀티캐스트 센더 에서는 멀티캐스트 리시버에 어답티브 스트리밍을 지원 하는 프로토콜을 정의 할 수 있고, 해당 어답티브 스트리밍 은 다수의 멀티캐스트 리시버로 전달 되기 위해 IP 멀티캐스트 방식이 지원될 수 있다. 어답티브 스트리밍의 프로토콜에 따라 IP 멀티캐스트 또한 TCP/IP 와 UDP/IP 의 조합으로 정의 될 수 있다.
멀티캐스트 리시버가 디코더 및 플레이어를 겸하는 경우에는 IP 멀티캐스트 패킷을 수신하여 어답티브 스트리밍 데이터를 획득하고 해당 데이터에서 미디어 컨텐츠 포맷에 해당 하는 데이터를 디코딩 및 플레이하게 된다.
도53은 어답티브 미디어 스트리밍을 위한 프로토콜을 나타낸다.
도53은 미디어 컨텐츠를 전달 하기 위한 프로토콜에 대한 예시를 나타낸 것이다. 멀티캐스트 리시버와 디코더 (미디어 플레이어)가 별도의 장치 또는 모듈로 구성되어 있는 경우에 해당 한다. 컨텐츠 네트워크에서 생성되거나 서버에 저장되어 있는 미디어 컨텐츠는 멀티캐스트 리시버를 거쳐 사용자의 디코더 디바이스에 전달 하는 것이 목적이며, 이를 다수의 멀티캐스트 리시버 또는 사용자에게 전달 하기 위해 멀티캐스트로 전송 될 수 있다.
어답티브 스트리밍환경에서, 컨텐츠의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 생성된 컨텐츠를 멀티캐스트 전송을 수행하는 노드 또는 엔티티 (그림에서는 멀티캐스트 센더)로 전달 하기 위한 프로토콜과, 해당 컨텐츠를 어답티브 스트리밍형식으로 멀티캐스트 송수신 하는 프로토콜이 정의 될 수 있다. 또한, 컨텐츠 데이터는 여러 노드 또는 엔티티 를 거치게 되며 각각의 노드 및 엔티티 사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔티티 상의 프로토콜은 미디어 전송보다는 데이터를 효율적이면서 실시간으로 다음 노드 로 전달하는 프로토콜을 주로 사용 할 수 있으며, 이러한 프로토콜을 터널링 프로토콜이라 부를 수 있다. 따라서 그림과 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의 될 수 있다. 이때, 터널링 프로토콜의 페이로드로 미디어 컨텐츠가 전달 되지만, 터널링 프로토콜 자체는 해당 미디어 컨텐츠가 어떠한 형식인지 무관하게 동작할 수 있다.
멀티캐스트 센더에서는 멀티캐스트 리시버에 어답티브 스트리밍을 지원 하는 프로토콜을 정의 할 수 있고, 해당 어답티브 스트리밍은 다수의 멀티캐스트 리시버로 전달 되기 위해 IP 멀티캐스트 방식이 지원될 수 있다. 어답티브 스트리밍의 프로토콜에 따라 IP 멀티캐스트 또한 TCP/IP 와 UDP/IP 의 조합으로 정의 될 수 있다.
멀티캐스트 리시버와 디코더 (플레이어) 가 별도의 장치 또는 모듈로 구성되어 있는 경우에는, 멀티캐스트 리시버가 IP 멀티캐스트 패킷을 수신하여 어답티브 스트리밍 데이터를 획득하고 이를 다시 디코더 에게 전달 할 수 있다. 이때 멀티캐스트 리시버와 디코더 사이에는 IP 유니캐스트 프로토콜이 정의 될 수 있다. 멀티캐스트 리시버 가 수신한 컨텐츠 데이터를 다시 IP 유니캐스트 를 통해 디코더 로 전달 되고, 디코더 는 수신된 미디어 컨텐츠 포맷에 해당 하는 데이터를 디코딩 및 플레이하게 된다.
도54는 도52 상의 멀티캐스트 센더에 대한 시그널링 및 제어를 위한 프로토콜을 나타낸다.
도55는 도52상의 멀티캐스트 리시버 및 디코더에 대한 시그널링 및 제어를 위한 프로토콜을 나타낸다.
앞서 기술한 네트워크 구조에서 컨텐츠 네트워크 에 포함되는 오퍼레이터 컨트롤러와 멀티캐스트 네트워크 에 포함되는 네트워크 컨트롤러 사이에 컨트롤 프로토콜이 정의 될 수 있다. 또한 오퍼레이터 컨트롤러에서 적절한 컨트롤및 매니지먼트 메시지를 생성하기 위해 네트워크 컨트롤러는 컨트롤 메시지에 대한 리스폰스 또는 리포트 메시지를 오퍼레이터 컨트롤러로 보낼 수 있다. 따라서, 컨트롤 메시지를 보내기위한 터널링(tunneling) 프로토콜은 양방향으로 구성 될 수 있다. 단일 오퍼레이터 컨트롤러가 여러 멀티캐스트 컨트롤러와 컨트롤 메시지을 송수신 할 수 있다. 또간 각각의 멀티캐스트 네트워크 컨트롤러는 별도의 운영주체에서 관리 될 수 있다.
네트워크 컨트롤러에서 네트워크의 구성 관련 정보는 멀티캐스트 센더 및 멀티캐스트 리시버로 전달 될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 구성 정보 및 네트워크 의 노드 사이의 매핑 정보, 라우팅(routing) 정보 등을 포함 할 수 있다. 또한 오퍼레이터 컨트롤러로부터 수신된 구성 정보등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달 할 수 있다. 이 과정에서, 멀티캐스트 컨트롤러에서 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송되는 프로토콜은 구별될 수 있다.
또한, 하나의 네트워크 컨트롤러에서 다수의 멀티캐스트 센더 및 멀티캐스트 리시버 로 구성 메시지를 전달 하기 위해 IP 멀티캐스트 로 구성될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등이 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행 될 수 있기 때문에 유니캐스트 방식의 프로토콜로 구성될 수 있다. 이러한 일련의 컨트롤, 구성 정보 등은 동적으로 업데이트될 수 있고 즉시 또는 스케쥴링을 통해 전송될 수 있다.
멀티캐스트 리시버는 수신된 어답티브 스트리밍 데이터를 다시 디코더 디바이스에 전송하기 위한 시그널링 프로토콜을 정의 할 수 있다. 이때, 개별 디코더 디바이스에 별도의 정보를 제공하기 위해 IP 유니캐스트 방식의 프로토콜을 정의 할 수 있다. 또한 IP 유니캐스트 방식의 프로토콜을 이용하여 디코더 디바이스가 요청하는 사항에 대한 시그널링 을 전달 할 수 있다. 따라서 멀티캐스트 리시버와 디코더 디바이스사이에 양방향 프로토콜로 정의 될 수 있다.
도56은 도53상의 시그널링 및 컨트롤을 위한 프로토콜을 나타낸다.
도56은 멀티캐스트 네트워크 컨트롤러 가 멀티캐스트 리시버에 직접 접속되지 않고, 멀티캐스트 센더를 거쳐 접속 되어 있는 경우를 나타낸다.
네트워크 컨트롤러 에서 네트워크의 구성 관련 정보는 멀티캐스트 센더 및 멀티캐스트 리시버로 전달 될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 구성 정보 및 네트워크의 노드 사이의 매핑 정보, 라우팅 정보 등을 포함 할 수 있다. 또한 오퍼레이터 컨트롤러 로부터 수신 된 구성 정보등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달 할 수 있다. 그런데 이 경우에서 멀티캐스트 컨트롤러는 멀티캐스트 센더에만 연결되어 있고, 멀티캐스트 리시버와는 연결 되어 있지 않으므로, 멀티캐스트 센더가 네트워크 컨트롤러 에서 멀티캐스트 리시버로 전달되는 구성 메시지를 포워딩해 줄 수 있다. 멀티캐스트 네트워크 컨트롤러에서 구성 관련한 프로토콜 (또는 메시지 세트)은 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송 되는 프로토콜이 구별될 수 있다.
또한, 하나의 네트워크 컨트롤러에서 다수의 멀티캐스트 센더 및 멀티캐스트 리시버로 구성 메시지를 전달 하기 위해 IP 멀티캐스트로 구성될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등이 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행 될 수 있기 때문에 유니캐스트 방식의 프로토콜로 구성될 수 있다. 이러한 일련의 컨트롤, 구성 정보 등은 동적으로 업데이트될 수 있고 즉시 또는 스케쥴링을 통해 전송될 수 있다. 멀티캐스트 리시버에서 멀티캐스트 네트워크 컨트롤러로 전송되는 리포트 등의 정보는 멀티캐스트 센더를 통해 멀티캐스트 네트워크 컨트롤러로 전달 될 수 있으며, 멀티캐스트 센더가 멀티캐스트 리시버에서 네트워크 컨트롤러로 전달되는 리포트 메시지 등을 포워딩해 줄 수 있다. 그외 프로토콜의 동작은 앞서 기술한 도52 의 경우와 동일하다.
도 57은 IP멀티캐스트를 위한 프로토콜 스택을 나타낸다.
도57은 IP 네트워크를 통해 미디어 데이터를 전송하기 위한 프로토콜의 예를 나타낸다. 각 레어어 별로 해당하는 프로토콜및 패킷 포맷이 결정될 수 있으며, 각각의 프로토콜은 독립적으로 구성되거나 상호 동작을 위해 특정 프로토콜끼리 적절히 조합될 수 있다.
인코더는 비디오 및 오디오 데이터를 압축하고 적절한 코덱으로 변환 하여 패키저로 전달 하고 이것은 주로 송신 시스템 내부적인 처리로 이루어 진다. 비디오 및 오디오의 멀티캐스트를 위해, 효율적인 코덱이 사용 될 수 있으며, 비디오 는 HEVC, AVC 등의 코덱이 사용될 수 있고, 오디오는 AAC, AC4, MPEG-H 오디오 코덱 등이 이용될 수 있다.
각각의 코덱은 전송 또는 저장에 적합한 형태로 패키징될 수 있다. 이를 위해서 주로 ISOBMFF, CMAF, MPEG-2 TS 형태의 포맷등이 사용 될 수 있다. 코덱으로 인코딩된 컨텐트 데이터가 패키징이 되는동안 특정 수신기에만 해당 컨텐츠를 플레이할 수 있도록 DRM이 추가될 수 있고, DRM에 사용되는 인증 key값은 별도의 링크 또는 채널을 통해 전달될 수 있다.
파일 형태로 구성된 미디어 데이터는 전송 방식에 따라 FLUTE과 같이 파일을 직접 전송 할 수 있는 프로토콜이 적용될 수 있다. 또한, DASH와 같은 어답티브 스트리밍을 지원 하는 프로토콜이 이용 될 수 있다. FLUTE 또는 DASH의 구성에 따라 하위 레이어의 프로토콜이 구성될 수 있다. 예를 들어 DASH 가 적용되어 있는 경우 하위 레이어 프로토콜로 HTTP가 적용되거나, DASH segment를 파일로 간주 하고 FLUTE이 하위 레이어의 프로토콜로 구성될 수 있다.
IP 멀티캐스트를 위해 상위 프로토콜의 구성에 따라 TCP/IP 또는 UDP/IP가 구성 될 수 있으며, 멀티캐스트 리시버에서 IP multicast group의 가입 등을 관리해 줄 수 있는 IGMP 등이 병행될 수 있다. Layer2 및 Layer1 프로토콜은 각각의 전송 link에 따라 정의 될 수 있다. 즉, Network 상에 구성되는 node 및 entity사이의 link에 따라 최적화 된 프로토콜이 구성 될 수 있다. 예를 들어 LAN 환경에서 Layer 2는 Ethernet, Layer 1은 CSMA/CD 프로토콜로 정의 될 수 있다.
도58은 IP멀티캐스팅을 위한 미디어 딜리버리 방법을 나타낸다.
도58은 앞서 기술한 프로토콜을 기반으로, 미디어 컨텐츠가 전송되는 경로에 따른 프로토콜의 구체적인 실시 예에 대해 나타낸 것이다. 여기에서, 멀티캐스트 리시버는 디코더 (미디어 플레이어)와 동일한 장치 및 모듈로 구성되어 있는 경우에 해당 한다.
서버에서 컨텐츠 를 위한 프로토콜은 주로 미디어 코덱과 파일 포맷을 정의 할 수 있다. 미디어 코덱은 비디오, 오디오또는 그외의 인코딩 포맷 을 가질 수 있고, 비디오 에 대해서는 HEVC, AVC 등의 코덱을 정의 할 수 있고, 오디오에 대해서는 AAC, AC4, MPEG-H 오디오 코덱 등의 포맷을 가질 수 있다. 파일 포맷에 대한 프로토콜의 경우, 코덱 포맷을 파일 형태로 전송 또는 저장 하기 위한 포맷을 정의 할 수 있다. 이를 위해 ISOBMFF, CMAF 등의 파일 포맷을 사용 할 수 있고, 기존 방송 네트워크가 연결 되는 경우에는 MPEG-2 TS의 포맷을 이용하여 전송될 수 있다. 파일 포맷을 전송의 효율화를 위해 복수개의 포맷이 사용될 수 있다.
서버 와 멀티캐스트 센더 사이의 프로토콜은 주로 파일 포맷의 효율적인 전달을 위한 프로토콜을 정의 할 수 있다. 따라서, 서버에서 생성된 컨텐츠의 데이터를 터널링 프로토콜을 이용하여 전달 할 수 있다. 터널링 프로토콜은 주로 RTP 와 같은 실시간 전송 프로토콜을 이용할 수 있고, 그외 해당 네트워크에서 정의 할 수 있는 IP 기반의 또 다른 터널링 프로토콜을 이용 할 수 있다. 이때 기존의 프로토콜을 그대로 이용 하거나, 해당 네트워크에 적합하도록 필드의 정의를 변경할 수 있다. 멀티캐스트 센더에서는 서버로부터 터널링 프로토콜을 이용하여 전달되는 파일을 수신 하기 위해 입력 단에 터널링 프로토콜이 정의 될 수 있다. 이때 터널링 프로토콜을 이용하여 전송되는 파일 포맷은 멀티캐스트 센더에서는 멀티캐스트 리시버로 전달 하여야 할 데이터 이므로, 해당 데이터에 대한 포맷에 무관하게 터널링 프로토콜이 동작할 수 있다.
멀티캐스트 센더와 멀티캐스트 리시버 사이의 프로토콜은 주로 어답티브 스트리밍 을 위한 프로토콜로 정의 될 수 있다. 이러한 프로토콜은 DASH 기반의 프로토콜 로 구성될 수 있으며, 이를 위해 하위 layer 프로토콜은 IP 멀티캐스트를 기반으로 한다. DASH 가 동작하기 위해 HTTP 등의 프로토콜이 함께 구성될 수 있으며, DASH segment가 파일 형태로 간주하게 되는 경우에는 FLUTE 등의 파일 전송 프로토콜이 구성 될 수 있다. 추가로, DASH/HTTP 프로토콜의 효과적인 네트워크상의 커넥션 및 멀티캐스트 전송을 위해 TCP/IP가 구성 될 수 있다.
멀티캐스트 리시버는 멀티캐스트로 전송된 패킷 스트림을 수신하기 위해 TCP/IP 가 구성될 수 있고, 패킷 스트림에 대한 리퀘스트, 수신된 데이터 에 대한 리스폰스 등을 위해 HTTP가 구성될 수 있다. 멀티캐스트 센더에서 DASH를 사용하여 어답티브 스트리밍 하는 경우 DASH 클라이언트가 구성될 수 있다. DASH를 이용하여 어답티브 스트리밍 되는 데이터는 서버에서 송신한 파일 포맷으로 구성 되어 있으므로, 해당 파일 포맷을 식별할 수 있는 파일 포맷 관련 프로토콜과 식별된 미디어 포맷을 디코딩할 수 있는 미디어 코덱이 구성 될 수 있다.
도59는 IP멀티캐스팅을 위한 미디어 딜리버리를 나타낸다.
그림은 앞서 기술한 conceptual protocol을 기반으로, media contents가 전송되는 경로에 따른 protocol의 구체적인 실시 예에 대해 나타낸 것이다. 여기에서, multicast receiver는 decoder (media player)와 별도의 장치 및 module로 구성되어 있는 경우에 해당 한다. 따라서, Multicast receiver는 수신된 multicast stream을 decoder device에 전송하는 과정이 필요하다.
Multicast receiver는 multicast로 전송된 packet stream을 수신하기 위해 TCP/IP 가 구성될 수 있고, packet stream에 대한 request, 수신된 data 에 대한 response 등을 위해 HTTP가 구성될 수 있다. Multicast sender에서 DASH를 사용하여 adaptive streaming 하는 경우 DASH client가 구성될 수 있다. DASH를 이용하여 adaptive streaming 되는 data는 multicast receiver에서 proxy의 역할을 수행하여 이를 다시 decoder device로 전달 할 수 있다. Multicast receiver에 접속되어 있는 decoder device의 수는 한정될 수 있으므로 해당 연결은 unicast 전송을 기반으로 할 수 있다. 따라서, unicast 연결을 위한 HTTP와 TCP/IP protocol로 구성 될 수 있다.
Decoder device에서는 multicast receiver로부터 전송되는 data를 수신 하기 위한 unicast protocol이 구성될 수 있으며, decoder device로 HTTP unicast를 통해 전달된 data는 server에서 송신한 file format으로 구성 되어 있으므로, 해당 file format을 식별할 수 있는 file format 관련 protocol과 식별된 media format을 decoding 할 수 있는 media codec이 구성 될 수 있다.
그 외의 protocol에 대한 동작은 앞서 기술한 실시 예와 동일 하다.
도60은 IP멀티캐스팅을 위한 미디어 딜리버리를 나타낸다.
그림은 앞서 기술한 실시 예에서, DASH segment를 전송하는 protocol 방식이 QUIC (Quick UDP Internet Connections) protocol을 기반으로 하는 실시 예에 대해 나타낸 것이다. TCP/IP를 사용한 multicast 방식은 connection을 수립 하는데 delay가 발생 될 수 있고, streaming data를 즉시 전송하는데 부적합 한 경우가 발생할 수 있다. QUIC 기반의 protocol은 connection 및 flow 제어에 대한 과정을 QUIC에서 담당한다. 또한 QUIC는 HTTP/2를 사용할 수 있으며, 이로인해 기존의 HTTP에서 발생하는 전송 지연을 개선할 수 있으며, UDP/IP를 이용하여 streaming data를 즉시 전송 할 수 있다.
그 외의 protocol에 대한 동작은 앞서 기술한 실시 예와 동일 하다.
도61은 DASH segment 의 구조 및 발생과 파싱 순서를 나타낸다.
DASH 기술이란 다양한 품질의 콘텐트를 일정한 시간단위의 조각으로 잘라 서버에 자장하며, 사용자 디바이스의 미디어 요청 시에 잘려진 데이터 단위를 HTTP 프로토콜을 이용하여 전송한다. 여기서 유동적인 HTTP망 상태를 고려하여 다양한 품질로 서버에 저장되어 있는 미디어 콘텐츠를 선택적으로 전송하게 됨으로써, 사용자는 끊김 없는 적응적 스트리밍 서비스를 받아볼 수 있게 된다.
적응적인 재생을 위해 미디어 콘텐츠를 적당한 크기의 조각으로 나누어 서버에 저장시켜두고, 이렇게 조각난 파일들을 timeline 순서 및 품질의 순서로 가져와서 재생할 것인지에 대한 정보를 별도의 파일로 만들어서 client 에게 전송하는 것을 MPD라 한다. 상기 MPD는 해당 잘려진 세그먼트는 각 URL 을 부여 받게 되고, 언제 요청이 시작되어야 하는지, 어떤 콘텐츠 인지 등의 속성을 작성한 XML문서가 된다. 이에 DASH 최초의 사용자는 서버에 MPD 파일을 요청하게 되고, 전달된 MPD 파일을 통해 서버에 저장되어 있는 해당 파일에 관한 정보를 인식하여 원하는 콘텐츠에 대한 세그먼트 파일을 요청한다.
도62는 DASH segment 의 구조를 나타낸다.
도62은 DASH segment 구조 및 발생 순서에 대한 도면이다. DASH 세그먼트는 전송할 콘텐츠를 미디어 세그먼트로 나누어 일정 duration 동안 재생을 가능하게 하는 전송 오브젝트의 데이터 단위이다. 기본적으로 세그먼트 유형을 나타내는 'styp'박스를 포함하고, 세그먼트 인덱스 정보를 포함하는 'sidx'박스를 포함한다. 또한 fragment단위로 잘려진 미디어 스트림을 포함하고 있는 'mdat'박스와 이에 대한 메타데이터를 담고 있는 'moof'박스를 포함하고 있다. DASH client는 서비스를 요청하기 위해 MPD 파일의 전송을 요청하는 것으로 시작으로 각 segment url을 통해 미디어 segment를 요청한다. media segment 를 디코딩 하기 위해서는 초기화 정보를 담고 있는 Initialization segment 파일을 파싱하여 디코더 초기화를 하고, 요청한 segment 파일을 수신하여 미디어 파싱과 디코딩을 진행하게 된다.
도62와 같이 미디어 재생을 위한 구성요소를 구분 지을 수 있고, 총 3개의 파일이 전송되어야만 재생이 가능하다. 미디어 인코더에서는 전체 재생블럭(MPD+IS+sidx+moof+mdat) 을 위해 mdat을 인코딩하고 인코딩 정보를 포함한 메타데이터 헤더(styp+sidx+moof)를 생성한다. 이후 디코더 초기화 정보인 IS.mp4파일을 생성하고, segment의 url을 부여 MPD에 작성하여 client 에게 전송한다. Client side(Parsing order) 에서는 MPD의 파일부터 수신 받아, 파싱하고 네트워크 상황에 따른 세그먼트를 요청하게 된다.
도63은 DASH segment 의 구조 및 발생과 파싱 순서를 나타낸다.
다양한 품질로 저장된 DASH 세그먼트가 live 타입의 서비스를 제공하거나, 라이브 방송 콘텐츠를 인코딩 하여 데이터를 전송하는 서비스의 경우는 미디어 서비스 framework 전체의 실시간성이 적용 되야 하기 때문에 seamless한 서비스의 구현과 딜레이가 발생할 수 있다. 특히, DASH 프로토콜을 적용한 live 방송시 실시간 콘텐츠를 encoding 과 패킷화를 하는 과정과 실시간 콘텐츠를 파싱하고 디코딩하는 과정에서 딜레이가 발생하여 서비스 시작 시점의 딜레이가 발생할 수 있다. 쉽게 말해, 각 파일을 만들고 각각의 패킷화를 거쳐서 보내게 되면, 패킷의 reception time, parsing을 위해서 전체 패킷이 만들어 질 때까지 기다려야 하는 지연시간이 발생하여, client 는 버퍼링의 시간이 길어진다.
본 발명은, 위에서 언급한 문제점을 해결하기 위해 아래와 같은 방법을 제안한다.
도63와 같이 MPD, IS, sidx, moof, I 를 하나의 building block 으로 만들어 미리 전송을 하는 것을 제안한다. 전송된 MPD는 DASH client 와 unicast로 기존 conventional model에 따라 MPD 전송 및 segment 요청으로 playback 을 실행한다. DASH 프레임워크를 동작하는 동안, 수신된 패킷에서 fast startup을 실행한다. 남은 빌딩 블록의 프레임들은 아래와 같은 방법으로 구성할 수 있다. Moof 헤더가 커버하는 mdat 전체의 프레임을 보내지 않고, I프레임만 전송하여 reception delay를 줄일 수 있고, RAP(Random Access Point)인 I프레임부터 재생을 시작하여 빠른 AV startup을 가능하게 한다. 또한 live의 경우 전체 quality의 세그먼트를 모두 만들지 않고, 네트워크 상황을 고려하거나, Network 사업자가 고려하여 빠른 startup을 가능하게 하는 representation/segment만을 지정하여 light MPD 를 만들어 전송한다. 발생된 light MPD는 수신하여 상기 fast startup building block을 구성 바로 플레이를 시작한다. 이후 다른 quality의 segment 를 proxy 에 수신하여, 세그먼트들의 quality 에 따른 비트스트림 스위칭을 하게 된다. 정리하면, 빠르게 startup할 세그먼트만을 고려하여 전송하여 수신하고 MPD안에도 빠른 startup을 위한 segment 의 확인으로 보다 딜레이를 최소화 할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 도63과 같은 파싱 방법을 통해 Fast AV startup을 위한 media content delivery를 구현할 수 있다.
도64는 DASH segment 의 playback을 위한 user network를 나타낸다.
Client 가 서비스를 받기 위해 proxy에 저장된 DASH 콘텐츠를 요청시, MPD에는 이러한 Fast startup segment mode를 나타내는 내용이 존재하지 않는다. 따라서 해당 컨포넌트에 접근했을 때, 빠르게 접근하기 위한 segment라는 signaling이 필요하다. 하기는 DASH 콘텐츠를 설명하는 MPD에 대해 기술한다.
도65는 MPD 계층적 구조를 나타낸다.
도65의MPD는 요소 및 속성들을 포함한 계층적인 구조로 구성되어 있다. 각 계층에는 미디어 콘텐트에 관한 정보를 담고 있는 요소 및 속성 등이 구조적 기능 및 역할 등을 기술하고 있다. 비디오, 오디오 컨포넌트 레벨에 대한 기술은 Adaptation-Set 부터 기술되고 하나 이상의 Representation entry들을 가지고 있다. Representation은 세그먼트들의 URL 경로를 부여하고, 비트스트팀 스위칭을 진행한다. 상기 representation에는 공통 속성을 나타낼 수 있는 기술자를 포함 할 수 있는데 도66와 같은 기술자를 포함할 수 있다. Common attribute에는 supplemental Property 기술자를 통해 DASH client 에서 해당 representation의 framework 에 필요한 요소를 정의할 수 잇다. 이러한 기술자 형태의 요소는 schemeIdUri로 어떤 동작을 해야 하는지의 attribute를 정의하고, value 속성들을 포함하여 특정 동작에 대한 구체적인 code point가 정의될 수 있다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 MPD구조를 통해 Fast startup segment 를 위한 DASH MPD 확장 구현이 가능하다.
도66은 DASH segment 의 playback을 위한 user network를 나타낸다.
본 발명은 새로운 supplemental Property 기술자의 확장을 통해 representation entry중 빠른 startup이 가능한 representation을 signaling 하는 방법을 정의하고자 한다. 도67을 참조하여 구체적인 시그널링 방법을 설명한다.
도67은 빠른 스타트업을 위한 시그널링 방법을 나타낸다.
도67의 테이블 및 신택스를 참조하면, MPD는 schemeIDUri 엘리먼트를 포함한다. schemeIDUri 엘리먼트는 패스트 스타트업 모드에 대한 URI를 나타낸다. MPD는 value 엘리먼트를 포함한다. value 엘리먼트 패스트 스타트업 모드에 대한 세그먼트 모드를 나타낸다.
도67과 같이, 본 발명의 실시예들에 따른 방송 신호 송수신 장치는 새로운 supplemental Property 기술자의 확장을 통해 representation entry중 빠른 startup이 가능한 representation을 signaling 하는 방법을 제안할 수 있다.
도68은 멀티캐스트 ABR 레퍼런스 구조 모델을 나타낸다.
통상적으로 전송할 media 를 정의하고, Manifest 를 작성 한 후 서비스 제공자가 전송한다. Client 는 Manifest 를 수신 후 DASH model에 따라 적절한 Quality의 representation을 선택 후, 해당 세그먼트의 url을 요청하여 미디어를 수신한다. 앞서 설명 했듯이, Unicast 의 트래픽의 동시 집중과 best effort 망의 네트워크 비트레이트 보장의 이슈로 client 와 인접한 proxy server를 중심으로 하여 multicast 방식을 통해 효율적이고 서비스를 수신 할 수 있다.
도68은 multicast ABR reference architecture model 로서, multicast 를 통한 ABR 서비스 수신 모델을 나타낸다. 다음 순서는 위도면의 framework 를 나타낸다. 1) Content playback(client)는 B 인터페이스인 bootstrap 을 통해 manifest 를 수신, 2) Client 는 Y의 정보(IP 주소, hostname)을 담고 있는 manifest내 정보를 기반 Y 에게 media 를 요청, 3) Y의 정보에 맞도록 X에서는 세그먼트 파일을 Y에게 전송, 4) Y는 manifest 파일과 실제 세그먼트를 비교하여 서비스 시작.
Manifest 에 segment template에 따라 segment가 수신되지만, linear 서비스를 multicast 1대 다의 형태로 전송하기 때문에 해당 representation의 수신이 용이하지 못할 시, representation 선택이 필요하다. Multicast 을 통한 데이터와 동시에 수신 어려운 representation 을 unicast 로 수신 받을 수 있다. 현재 Manifest 에서는 세그먼트에 접근가능한 Url은 하나만 정의하고 있기 때문에, delivery path 에 따른 접근 방법을 정의가 필요하다. 본 발명의 실시예들에 따른 방송 신호 송수신 장치는 delivery path에 대한 정의를 하여 unicast/multicast 망을 동시에 사용하여 하나의 MPD에서 대체망을 사용하여 richmedia 서비스를 수신 할 수 있다. 상기 이슈를 해결하기 위해, MPEG-DASH 의 MPD를 구체화 하고자 한다. 도65의 MPD 에는 baseurl을 두어, segment 를 GET하는 기초가 되는 string을 정의할 수 있다. Delivery method에 따라 baseurl을 manipulation 하여, 해당 representation 이 어느 delivery route에 따라 요청해야 하는지를 알 수 있다.
도69는 Multicast ABR delivery method 에 따른 base url 정의를 나타낸다.
도69는 MPD에 baseUrl 에 delivery method에 따라 정의하는 방법을 구분하였다. 아래와 같이 base pattern을 통해 manifest를 manipulation 하고, 미디어 세그먼트를 경로에 따라 구별 가능한 string을 기반으로 세그먼트를 요청한다.
도70은 segment 접근 URL 구성방법을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 Segment 를 다운로드 하기 위해서 접근 주소를 도70과 같이 정의한다. 통상적으로 multiple base url을 사용하면 alternative 관점에서 접근할 수 있는 base string 들이 정해진다. Base string을 기반으로, segment template를 통해서 Full string을 만들어 낼 수 있다. 그림 2.17의 구성을 기반으로 base string pattern을 만들고, base URL 과 segment template를 통해 segment 를 접근할 수 있는 주소를 만들어 낸다. 실시 예로 도70과 같이 proxy의 multicast 주소와 richmedia 의 unicast 가 multiple base URL 형태로 작성되어 망에 따른 접근이 가능하도록 구성하였다.
도71은 multicast ABR service 아키텍쳐를 나타낸다.
멀티캐스트 ABR 서비스를 위해서 딜리버리 메소드를 제어하는 방법을 설명한다.
도68와 같이 IP 기반 media 서비스 제공 시, unicast 만을 기반한 서비스가 아닌, 패킷 트래픽을 분산 시킬 수 있는 multicast 서비스도 동시에 제공할 수 있다. 이때 ABR streaming 서비스를 제공하기 위한 manifest 파일 내 delivery method를 구분할 수 있는 방법을 도68에 제시하였다. 기존의 manifest 의 구조는 변경하지 않고, baseURL을 통한 delivery method를 정의하여 기존 ABR 서비스에 호환 가능한 방법을 발명하였다.
본 시나리오 기반 MPD에 baseURL string 구분 방법을 제시하였으나, 본 string의 constraint 를 미리 전달할 메시지를 정의해야 한다. multicast gateway, server 에 미리 전달하여 multicast 경로의 string과 unicast 경로의 string을 미리 전달하여, 서비스 시작 시 MPD가 전달 되면 상기 string 들의 경로를 통해 Y function의 operation을 적응적으로 대응할 수 있다. 예를 들어, multicast segment url의 경로가 만료되거나, available한 상태가 아닐 시에, content playback module에서는 round the side 의 형태로 요청하고 새로운 unicast url을 받아와야 하는 과정이 필요하다. 본 과정은 live 시에는 서비스 black out 이슈가 발생할 수 있으며, latency의 증가를 유발하는 방법이 된다. 따라서 MPD 내 통합 delivery method를 정의하여 적응적인 스트리밍 서비스를 소비할 수 있다. 또한 live 서비스시, multicast protocol과 unicast protocol이 다른 이유로 다른 파싱 과정과 capacity에 고려한 다른 버퍼 관리를 수행하기 때문에 delivery 경로의 구분은 중요할 수 있다.
또한 터널 안이나, 트래픽의 이슈로 미디어 세그먼트 손실이 발생 시, repair 를 할 수 있도록 M` 인터 페이스를 통해 멀티캐스트 형태로 데이터를 전달하고, unicast repair 서비스 모듈에서는 데이터를 수신하여 Y 와 unicast 요청 형태로 손실된 미디어 세그먼트를 수신 받을 수 있다. 이 때 Y 는 수신 받은 MPD에서 unicast 경로는 통해 수신 받아 처리해야 하는 동작이므로, 기존 multicast 의 세그먼트 정보와는 구별 될 필요성이 있다.
멀티캐스트의 초기화 과정이나 갱신과정에서 수신하고자 하는 representation 을 구분하기 위해, multicast network controller 는 multicast gateway, server 의 unique and distinguished URL pattern 을 정의하고 해당 pattern 에 따라 MPD 내 representation 을 정의한다.
본 경로를 구분하기 위해, string에 따른 delivery method 를 구분하기 위해, manifest 파일에 정의되는 string을 인식하기 위해 미디어 세그먼트가 전송되기 전 multicast gateway or multicast server 에게 전송해야 할 필요가 있다. 이러한 string은 3GPP에서 사용하는 SDP나, DVB IPTV의 STP, 또는 multicast network controller 나 3 rd party의 주기적인 configuration 정보에 포함되어 본 정보를 전달 할 수 있다. 그 중 첫 번째로, 도71 내, multicast network controller는 multicast gateway, server 에게 서비스의 대한 acquisition, initialization등의 서비스 쿼리 또는 메시지를 전송 할 수 있다. 본 모듈에서 도68에서 정의한 string constraint 를 전송하여 multicast gateway 에서의 동작을 컨트롤 할 수 있다.
도72는 multicast ABR service control message를 나타낸다.
상기 C MR, C MS 인터페이스에서는 multicast server 에서 전송하는 미디어 서비스를 컨트롤하는 메시지를 전송할 수 있고, 도72은 C MR, C MS 에서 전송 가능한 Multicast network control message 로서, multicast gateway or multicast server 에서 제공해야 하는 정보를 정의하였다. 상기 메시지는 RESTful HTTP(S) 의 포맷이 될 수 있다. Multicast media 를 전송하는 M 인터페이스 내 특정 세션 내 control message가 포함되지 않고, 외부 ISP 관리 망이나, 네트워크 사업자가 지정한 multicast service controller 에서 Multicast flow 를 control 하기 위해서는 하기와 같은 접근 정보가 필요하다. 해당 세션의 IP와 port로서 접근이 가능하고, 전송되는 manifest 내 component/adaptation 식별정보나 service entry 식별 정보를 통해, media representation 에 정의된 segment URL 의 string에 접근이 가능하다. 접근 후 multicast / unicast service 를 구별하는 base pattern과 manifest 파일 내 base URL을 매칭하여 미디어 세그먼트가 어떤 경로로 서비스가 가능한지 여부를 알 수 있다. 또한 delivery method를 정의하여 적절한 수신기 동작을 구현하고, round the site 를 하지 않고 바로 서비스 전환이 가능하도록 할 수 있다. 기본적으로 priority 는 optional 동작이며 단말에서 현재 네트워크 환경에 맞는 경로를 선택하는 것이 우선이 된다. 단, service provider 의 특정 목적으로 priority 정보를 제공 시, 현재 server 과 multicast gateway 에서 media segment capacity를 고려한 multicast / unicast 경로의 priority를 정의하여 seamless 한 서비스를 구현할 수 있다. 또한 손실된 패킷을 unicast로 수신해야 할 때 multicast media segment 와 aligned 되어 현재 playout time에 맞는 손실된 패킷을 요청할 수 있다. 각 필드를 설명하면 다음과 같다.
@serviceId는 id 또는 MPD id의 서비스 엔트리 또는 어답테이션 세트에 대응하는 서비스를 나타낸다.
@servicename은 대응하는 서비스의 이름 또는 타이틀을 나타낸다.
@servicestatus는 액티브 또는 인액티브 서비스의 상태를 나타낸다.
@MPDUri는 컴포넌트들에 대한 디스크립션을 포함하는 업데이트된 MPD를 나타낸다. 업데이트된 MPD는 얼터네이티브 어답테이션 세트의 위치를 포함할 수 있다.
@operatoruri는 대응하는 서비스를 식별하는 글로벌리 유니크 URI를 나타낸다.
@originalnetworkid는 오리지날 네트워크의 식별 정보를 나타낸다.
@AITuri는 어플리케이션 트리거를 위한 디스크립션 위치를 나타낸다.
@SIPaddress는 그룹 멀티캐스트 세션의 소스 IP어드레스를 나타낸다.
@dIpAddress는 그룹 멀티캐스트 세션의 데스트니네이션 IP어드레스를 나타낸다.
@sport는 멀티캐스트의 소스포트를 나타낸다.
@dport는 멀티캐스트의 데스트니네이션 포트를 나타낸다.
@Mgateway type은 커넥티드 TV, IP게이트웨이, 엣지 서버와 같은 멀티캐스트 게이트웨이의 디블로이먼트 타입을 나타낸다.
LS는 멀티캐스트 서비스에 속하는 대응하는 미디어 컴포넌트(들)을 포함하는 멀티캐스트 상 전달되는 DASH 레프리젠테이션을 나타낸다.
@tsi는 대응하는 서비스 엔트리 또는 어답테이션 세트의 세션 TSI 값을 나타낸다.
@bw는 최대 밴드위드 값을 나타낸다.
@startTime은 스타트 타임을 나타낸다.
@endTime은 앤드 타임을 나타낸다.
DeliverMethod는 어세스의 멀티캐스트 및 유니캐스트 상 서비스의 컨텐츠에 속하는 트랜스포트 관련 정보의 컨테이너를 나타낸다.
Multicast_service는 멀티캐스트 서비스에 속하는 대응하는 미디어 컴포넌트(들)을 포함하는 멀티캐스트 상 전달되는 DASH 리프리젠테이션을 나타낸다.
BasePattern은 패런트 DASH리프리젠테이션의 DASH미디어 세그먼트를 요청하기 위해 DASH 클라이언트에 의해 사용되는 세그먼트URL의 포션에 대해 매치하기 위한 멀티캐스트ABR수신기에 의해 사용되기 위한 특성 패턴을 나타낸다.
priority는 멀티캐스트 서비스를 제공하기 위한 네트워크 및 캐퍼시티를 고려한 DASH 리프리젠테이션 딜리버리의 우선순위를 나타낸다.
Unicast_service는 유니캐스트 서비스에 속하는 대응하는 미디어 컴포넌트(들)을 포함하는 유니캐스트 상 전달되는 DASH 리프리젠테이션을 나타낸다.
BastPattern은 패런트 DASH리프리젠테이션을 요청하기 위해 DASH클라이언트에 의해 사용되는 세그먼트 URL의 포션에 대해 매치하기 위한 멀티캐스트ABR리시버에 의해 사용되기 위한 특성 패턴을 나타낸다.
priority는 멀티캐스트 서비스를 제공하기 위한 네트워크 및 캐퍼시티를 고려한 DASH리프리젠테이션 딜리버리의 우선순위를 나타낸다.
다음은 멀티캐스트/유니캐스트 다이나믹 할당을 설명한다.
도71의Multicast ABR reference model 에 따라, Multicast service 는 B 를 통해 bootstrapping 되고, B 또는 M 을 통해 DASH MPD 를 획득한다. 수신된 MPD 는 기본적으로 multicast 를 수신할 수 있는 segment information 을 정의하고 있지만, 아래의 use case 에서 추가적인 control 정보를 획득할 속성들이 필요하다. 단계별로 설명하면 다음과 같다.
단계1, Alternative Unicast data acquisition: multicast 수신중 subscribe 의 오류가 생기거나, 트래픽의 급증으로 인해 seamless 한 서비스가 어려운 상황이 발생할 수 있다. multicast/unicast 경로의 dynamic 한 경로 확보가 필요하다.
단계2, Additional service: multicast service 중간에, 사용자 요청에 의해 추가적인 서비스를 요청 할 수 있다. 예를 들어 한국어의 오디오 만 multicast MPD 내에 정의되었다면, 영어의 representation 이 포함된 새로운 component 의 추가가 필요할 수 있다.
단계3, Ad insertion: multicast service 중간에 새로운 광고의 update 가 발생하거나, component 의 update 가 필요한 경우 새로운 정보의 업데이트가 필요하다.
단계4, Alternative multicast gateway 변경: 현재 수신중인 multicast gateway 의 대체나, 접속 위치의 변경으로 새로운 주소를 받아야 할 때 새로운 multicast gateway 의 MPD 를 수신할 수 있다.
단계5, 고화질 컨텐츠 제공: Multicast/unicast 대역 폭을 활용하여 UHD/HD + residual data 을 통해 8k 서비스를 제공할 수 있다.
도72는 상기 use case 에 대해 network level 에서 multicast gateway 로 전달 될 수 있는 메시지이다.
@MPDuri: Multicast gateway 는 기존에 수신했던 MPD 에서 업데이트 된 MPD 를 수신 할 수 있는 uri 를 정의 한다.
@operatoruri: 는 서비스를 제공하는 operator의 unique 한 id 를 나타낸다.
@AITuri: 는 application 진행중 또는 linear 채널에서 추가적인 app 서비스를 trigger 하기 위한 description 의 location 을 나타낸다.
@ Mgateway type: Multicast gateway 는 Deployment type 을 의미한다. connected TV, IP gateway, edge server 등이 될 수 있다.
Service_id, Operatoruri, originalnetworkID 는 서비스의 고유 식별자 역할을 하고, 추가로 TSI 는 MPD 내 adaptation-set 과 aligned 되는 값으로 서비스 내 component 시그널링을 가능하게 한다.
상술한 약자의 풀네임은 다음과 같다. AAC(Advanced Audio Coding), ABR(Adaptive Bit Rate), CDN(Content Delivery(Distribution) Network), CMAF(Common Media Application Format), DASH(Dynamic Adaptive Streaming over HTTP), HTTP(HyperText Transfer Protocol), IGMP(Internet Group Management Protocol), IP(Internet Protocol), ISOBMFF(ISO Base Media File Format), MPEG(Moving Picture Experts Group), OTT(Over The Top), QUIC(Quick UDP Internet Connection), RTCP(RTP Control Protocol), RTP(Real-time Transport Protocol), TCP(Transmission Control Protocol), UDP(User Datagram Protocol).
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 상술한 어답티브 미디어 스트리밍(Adaptive Media Streaming)을 위한 프로토콜을 사용한다. 본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 실시간 IP 멀티캐스트 방송 환경에서 파일기반 멀티케스트 콘텐츠를 전송 시, 초기화(initialization) 및 AV 스타트업(startup) 동작에서 걸리는 시간을 단축할 수 있고, 리니어 IP 어답티브 멀티캐스트(linear IP adaptive multicast) 방송환경에서 파일기반 콘텐츠를 전송 시, 네트워크를 효율적으로 제어할 수 있다. 나아가, 이러한 효과를 위한 제어 정보 등을 상술하였다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는IP 기반의 Multicast 송수신을 위한 network architecture, IP 기반의 Multicast 송수신을 위한 protocol의 구조, 실시간 IP multicast 방송환경에서 파일 기반 멀티미디어 파일 분할 생성 및 전송 boundary 정의, 실시간 IP multicast 방송환경 빠른 startup 을 위한 delivery frame 구조, Multicast control information 의 version 관리 방법, Multicast/Unicast 의 dynamic allocation 시, MPD 의 필요한 constraints 과 delivery route 구별, Multicast gateway 의 deployment mode 의 변경 시. Multicast gateway 의 위치가 변경 시 서비스 초기화 방법 등을 제안한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는 실시간 IP multicast 방송환경 빠른 startup 을 위한 DASH MPD 확장하고, Multicast / unicast dynamic allocation 시나리오를 위한 Multicast control information 확장하는 것을 특징으로 한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 기존의 방송 network, internet, home network 등에 속해있는 device 사이의 multicast 전송을 효과적으로 가능하게 한다. 기존 unicast 전송을 multicast로 전환을 통해 network의 부하 감소시키고, Linear 서비스 및 실시간 라이브 인코딩 시, 네트워크 상황에 따른 DASH live 세그먼트 요청의 딜레이를 해결할 수 있다. 또한, 실시간으로 push 해주는 구조에서 빠른 AV startup의 방법을 제공할 수 있다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 기존 DASH 시나리오를 반영한 IP multicast 실시간 방송이 지닌 문제점, 즉, 전체 movie fragment 를 모두 generating 후 전송을 하는 전송 delay를 해결한다. 빠른 startup를 위해 RAP(Random Access Point)를 가지는 프레임과 초기화 정보를 delivery boundary 로 설정 후 먼저 보내는 구조를 제공한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, 저화질 또는 reception time, decoding time 이 적게 걸리는 미디어 세그먼트를 먼저 전송하는 구조로 빠른 startup을 위한 content generation을 가능하게 한다. 빠른 startup을 위해, delivery layer 부터 application layer까지 가능한 startup object를 구분하는 정보를 추가하여, request 부터 AV startup까지 걸리는 시간을 단축시킨다. 또한 UHD 콘텐츠부터 소비하기 위해 걸리는 버퍼링과 수신딜레이를 줄이고 seamless한 서비스를 가능하게 한다.
본 발명의 실시예들에 따른 방송 신호 송수신 장치는, Multicast/unicast dynamic allocation 을 통해, bandwidth 의 flexibility 를 높이고 사용자에게 seamless 한 서비스를 제공할 수 있다.
도73은 본 발명의 실시예들에 따른 방송 신호 송신 방법을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 송신 방법은 서비스 데이터 및 서비스 데이터를 위한 시그널링 정보를 포함하는 패킷을 생성하고(S73001), 패킷을 인코딩하고(S73002), 패킷을 포함하는 방송 신호를 전송한다(S73003). 도73의 각 단계는 도1의 방송 신호 송신 장치의 구성요소에 따라서 처리될 수 있다.
도74는 본 발명의 실시예들에 따른 방송 신호 수신 방법을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 방법은 방송 신호를 수신하고(S74001), 방송 신호에 포함된 패킷을 파싱하고 단계, 패킷은 서비스 데이터 및 서비스 데이터를 위한 시그널링 정보를 포함하고(S74002), 서비스 데이터 및 시그널링 정보를 디코딩한다(S74003). 도74의 각 단계는 도2의 방송 신호 수신 장치에 의해서 처리된다.
도75는 본 발명의 실시예들에 따른 방송 신호 수신 장치가 서비스를 디스커버리하고, 서비스 가이드를 디스플레이하는 과정을 나타낸다.
본 발명의 실시예들에 따른 방송 신호 수신 장치는 도9에 도시된 시그널링 정보 파싱 과정을 통해서 네트워크 또는 방송 채널에 대한 시그널링 정보를 파싱(S75001)하고, 도10 내지 도16에 도시된 시그널링 정보에 기반하여 인터넷 리니어 채널에 대한 시그널링 정보를 파싱(S75002)하고, 인터넷 리니어 채널에 대한 서비스 데이터를 디스커버리(S75003)한다. 이후, 본 발명의 실시예들에 따른 방송 신호 수신 장치는 시그널링 정보에 기반하여 도41 내지 도42와 같이 인터넷 리니어 채널을 포함하는 방송 채널에 대한 통합된 서비스 가이드 정보를 디스플레이(S75004)한다. 도75의 각 단계는 도2 및 도40에 도시된 방송 신호 수신 장치에 의해서 처리될 수 있다.
본 명세서에서 모듈 또는 유닛은 메모리(또는 저장 유닛)에 저장된 연속된 수행과정들을 실행하는 프로세서들일 수 있다. 전술한 실시예에 기술된 각 단계들은 하드웨어, 소트프웨어, 프로세서들에 의해 수행될 수 있다. 전술한 실시예에 기술된 각 모듈/블락/유닛들은 하드웨어, 소프트웨어, 프로세서로서 동작할 수 있다. 또한, 본 발명이 제시하는 방법들은 코드로서 실행될 수 있다. 이 코드는 프로세서가 읽을 수 있는 저장매체에 쓰여질 수 있고, 따라서 장치(apparatus)가 제공하는 프로세서에 의해 읽혀질 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명이 제안하는 방법을 네트워크 디바이스에 구비된, 프로세서가 읽을 수 있는 기록매체에, 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 이해된다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.
본 명세서에서 장치 및 방법 발명이 모두 언급되고, 장치 및 방법 발명 모두의 설명은 서로 보완하여 적용될 수 있다.
다양한 실시예가 본 발명을 실시하기 위한 최선의 형태에서 설명되었다.
본 발명은 일련의 데이터를 포함하는 방송 신호 제공 분야에서 이용된다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.

Claims (12)

  1. 서비스 데이터 및 상기 서비스 데이터를 위한 시그널링 정보를 포함하는 패킷을 생성하는 단계;
    상기 패킷을 인코딩하는 단계; 및
    상기 패킷을 포함하는 방송 신호를 전송하는 단계; 를 포함하는,
    방송 송신 방법.
  2. 제1항에 있어서,
    상기 시그널링 정보는 상기 방송 신호에 대한 네트워크 정보를 포함하고,
    상기 네트워크 정보는 메인 네트워크 또는 아더 네트워크에 대한 제1식별 정보를 포함하고,
    상기 제1식별 정보가 상기 아더 네트워크를 나타내는 경우,
    상기 네트워크 정보는 인터넷 리니어 채널에 대한 제2식별 정보를 포함하는,
    방송 송신 방법.
  3. 제1항에 있어서,
    상기 시그널링 정보는 인터넷 리니어 채널에 기반하여 전송되고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 획득하기 위한 서비스 디스커버리 정보를 포함하고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 식별하는 URI(Uniform Resource Identifier)정보를 포함하는,
    방송 송신 방법.
  4. 서비스 데이터 및 상기 서비스 데이터를 위한 시그널링 정보를 포함하는 패킷을 생성하는 생성기;
    상기 패킷을 인코딩하는 인코더; 및
    상기 패킷을 포함하는 방송 신호를 전송하는 전송기; 를 포함하는,
    방송 신호 송신 장치.
  5. 제4항에 있어서,
    상기 시그널링 정보는 상기 방송 신호에 대한 네트워크 정보를 포함하고,
    상기 네트워크 정보는 메인 네트워크 또는 아더 네트워크에 대한 제1식별 정보를 포함하고,
    상기 제1식별 정보가 상기 아더 네트워크를 나타내는 경우,
    상기 네트워크 정보는 인터넷 리니어 채널에 대한 제2식별 정보를 포함하는,
    방송 신호 송신 장치.
  6. 제4항에 있어서,
    상기 시그널링 정보는 인터넷 리니어 채널에 기반하여 전송되고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 획득하기 위한 서비스 디스커버리 정보를 포함하고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 식별하는 URI(Uniform Resource Identifier)정보를 포함하는,
    방송 신호 송신 장치.
  7. 방송 신호를 수신하는 단계;
    방송 신호에 포함된 패킷을 파싱하는 단계, 상기 패킷은 서비스 데이터 및 상기 서비스 데이터를 위한 시그널링 정보를 포함함;
    상기 서비스 데이터 및 상기 시그널링 정보를 디코딩하는 단계; 를 포함하는,
    방송 수신 방법.
  8. 제7항에 있어서,
    상기 시그널링 정보는 상기 방송 신호에 대한 네트워크 정보를 포함하고,
    상기 네트워크 정보는 메인 네트워크 또는 아더 네트워크에 대한 제1식별 정보를 포함하고,
    상기 제1식별 정보가 상기 아더 네트워크를 나타내는 경우,
    상기 네트워크 정보는 인터넷 리니어 채널에 대한 제2식별 정보를 포함하는,
    방송 수신 방법.
  9. 제7항에 있어서,
    상기 시그널링 정보는 인터넷 리니어 채널에 기반하여 수신되고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 획득하기 위한 서비스 디스커버리 정보를 포함하고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 식별하는 URI(Uniform Resource Identifier)정보를 포함하는,
    방송 수신 방법.
  10. 방송 신호를 수신하는 튜너;
    방송 신호에 포함된 패킷을 파싱하는 파서, 상기 패킷은 서비스 데이터 및 상기 서비스 데이터를 위한 시그널링 정보를 포함함;
    상기 서비스 데이터 및 상기 시그널링 정보를 디코딩하는 디코더; 를 포함하는,
    방송 신호 수신 장치.
  11. 제10항에 있어서,
    상기 시그널링 정보는 상기 방송 신호에 대한 네트워크 정보를 포함하고,
    상기 네트워크 정보는 메인 네트워크 또는 아더 네트워크에 대한 제1식별 정보를 포함하고,
    상기 제1식별 정보가 상기 아더 네트워크를 나타내는 경우,
    상기 네트워크 정보는 인터넷 리니어 채널에 대한 제2식별 정보를 포함하는,
    방송 신호 수신 장치.
  12. 제10항에 있어서,
    상기 시그널링 정보는 인터넷 리니어 채널에 기반하여 수신되고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 획득하기 위한 서비스 디스커버리 정보를 포함하고,
    상기 시그널링 정보는 상기 인터넷 채널에 대한 서비스 데이터를 식별하는 URI(Uniform Resource Identifier)정보를 포함하는,
    방송 신호 수신 장치.
PCT/KR2019/005400 2018-05-04 2019-05-07 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치 WO2019212318A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP19796648.4A EP3790286A4 (en) 2018-05-04 2019-05-07 BROADCASTING SIGNAL TRANSMISSION DEVICE, BROADCASTING SIGNAL TRANSMISSION METHOD, BROADCASTING SIGNAL RECEPTION METHOD AND BROADCASTING SIGNAL RECEPTION DEVICE

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
KR20180051726 2018-05-04
KR10-2018-0051726 2018-05-04
KR20180062812 2018-05-31
KR10-2018-0062812 2018-05-31
KR10-2018-0067575 2018-06-12
KR20180067575 2018-06-12

Publications (1)

Publication Number Publication Date
WO2019212318A1 true WO2019212318A1 (ko) 2019-11-07

Family

ID=68386621

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/005400 WO2019212318A1 (ko) 2018-05-04 2019-05-07 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치

Country Status (2)

Country Link
EP (1) EP3790286A4 (ko)
WO (1) WO2019212318A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2586637A (en) * 2019-08-30 2021-03-03 British Telecomm Content delivery
CN113300936A (zh) * 2021-02-01 2021-08-24 阿里巴巴集团控股有限公司 Cdn节点、边缘节点的信令适配方法、设备及存储介质
WO2021177630A1 (ko) * 2020-03-05 2021-09-10 엘지전자 주식회사 미디어 처리 장치 및 미디어 처리 방법
US11638057B2 (en) 2019-08-30 2023-04-25 British Telecommunications Public Limited Company Content delivery

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100195633A1 (en) * 2009-02-04 2010-08-05 Nokia Corporation Mapping service components in a broadcast environment
KR20120088810A (ko) * 2009-11-03 2012-08-08 알까뗄 루슨트 기계 단말 기기로부터 복수의 서비스 데이터를 수집하기 위한 방법 및 디바이스
US20120288031A1 (en) * 2011-05-12 2012-11-15 Nokia Corporation Providing Signaling Information in an Electronic Service Guide
KR20160026826A (ko) * 2013-06-27 2016-03-09 엘지전자 주식회사 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
KR20160084832A (ko) * 2014-12-10 2016-07-14 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8549574B2 (en) * 2002-12-10 2013-10-01 Ol2, Inc. Method of combining linear content and interactive content compressed together as streaming interactive video
US8503447B2 (en) * 2007-09-20 2013-08-06 Lg Electronics Inc. Broadcast receiver and channel information processing method
EP3220594A4 (en) * 2014-11-12 2018-04-25 LG Electronics Inc. Broadcast signal transmission apparatus, broadcast signal receiving apparatus, broadcast signal transmission method, and broadcast signal receiving method
KR101789640B1 (ko) * 2014-11-13 2017-11-20 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100195633A1 (en) * 2009-02-04 2010-08-05 Nokia Corporation Mapping service components in a broadcast environment
KR20120088810A (ko) * 2009-11-03 2012-08-08 알까뗄 루슨트 기계 단말 기기로부터 복수의 서비스 데이터를 수집하기 위한 방법 및 디바이스
US20120288031A1 (en) * 2011-05-12 2012-11-15 Nokia Corporation Providing Signaling Information in an Electronic Service Guide
KR20160026826A (ko) * 2013-06-27 2016-03-09 엘지전자 주식회사 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
KR20160084832A (ko) * 2014-12-10 2016-07-14 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2586637A (en) * 2019-08-30 2021-03-03 British Telecomm Content delivery
GB2586637B (en) * 2019-08-30 2022-02-16 British Telecomm Content delivery
US11638057B2 (en) 2019-08-30 2023-04-25 British Telecommunications Public Limited Company Content delivery
WO2021177630A1 (ko) * 2020-03-05 2021-09-10 엘지전자 주식회사 미디어 처리 장치 및 미디어 처리 방법
US11895347B2 (en) 2020-03-05 2024-02-06 Lg Electronics Inc. Media processing device and media processing method
CN113300936A (zh) * 2021-02-01 2021-08-24 阿里巴巴集团控股有限公司 Cdn节点、边缘节点的信令适配方法、设备及存储介质
CN113300936B (zh) * 2021-02-01 2023-04-14 阿里巴巴集团控股有限公司 Cdn节点、边缘节点的信令适配方法、设备及存储介质

Also Published As

Publication number Publication date
EP3790286A4 (en) 2022-02-09
EP3790286A1 (en) 2021-03-10

Similar Documents

Publication Publication Date Title
WO2016140478A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2019212318A1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2016105090A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016140477A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016093586A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2020162712A1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2017007192A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016060422A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016186407A1 (ko) 방송 신호 송수신 장치 및 방법
WO2016076569A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016105100A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016089095A1 (ko) 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2016126116A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016093576A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017014586A1 (ko) 방송 신호 송수신 장치 및 방법
WO2015178690A1 (ko) 방송 신호 송/수신 처리 방법 및 장치
WO2016144031A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016122269A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017209514A1 (ko) 방송 신호 송수신 장치 및 방법
WO2015167200A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016060416A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016108606A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016178549A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016163772A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016108610A1 (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: 19796648

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2019796648

Country of ref document: EP