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

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

Info

Publication number
WO2018174367A1
WO2018174367A1 PCT/KR2017/013069 KR2017013069W WO2018174367A1 WO 2018174367 A1 WO2018174367 A1 WO 2018174367A1 KR 2017013069 W KR2017013069 W KR 2017013069W WO 2018174367 A1 WO2018174367 A1 WO 2018174367A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
media data
network
protocol
media
Prior art date
Application number
PCT/KR2017/013069
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 US16/495,365 priority Critical patent/US20200021867A1/en
Publication of WO2018174367A1 publication Critical patent/WO2018174367A1/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/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/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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • 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/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • 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/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Definitions

  • the present invention relates to an apparatus and method for transmitting and receiving broadcast signals.
  • a multicast transmission scheme for transmitting the same content to a plurality of users is effective because it can take advantage of both the unicast (broadcast) and broadcast (broadcast).
  • the conventional multicast transmission method was possible only within a single network, and multicast service between heterogeneous networks was impossible.
  • AV audio / video
  • An object of the present invention is to improve transmission efficiency in a method and apparatus for transmitting a broadcast signal.
  • Another object of the present invention is to provide a transmission apparatus and method for providing a multicast service in a broadcasting network.
  • a multicast transmission method comprises the steps of receiving media data, packetizing the received media data into media data packets using a transport protocol, and multicasting the media data packets.
  • the media data packets generated by the transport protocol may each include a packet header and a payload, and the packet header may include information on fast startup.
  • the fast startup includes a media presentation description (MPD), an initialization segment file, and an ISO base media file format (ISOBMFF) file. It may be characterized by supporting the presentation of fast media data using a single building block.
  • MPD media presentation description
  • ISOBMFF ISO base media file format
  • the ISOBMFF file may include a segment type box (styp), a segment index box (sidx), and a movie fragment box (moof). And a media data box (mdat), wherein the mdat box may selectively include only I frames of media data.
  • the transmission protocol is a Quick UDP Internet Connections (QUIC) protocol, and whether the packet header supports the fast startup, a representation ID of the media data, a code point And QUIC PTS (presentation time stamp) information.
  • QUIC Quick UDP Internet Connections
  • the MPD may include a descriptor indicating whether a representation belonging to the media data supports fast start-up.
  • An apparatus for transmitting multicast includes a receiver for receiving media data, a packetizer for packetizing the received media data into media data packets using a transmission protocol, and multicasting the media data packets.
  • the media data packets generated by the transport protocol may include a packet header and a payload, and the packet header may include information about a fast startup.
  • the fast startup includes a media presentation description (MPD), an initialization segment file, and an ISO base media file format (ISOBMFF) file. It may be characterized by supporting the presentation of fast media data using a single building block.
  • MPD media presentation description
  • ISOBMFF ISO base media file format
  • the ISOBMFF file may include a segment type box (styp), a segment index box (sidx), and a movie fragment box (moof). And a media data box (mdat), wherein the mdat box may selectively include only I frames of media data.
  • the transmission protocol is a Quick UDP Internet Connections (QUIC) protocol, and whether the packet header supports the fast startup, a representation ID of the media data, a code point And QUIC PTS (presentation time stamp) information.
  • QUIC Quick UDP Internet Connections
  • the MPD may include a descriptor indicating whether a representation belonging to the media data supports fast start-up.
  • the method comprises the steps of: receiving media data packets according to a transport protocol, wherein the media data packets each include a packet header and a payload, and the packet header is a fast startup. And a decoder for acquiring information about the fast startup, decoding the received media data packets to perform fast startup, and the fast startup includes a media presentation description.
  • the ISOBMFF file is a segment type Box (segment type box, styp), segment index box (s eg, an index index box, sidx, a movie fragment box (moof), and a media data box (mdat), wherein the mdat box may selectively include only I frames of media data. Can be.
  • the MPD may include a descriptor indicating whether a representation belonging to the media data supports fast start-up.
  • the ISOBMFF file is a segment type Box (segment type box, styp), segment index box (segment index box, sidx), movie fragment box (movie fragment box, moof), and media data box (media data box, mdat), wherein the mdat box selectively includes only I frames of media data can do.
  • the transmission protocol is a Quick UDP Internet Connections (QUIC) protocol, and whether the packet header supports the fast startup, a representation ID of the media data, a code point And QUIC PTS (presentation time stamp) information, wherein the MPD may include a descriptor indicating whether a representation belonging to the media data supports fast start-up.
  • QUIC Quick UDP Internet Connections
  • playback at the receiver for the multicast service can be started quickly.
  • FIG. 1 is a diagram illustrating a network structure according to an embodiment of the present invention.
  • FIG. 2 illustrates a content network according to an embodiment of the present invention.
  • FIG. 6 illustrates a mobile multicast network according to an embodiment of the present invention.
  • FIG. 7 illustrates a user network according to an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating a protocol for adaptive multicast streaming according to an embodiment of the present invention.
  • FIG. 11 illustrates a protocol for signaling and control messages according to an embodiment of the present invention.
  • FIG. 12 illustrates a protocol for signaling and control messages according to an embodiment of the present invention.
  • FIG. 13 illustrates a protocol for transmitting media data through an IP network according to an embodiment of the present invention.
  • FIG. 14 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
  • FIG. 16 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
  • FIG. 17 shows a DASH transmission scheme according to an embodiment of the present invention.
  • FIG. 18 illustrates a structure of a DASH segment according to an embodiment of the present invention.
  • FIG. 19 illustrates a structure, a generation, and a parsing sequence of a DASH segment according to an embodiment of the present invention.
  • FIG. 23 is a diagram illustrating a network configuration for multicast according to an embodiment of the present invention.
  • FIG. 24 illustrates a process of generating a DASH segment according to an embodiment of the present invention.
  • 25 illustrates a QUIC protocol stack according to an embodiment of the present invention.
  • FIG. 26 illustrates a multicast method to which the QUIC protocol is applied according to an embodiment of the present invention.
  • FIG. 27 illustrates QUIC header extension according to an embodiment of the present invention.
  • FIG. 28 is a diagram illustrating a receiver structure according to an embodiment of the present invention.
  • 29 illustrates a content server, a multicast server and a multicast receiver according to an embodiment of the present invention.
  • FIG. 30 illustrates a method of operating a multicast server according to an embodiment of the present invention.
  • a network for adaptive media streaming includes a content network, an adaptive bit rate (ABR) multicast network, and a user network (User).
  • ABR adaptive bit rate
  • User User
  • Network This is a functional classification of the networks used to support adaptive media streaming in a multicast network based on the Internet Protocol (IP).
  • IP Internet Protocol
  • Each network can also connect to additional networks to support other functions than adaptive media streaming.
  • the content network and the user network may each connect to a unicast network for unicast services.
  • the user network may send a request, report, and feedback for content to be received to the ABR multicast network.
  • the ABR multicast network may send a request, report, and feedback to the content network based on the information received from the user network.
  • the content network may transmit the multicast content and signaling information to the ABR multicast network based on the information received from the ABR multicast network.
  • the ABR multicast network may transmit the received multicast content and signaling information to the user network to provide a multicast service.
  • the content network may be responsible for generating, collecting, and packaging content for adaptive multicast streaming, and may include various content sources.
  • the content network may include a head-end of a broadcaster that serves terrestrial and cable broadcasting to serve broadcast content.
  • the broadcaster head end may include at least one of an encoder for encoding the content generated in the content production, a packager for converting the encoded content, and a content server for storing the content.
  • the content network may further include a satellite receiving network for receiving services produced from geographically remote regions. It may also include a content server to service pre-stored content.
  • the content network may include, together with a content server, a Content Delivery Network (CDN) that serves media delivery. Accordingly, the content network may generate and transmit a signaling message, a control message, and the like related to the content.
  • CDN Content Delivery Network
  • Separate signaling messages or control messages may be exchanged between nodes belonging to the content network for proper interworking of content, signaling messages, control messages, etc., and these messages may not be forwarded to other external networks. have.
  • the signaling message or control message not transmitted to the external network may be referred to as internal network signaling.
  • an encoder included in the broadcaster head-end performs encoding on content.
  • a packager included in the broadcaster head-end may convert encoded content and data into a format suitable for multicast transmission.
  • a format suitable for multicast transmission may be, for example, a media segment created by dividing one content.
  • the packager may generate signaling that can be received by a receiver or a device belonging to a network if necessary.
  • the media segment generated by the packager may be directly transmitted to the multicast sender and multicasted, but may be stored in the content server when the media segment does not need to be delivered immediately.
  • the content server included in the broadcaster head-end may store media data and related signaling.
  • the content server can also store 3rd party content generated by third parties and use it for multicast if necessary.
  • the content network including the satellite relay may include an encoder, a satellite transmitter, a satellite receiver, a packager, a content server, and an operator controller.
  • the head-end of a broadcaster serving terrestrial and cable broadcasting may include a satellite receiving network for receiving services of geographically separated content producers.
  • the satellite transmitting side may be the head-end of another broadcaster.
  • a satellite transmission / reception network to which headends of a plurality of broadcasters are connected may be included in the content network.
  • the content received through the satellite system may be multicasted by encoding and packaging to a multicast sender, or may be stored in a content server and transmitted to a multicast sender when necessary.
  • An encoder of a content network including a satellite relay may perform encoding for content.
  • the encoder may be connected to a satellite transmission device for relaying broadcast data to a satellite.
  • the Satellite Network's Satellite Relay System which includes satellite relay, can be used for live broadcasts to geographically remote locations. For example, overseas sports, concert relaying, news, and the like may be broadcast in real time through the satellite relay system. For this purpose, a separate satellite transmission related protocol and transmission scheme may be used. Data passed through the satellite transmission and reception system is delivered to the packager.
  • a content server of a content network including a satellite relay may store media data and related signaling.
  • the data passed through the packager is sent directly to the multicast sender, but the media can be used for later use of the content at the broadcaster's head-end. Data and signaling related thereto may be stored.
  • the description of the operator controller of the content network including the satellite relay is as described in the previous drawings.
  • a content network including a content delivery network (CDN)
  • CDN can be connected for efficient use of network resources.
  • a content network including a content delivery network (CDN)
  • CDN may include an encoder, a packager, a content server, an operator controller, and a CDN.
  • the content of the OTT can be delivered to the CDN through encoding and packaging.
  • the encoded and packaged content may be stored in the content server and then delivered to the CDN in response to the request for the content.
  • Content delivered to the CDN may be delivered to the multicast sender.
  • the content of the OTT may be delivered to the multicast sender directly without going through the CDN and multicasted.
  • the encoder of the OTT may perform encoding on the content.
  • a live service may be provided or content to be stored in a content server may be produced. Description of the packager of the OTT is as described in the previous figure.
  • the OTT content server may store media data to be serviced by the OTT and signaling related thereto.
  • the content server can also store 3rd party content generated by third parties and use it for multicast if necessary. In this case, the content stored in the content server may not need a separate encoding process. Accordingly, the content server may store the media segment and the file encoding or packaging the content, and transmit the content segment upon request.
  • the encoding result of the media data may be stored in the content server, and a separate packaging process may be required according to the type of the transmission network.
  • OTT's Operator Controller can manage and control a series of processes involving multicast data and unicast data.
  • the operator controller collects control and signaling data for a plurality of devices and nodes in the content network and, if necessary, transmits the control and signaling data to the multicast network. This allows the operator controller to enable the multicast network to perform signaling and control related to the multicast.
  • the operator controller can receive and process unicast information transmitted from a decoding device or a player and use it for multicast.
  • the OTT and CDN may each include a separate operator controller, and the operator controller included in the OTT and the operator controller included in the CDN may communicate with each other.
  • An ABR multicast network is a network that multicasts content delivered from a content network over an IP network.
  • the IP network may correspond to either a managed network where QoS is managed by a network provider and unlicensed traffic is restricted, or an unmanaged network where unauthorized traffic is not restricted.
  • the IP network may be connected in a wired or wireless manner by devices included in a multicast network or a user network.
  • an IP network connected to a content network may be different from an IP network connected to a user network. That is, the content network and the user network may be connected to separate IP networks.
  • separate IP networks may follow a connection protocol between an ISP (Internet Service Provider) providing each network.
  • ISP Internet Service Provider
  • the sender and receiver are transparent for multicast content. That is, the output data of the sender is the same as the input data of the receiver, even though it passes through several ISP networks and nodes on the network.
  • the multicast network for transmitting and receiving the multicast stream may include a multicast sender (server), a multicast receiver (client), and a multicast network controller.
  • the multicast network may include a plurality of networks, depending on the location or connection status of the sender and receiver of the network for multicast. In addition, a separate protocol may be used for each network.
  • Multicast streams can be delivered over a wired IP network.
  • a network provided by an ISP Internet Service Provider
  • ISP Internet Service Provider
  • the multicast stream may be delivered through an IP network managed by a plurality of ISPs, and management entities of the multicast sender, receiver, controller and IP network may be different.
  • the transmission of the multicast stream may follow an access protocol corresponding to each ISP.
  • the multicast sender included in the multicast network may transmit content data to each multicast receiver.
  • the multicast sender may receive packaged content from a content network and transmit the packaged content to a plurality of multicast receivers using a multicast protocol.
  • the multicast receiver included in the multicast network may receive content data transmitted from the multicast sender and deliver the content data to a decoding device capable of playing the content data.
  • the multicast receiver can cache the content data so that the decoding device can play the content data efficiently.
  • the multicast receiver may be configured in the same apparatus as the decoding device.
  • the multicast stream may be received through a gateway of the user network. In such an embodiment, the multicast receiver may be a component of the user network.
  • the network cache included in the multicast network may include a node or a device that caches between the multicast sender and the multicast receiver.
  • the network cache may store a suitable range of content for efficient use of network resources, and deliver a multicast stream to the multicast receiver.
  • the network cache may perform an update procedure for the multicast sender and the cached content.
  • the multicast stream may be delivered over a wired IP network, but for a mobile receiver it may be delivered over a mobile access network.
  • mobile access networks can use networks that support IP transport.
  • the mobile access network may support multicast to serve a multicast stream to a plurality of mobile receivers.
  • the multicast sender included in the multicast network may transmit content data to each multicast receiver.
  • the multicast sender may receive packaged content from a content network and transmit the packaged content to a plurality of multicast receivers using a multicast protocol.
  • the multicast receiver included in the multicast network may receive content data transmitted from the multicast sender and deliver the content data to a decoding device capable of playing the content data.
  • the multicast receiver connected to the mobile access network may receive a radio signal for the mobile access network.
  • the multicast receiver connected to the mobile access network may be connected to the decoding device through a separate wireless access standard.
  • the multicast receiver can cache the content data so that the decoding device can play the content data efficiently.
  • the multicast receiver may be configured in the same apparatus as the decoding device.
  • the multicast network controller included in the multicast network may control content transmission and related session information of the multicast sender.
  • the multicast network controller may manage and transmit signaling information for configuration of each multicast sender and multicast receiver.
  • Such a multicast network controller may be connected to each multicast sender and multicast receiver using a protocol separate from the multicast content.
  • the multicast network controller may be connected only to the multicast sender, and signaling information transmitted to the multicast receiver may follow the same protocol as the multicast content.
  • the IP network and the mobile access network may each include a multicast network controller. In this case, the multicast network controller can transmit and receive control and signaling information about a corresponding network.
  • Each multicast network controller can perform communication between multicast network controllers using a separate protocol.
  • the network cache included in the multicast network may include a node or a device that caches between the multicast sender and the multicast receiver.
  • the network cache may be included in each of a plurality of networks constituting the multicast network, and a plurality of network caches may be included in each network.
  • some nodes of each network may simultaneously perform a cache role.
  • the network cache may store a suitable range of content for efficient use of network resources, and deliver a multicast stream to the multicast receiver.
  • the network cache may perform an update procedure for the multicast sender and the cached content.
  • the multicast receiver may serve as a server or a multicast sender in the user network.
  • the decoding device included in the user network can consume multicast content, and can enable multicast streaming even when the decoding device cannot directly receive the multicast content.
  • FIG. 7 illustrates a user network according to an embodiment of the present invention.
  • a home network may be considered.
  • the multicast receiver may directly receive the data transmitted by the multicast, but the home gateway belonging to the home network may receive the data and transmit the data to the multicast receiver.
  • a decoding device may be defined as a device that plays back and provides a multicast stream to a user.
  • a plurality of decoding devices can connect to the multicast receiver, and the decoding device can transmit and receive data via unicast or multicast.
  • the decoding device may connect to a unicast network in addition to the multicast network that receives the multicast stream.
  • the decoding device may send a request or report or the like to the content network or the ABR multicast network.
  • the decoding module and the display screen may be included in the home network as a separate device in addition to the decoding device.
  • the decoding device can also be configured as a single apparatus with a multicast receiver.
  • the network structure for adaptive media streaming may include a content network, an ABR multicast network, and a user network. Detailed description of each network is as described in the previous drawings.
  • the node or entity defined in the present invention may have a logical configuration, and each node may be configured as a separate device, but may operate in a device such as an adjacent node according to an embodiment. have. As shown, a plurality of networks may be connected to each other and exchange signaling and management information for efficient multicast streaming.
  • a multicast receiver may be comprised of the same devices and modules as a decoder.
  • Media content created in the content network or stored in a server may be delivered to a user's decoding device and may be transmitted in multicast for delivery to a plurality of users.
  • a protocol for delivering content generated to a node and an entity performing multicast transmission and a protocol for multicasting and transmitting the content in the adaptive streaming format may be defined.
  • nodes and entities are shown as multicast senders.
  • content data passes through a plurality of nodes or entities, and an appropriate protocol is required between each node and entity.
  • a protocol on a node or an entity may use a protocol for delivering data to the next node efficiently and in real time, and such a protocol may be referred to as a tunneling protocol.
  • a tunneling protocol may be defined between the server and the multicast sender. At this time, the media content is delivered as a payload of the tunneling protocol, but the tunneling protocol may operate regardless of the format of the media content.
  • a protocol supporting adaptive streaming may be defined for a multicast receiver, and the IP multicast scheme may be applied to the adaptive streaming to be delivered to a plurality of multicast receivers.
  • IP multicast can be defined as a combination of TCP / IP and UDP / IP.
  • the multicast receiver may receive an IP multicast packet to obtain adaptive streaming data, and decode and play data corresponding to a media content format from the data.
  • the multicast receiver may be configured as a device or module separate from the decoder.
  • Media content created in the content network or stored in a server may be delivered to a user's decoding device and may be transmitted in multicast for delivery to a plurality of users.
  • a protocol for delivering content generated to a node and an entity performing multicast transmission and a protocol for multicasting and transmitting the content in the adaptive streaming format may be defined.
  • nodes and entities are shown as multicast senders.
  • content data passes through a plurality of nodes or entities, and an appropriate protocol is required between each node and entity.
  • a protocol on a node or an entity may use a protocol for delivering data to the next node efficiently and in real time, and such a protocol may be referred to as a tunneling protocol.
  • a tunneling protocol may be defined between the server and the multicast sender. At this time, the media content is delivered as a payload of the tunneling protocol, but the tunneling protocol may operate regardless of the format of the media content.
  • a protocol supporting adaptive streaming may be defined for a multicast receiver, and the IP multicast scheme may be applied to the adaptive streaming to be delivered to a plurality of multicast receivers.
  • IP multicast can be defined as a combination of TCP / IP and UDP / IP.
  • 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. That is, the multicast sender may forward a report message or the like transmitted from the multicast receiver to the multicast network controller.
  • the operation of other protocols may be applied in the same manner as the description of the above-described drawings.
  • Media data configured in the form of a file may be applied with a protocol that can directly transfer a file such as FLUTE (File Delivery over Unidirectional Transport) according to a transmission method.
  • a protocol supporting adaptive streaming such as DASH (Dynamic Adaptive Streaming over HTTP) may be used.
  • the lower layer protocol may be applied according to the configuration of FLUTE or DASH. For example, if 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 used as a lower layer protocol.
  • the media delivery protocol illustrates a specific embodiment of the protocol according to a path through which media content is transmitted.
  • the multicast receiver is composed of the same devices and modules as the decoder (media player).
  • FIG. 20 illustrates a user network and an MPD according to an embodiment of the present invention.
  • the client requests the DASH content stored in the proxy to receive the service as shown in the upper part of the figure, there is no content indicating the fast startup segment mode (Fastmode) described in the previous figure in the existing MPD. Therefore, when the client accesses the component, signaling is needed to indicate that it is a fast startup segment, that is, a fast startup segment.
  • the lower part of the figure shows the hierarchical structure of the MPD.
  • MPD is organized in a hierarchical structure including elements and attributes. Within each layer, elements and attributes that contain information about media content describe structural functions and roles. The description of the video and audio component levels is described from Adaptation-Set, which has one or more Representation entries. Representation includes information on URL paths of the segments, and the client may perform bitstream switching between the representations according to network conditions.
  • Adaptive streaming such as DASH and Http Live Streaming (HLS)
  • HLS Http Live Streaming
  • a media segment file that can be transmitted first may be transmitted using an existing multicast model.
  • a manifest (ex. MPD) file can be created to play the media segment file that was sent first. That is, according to the existing multicast model, when the multicast data is cached to the multicast receiver or proxy in the multicast ABR model or the unicast packets that can be received are cached, the multicast receiver is based on a specific point in time. Alternatively, you can create an MPD in the proxy.
  • the segment to be transmitted may be generated according to the inspectionrating order shown and may be transmitted according to the transport block. Since the media segment has a longer segment length as Quality increases, a delay may occur in generating and transmitting an entire segment. Therefore, it is necessary to separately create and transmit a segment that can be quickly started among the segments.
  • data created according to the generated block must be partially packetized according to the transport object and transmitted. To this end, the packet may transmit an object including only I frames capable of RAP, not the entire sequence. As shown, after generating 1,2,3,4,5,6 according to the generating order, the transport object may be configured to include only I frames.
  • QUIC is a UDP-based object transport protocol for a scalable IP-based TV distribution system.
  • QUIC can compensate for the shortcomings of connection long-standing between TCP-based users and servers, and can transfer UDP datagrams using FEC similar to TCP.
  • QUIC can send multiplexed application level data and support multicast with HTTP-based Web-oriented mechanisms. That is, QUIC can support multicast and unicast, respectively.
  • the L1 signaling information may be input to the signaling controller of the receiver.
  • the decoded signal may be input to the link layer interface and parsed by the L2 signaling parser, and the L2 signaling information may be input to the signaling controller.
  • the signaling controller may communicate with a service signaling channel (ssc) processing buffer and a parser, thereby updating a service MAP DB.
  • the service guide (SG) processor may update the service guide DB.
  • the receiver may restore the packet header according to the signaling information input to the signaling controller and receive the IP packet using the IP packet filter.
  • the network switch of the receiver may receive an IP packet through wired or wireless communication, and may receive it through a TCP / IP stack.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

본 발명은 멀티캐스트를 송수신하는 장치 및 방법에 관한 것이다. 본 발명의 일 실시예에 따른 멀티캐스트 송신 장치는, 미디어 데이터를 수신하는 수신부, 상기 수신된 미디어 데이터를 전송 프로토콜을 이용하여 미디어 데이터 패킷들로 패킷화하는 패킷화부, 및 상기 미디어 데이터 패킷들을 멀티캐스팅하는 송신부를 포함하는 멀티캐스트 송신 장치으로써, 상기 전송 프로토콜에 의해 생성되는 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함할 수 있다.

Description

방송 신호 송수신 방법 및 장치
본 발명은 방송 신호를 송수신하는 장치 및 방법에 관한 것이다.
디지털 기술 및 통신 기술의 발전으로 방송, 영화뿐만 아니라 인터넷 및 개인 미디어 등의 다양한 영역에서 오디오/비디오 중심의 멀티미디어 컨텐츠 보급 및 수요가 급속도로 확대되고 있다. 또한, 디스플레이 기술의 발전과 더불어 가정에서의 TV 화면이 대형화 됨에 따라 UHD (Ultra High Definition) 방송 서비스에 대한 논의가 증가되고 있는 추세이다.
방송 서비스와 관련하여, 복수의 사용자에게 동일한 컨텐츠를 전송하는 멀티캐스트 (multicast) 전송 방식은 유니캐스트 (unicast)와 브로드캐스트 (broadcast)의 장점을 모두 활용할 수 있으므로 효과적이다. 하지만, 기존의 멀티캐스트 전송 방식은 단일 네트워크 내에서만 가능했으며 이종망 간의 멀티캐스트 서비스가 불가능한 단점이 있었다. 또한 실시간 IP 멀티캐스트 방송환경에서 파일 기반 멀티캐스트 컨텐츠를 전송하는 경우, 수신기의 초기화 및 AV (audio/video) startup 동작에 긴 시간이 소요되는 단점이 있었다.
본 발명의 목적은, 방송 신호를 전송하는 방법 및 장치에 있어서 전송 효율을 높이는 것이다.
본 발명의 다른 목적은, 멀티캐스트 서비스를 방송망에서 제공하기 위한 전송 장치 및 방법을 제공하는 것이다.
본 발명의 다른 목적은, 멀티캐스트 서비스에 대한 수신기에서의 재생을 신속하게 시작하기 위한 장치 및 방법을 제공하는 것이다.
본 발명의 일 실시예에 따른 멀티캐스트 송신 방법은 미디어 데이터를 수신하는 단계, 상기 수신된 미디어 데이터를 전송 프로토콜을 이용하여 미디어 데이터 패킷들로 패킷화하는 단계, 및 상기 미디어 데이터 패킷들을 멀티캐스팅하는 단계를 포함하고, 상기 전송 프로토콜에 의해 생성되는 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 방법에서 상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 방법에서 상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 방법에서 상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 방법에서 상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 것을 특징으로 할 수 있다.
본 발명의 일 실시예에 따른 멀티캐스트 송신 장치는 미디어 데이터를 수신하는 수신부, 상기 수신된 미디어 데이터를 전송 프로토콜을 이용하여 미디어 데이터 패킷들로 패킷화하는 패킷화부, 및 상기 미디어 데이터 패킷들을 멀티캐스팅하는 송신부를 포함하고, 상기 전송 프로토콜에 의해 생성되는 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 장치에서 상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 장치에서 상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 장치에서 상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 송신 장치에서 상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 것을 특징으로 할 수 있다.
본 발명의 일 실시예에 따른 멀티캐스트 수신 방법은 전송 프로토콜에 따라 미디어 데이터 패킷들을 수신하는 단계, 상기 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함함, 상기 패스트 스타트업에 대한 정보를 획득하고, 수신된 미디어 데이터 패킷들을 디코딩하여 패스트 스타트업을 수행하는 디코더를 포함하고, 상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하고, 상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 수신 방법에서 상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 수신 방법에서 상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 것을 특징으로 할 수 있다.
본 발명의 일 실시예에 따른 멀티캐스트 수신 장치는 전송 프로토콜에 따라 미디어 데이터 패킷들을 수신하는 수신부, 상기 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함함, 상기 패스트 스타트업에 대한 정보를 획득하고, 수신된 미디어 데이터 패킷들을 디코딩하여 패스트 스타트업을 수행하는 디코더를 포함하고, 상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하고, 상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 할 수 있다.
또한 본 발명의 일 실시예에 따른 멀티캐스트 수신 장치에서 상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하고, 상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 것을 특징으로 할 수 있다.
본 발명의 실시예에 따르면, 방송 시스템의 전송 효율을 높일 수 있다.
본 발명의 실시예에 따르면, 이종망 간에 멀티캐스트 서비스를 제공할 수 있다.
본 발명의 실시예에 따르면, 멀티캐스트 서비스에 대한 수신기에서의 재생을 신속하게 시작할 수 있다.
도 1은 본 발명의 일 실시예에 따른 네트워크 구조를 나타낸 도면이다.
도 2는 본 발명의 일 실시예에 따른 컨텐트 네트워크를 나타낸 도면이다.
도 3은 본 발명의 일 실시예에 따른 컨텐트 네트워크가 위성 릴레이 (satellite relay)를 포함하는 경우를 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른 컨텐트 네트워크가 컨텐트 딜리버리 네트워크 (CDN)를 포함하는 경우를 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른 유선 (wired) 멀티캐스트 네트워크를 나타낸 도면이다.
도 6은 본 발명의 일 실시예에 따른 모바일 멀티캐스트 네트워크를 나타낸 도면이다.
도 7은 본 발명의 일 실시예에 따른 유저 네트워크를 나타낸 도면이다.
도 8은 본 발명의 일 실시예에 따른 ABR 멀티캐스트를 위한 네트워크 구조를 나타낸 도면이다.
도 9는 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다.
도 10은 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다.
도 11은 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다.
도 12는 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다.
도 13은 본 발명의 일 실시예에 따른 IP network를 통해 미디어 데이터를 전송하기 위한 프로토콜을 나타낸 도면이다.
도 14는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.
도 15는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.
도 16은 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.
도 17은 본 발명의 일 실시예에 따른 DASH 전송 방식을 나타낸다.
도 18은 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조를 나타낸 도면이다.
도 19는 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조와 생성 및 파싱 순서를 나타낸 도면이다.
도 20은 본 발명의 일 실시예에 따른 유저 네트워크 및 MPD를 나타낸 도면이다.
도 21은 본 발명의 일 실시예에 따른 MPD의 세부 내용을 나타낸 도면이다.
도 22는 본 발명의 일 실시예에 따른 패스트 스타트업을 위한 MPD를 나타낸 도면이다.
도 23은 본 발명의 일 실시예에 따른 멀티캐스트를 위한 네트워크 구성을 나타낸 도면이다.
도 24는 본 발명의 일 실시예에 따른 DASH 세그먼트를 발생하는 과정을 나타낸 도면이다.
도 25는 본 발명의 일 실시예에 따른 QUIC 프로토콜 스택을 나타낸 도면이다.
도 26은 본 발명의 일 실시예에 따른 QUIC 프로토콜을 적용한 멀티캐스트 방법을 나타낸 도면이다.
도 27은 본 발명의 일 실시예에 따른 QUIC 헤더 확장을 나타낸 도면이다.
도 28은 본 발명의 일 실시예에 따른 수신기 구조를 나타낸 도면이다.
도 29는 본 발명의 일 실시예에 따른 컨텐트 서버, 멀티캐스트 서버 및 멀티캐스트 리시버를 나타낸 도면이다.
도 30은 본 발명의 일 실시예에 따른 멀티캐스트 서버의 동작 방법을 나타낸다.
도 31은 본 발명의 일 실시예에 따른 멀티캐스트 리시버의 동작 방법을 나타낸다.
도 1은 본 발명의 일 실시예에 따른 네트워크 구조를 나타낸 도면이다. 도 1에 도시된 바와 같이, 어댑티브 미디어 스트리밍 (Adaptive Media Streaming)을 위한 네트워크는 컨텐트 네트워크 (Content Network), 어댑티브 비트 레이트 (Adaptive Bit Rate, ABR) 멀티캐스트 네트워크 (ABR Multicast Network) 및 유저 네트워크 (User Network)를 포함할 수 있다. 이는 인터넷 프로토콜 (Internet Protocol, IP) 기반의 멀티캐스트 네트워크 (Multicast Network)에서, 어댑티브 미디어 스트리밍을 지원하기 위해 사용되는 네트워크들을 기능별로 구분한 것이다. 또한 각각의 네트워크는 어댑티브 미디어 스트리밍 이외의 다른 기능을 지원하기 위한 부가적인 네트워크에 접속할 수 있다. 예를 들면 컨텐트 네트워크와 유저 네트워크는 유니캐스트 서비스를 위한 유니캐스트 네트워크에 각각 접속할 수 있다.
유저 네트워크는 ABR 멀티캐스트 네트워크에게 수신하고자 하는 컨텐트에 대한 요청(request), 보고 (report), 피드백 (feedback)을 전송할 수 있다. ABR 멀티캐스트 네트워크는 유저 네트워크로부터 수신된 정보에 기초하여 컨텐트 네트워크에게 요청(request), 보고 (report), 피드백 (feedback)을 전송할 수 있다. 컨테트 네트워크는 ABR 멀티캐스트 네트워크로부터 수신된 정보에 기초하여, 멀티 캐스 컨텐트 및 시그널링 정보를 ABR 멀티캐스트 네트워크에게 전송할 수 있다. ABR 멀티캐스트 네트워크는 수신된 멀티 캐스 컨텐트 및 시그널링 정보를 유저 네트워크에게 전송하여 멀티캐스트 서비스를 제공할 수 있다.
도 2는 본 발명의 일 실시예에 따른 컨텐트 네트워크를 나타낸 도면이다. 컨텐트 네트워크 (Content Network)는 어댑티브 멀티캐스트 스트리밍 (adaptive multicast streaming)을 위한 컨텐트의 생성, 수집, 패키징 (packaging) 등의 기능을 담당할 수 있으며, 다양한 컨텐트 소스 (contents source)를 포함할 수 있다. 컨텐트 네트워크는 방송 컨텐트를 서비스 하기 위해, 지상파 (terrestrial) 및 케이블 (cable) 방송 등을 서비스 하는 방송국 (broadcaster)의 헤드 엔드 (head-end)를 포함할 수 있다. 방송국 헤드 엔드는 컨텐트 프로덕션에서 생성된 컨텐트를 인코딩하는 인코더, 인코딩된 컨텐트를 변환하는 packager, 컨텐트를 저장하는 컨텐트 서버 중 적어도 하나를 포함할 수 있다.
또한, 컨텐트 네트워크는 지리적으로 멀리 떨어진 지역으로부터 제작된 서비스를 수신하기 위한 위성 수신 네트워크를 더 포함할 수 있다. 또한 미리 저장된 컨텐트를 서비스 하기 위해 컨텐트 서버 (content server)를 포함 할 수 있다. 컨텐트 네트워크는 컨텐트 서버와 함께, 미디어 전송을 서비스하는 컨텐트 딜리버리 네트워크 (Contents Delivery Network, CDN)를 포함할 수 있다. 따라서 컨텐트 네트워크는 컨텐트와 관련된 시그널링 메시지 (signaling message), 컨트롤 메시지 (control message) 등을 생성 및 전송 할 수 있다.
컨텐트, 시그널링 메시지, 컨트롤 메시지 등의 적절한 상호동작을 위해 컨텐트 네트워크에 속하는 여러 노드들 (nodes) 사이에는 별도의 시그널링 메시지 또는 컨트롤 메시지가 교환될 수 있으며, 이러한 메시지들은 다른 외부 네트워크로 전달되지 않을 수 있다. 이렇게 외부 네트워크로 전달되지 않는 시그널링 메시지 또는 컨트롤 메시지는 인터널 네트워크 시그널링 (internal network signaling)이라 명명할 수 있다.
위에서 설명한 바와 같이, 컨텐트 네트워크에는 브로드캐스터 헤드-엔드 (head-end) 를 포함할 수 있다. 브로드캐스터에서 생성된 컨텐트는 인코딩 및 패키징을 거쳐 멀티캐스트 센더 (multicast sender)로 전달되어 멀티캐스팅 되거나, 컨텐트 서버에 저장 되어 필요 시에 멀티캐스트 센더 (multicast sender)로 전달될 수 있다. 아래에서는 컨텐트 네트워크의 브로드캐스터 헤드-엔드에 포함된 각 구성요소에 대해 설명한다.
먼저, 브로드캐스터 헤드-엔드에 포함된 인코더 (Encoder)는 컨텐트에 대한 인코딩을 수행한다. 브로드캐스터 헤드-엔드에 포함된 패키저 (Packager)는 인코딩된 컨텐트 및 데이터를 멀티캐스트 전송에 적합한 포맷으로 변환할 수 있다. 멀티캐스트 전송에 적합한 포맷은 예를 들어, 하나의 컨텐트를 분할하여 생성된 미디어 세그먼트일 수 있다. 또한 패키저는 필요시 수신기 또는 네트워크에 소속된 장치에서 수신할 수 있는 시그널링을 생성할 수 있다. 패키저에서 생성한 미디어 세그먼트는 직접 멀티캐스트 센더로 전달되어 멀티캐스트될 수 있으나, 해당 미디어 세그먼트가 즉시 전달될 필요가 없는 데이터인 경우에는 컨텐트 서버에 저장될 수 있다. 브로드캐스터 헤드-엔드에 포함된 컨텐트 서버 (Content Server)는 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 컨텐트 서버는 또한 써드 파티에서 생성된 컨텐트 (3rd party content)를 저장하고 필요 시 멀티캐스트에 활용할 수 있다. 여기서, 컨텐트 서버에 저장되어 있는 컨텐트의 경우 별도의 인코딩 과정이 필요 없을 수 있다. 따라서 컨텐트 서버는 컨텐트를 인코딩 또는 패키징한 미디어 세그먼트 및 파일을 저장하고, 전송 요청이 있는 경우 전송할 수 있다. 실시예에 따라서는 미디어 데이터에 대한 인코딩 결과가 컨텐트 서버에 저장될 수도 있으며, 전송 네트워크의 형태에 따라 별도의 패키징 과정이 필요할 수 있다. 브로드캐스터 헤드-엔드에 포함된 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 프로덕션 (Content production) 및 컨텐트 서버 (content server) 등을 관리하고, 멀티캐스팅과 관련한 일련의 과정을 관리 및 제어할 수 있다. 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 네트워크 내의 복수의 디바이스들 및 노드들(nodes)에 대해 컨트롤 및 시그널링 데이터를 수집 하고, 필요한 경우 멀티캐스트 네트워크로 전달할 수 있다. 이를 통해 오퍼레이터 컨트롤러 (Operator Controller)는 멀티캐스트 네트워크가 멀티캐스트와 관련된 시그널링 및 컨트롤을 수행하는 것을 가능하게 할 수 있다. 또한 오퍼레이터 컨트롤러는 디코딩 디바이스나 플레이어(player)로부터 전달되는 유니캐스트 (unicast) 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다.
도 3은 본 발명의 일 실시예에 따른 컨텐트 네트워크가 위성 릴레이 (satellite relay)를 포함하는 경우를 나타낸 도면이다. 위성 릴레이 (satellite relay)가 포함된 컨텐트 네트워크는 인코더, 위성 송신기, 위성 수신기, 패키저 (packager), 컨텐트 서버, 오퍼레이터 컨트롤러를 포함할 수 있다. 지상파 및 케이블 방송 등을 서비스 하는 브로드캐스터의 헤드 엔드 (head-end)는, 지리적으로 떨어진 컨텐트 생산자의 서비스를 수신하기 위한 위성 수신 네트워크를 포함 할 수 있다. 위성 송신 측은 다른 브로드캐스터의 헤드엔드 (head-end)가 될 수 있다. 이러한 경우 복수의 브로드캐스터의 헤드엔드들이 연결되어 있는 위성 송수신 네트워크가 컨텐트 네트워크에 포함될 수 있다. 위성 시스템을 통해 수신된 컨텐트는 인코딩 및 패키징을 멀티캐스트 센더 (Multicast sender)로 전달되어 멀티캐스팅 되거나, 컨텐트 서버 (content server)에 저장되어 필요 시 멀티캐스트 센더 (Multicast sender)로 전달될 수 있다. 위성 릴레이 (satellite relay)가 포함된 컨텐트 네트워크의 인코더는 컨텐트에 대한 인코딩을 수행할 수 있다. 여기서, 인코더는 위성으로 방송 데이터를 중계하기 위한 위성 송신 장치에 연결될 수 있다. 위성 릴레이 (satellite relay)가 포함된 컨텐트 네트워크의 위성 릴레이 시스템 (Satellite Relay System)은 지리적으로 멀리 떨어진 장소에 대한 라이브 방송을 위해서 사용될 수 있다. 예를 들어, 해외 스포츠, 콘서트 중계, 뉴스 등이 위성 릴레이 시스템을 통해 실시간 방송될 수 있다. 이를 위해 별도의 위성 송신 관련 프로토콜 및 전송 방식을 이용할 수 있다. 위성 송수신 시스템을 거친 데이터는 패키저로 전달된다. 위성 릴레이 (satellite relay)가 포함된 컨텐트 네트워크의 패키저에 대한 설명은 이전 도면에서 설명한 바와 같다. 위성 릴레이 (satellite relay)가 포함된 컨텐트 네트워크의 Content Server는 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 지리적으로 멀리 떨어진 장소에 대한 라이브 (live) 방송시 패키저를 거친 데이터는 곧바로 멀티캐스트 센더 (multicast sender)로 전송 되지만, 브로드캐스터의 헤드 엔드 (head-end)에서 해당 컨텐트에 대한 추후 활용을 위해 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 이와 관련된 상세한 설명은 이전 도면에서 설명한 바와 같다. 위성 릴레이 (satellite relay)가 포함된 컨텐트 네트워크의 오퍼레이터 컨트롤러에 대한 설명은 이전 도면에서 설명한 바와 같다.
도 4는 본 발명의 일 실시예에 따른 컨텐트 네트워크가 컨텐트 딜리버리 네트워크 (CDN)를 포함하는 경우를 나타낸 도면이다. IP 네트워크를 이용하여 비디오 컨텐트를 서비스하는 오버더톱 (Over the top, OTT)은 컨텐트 네트워크 (Content Network)의 하나의 실시예로써 고려될 수 있다. OTT의 경우 효율적인 네트워크 자원의 활용 등을 위해 CDN이 연결 될 수 있다. 컨텐트 딜리버리 네트워크 (CDN)를 포함하는 컨텐트 네트워크는 인코더, 패키저, 컨텐트 서버, 오퍼레이터 컨트롤러 및 CDN을 포함할 수 있다. OTT의 컨텐트는 인코딩 및 패키징을 거쳐 CDN에 전달될 수 있다. 또한 인코딩 및 패키징이 수행된 컨텐트는 컨텐트 서버에 저장된 후, 컨텐트에 대한 요청에 대응하여 CDN에 전달될 수 있다. CDN에 전달된 컨텐트는 멀티캐스트 센더로 전달될 수 있다. 실시예에 따라서는 OTT의 컨텐트가 CDN을 거치지 않고 직접 멀티캐스트 센더로 전달되어 멀티캐스트될 수도 있다. OTT의 인코더는 컨텐트에 대한 인코딩을 수행할 수 있다. OTT에서 라이브 (live) 서비스를 제공하거나, 컨텐트 서버 (content server)에 저장될 컨텐트를 제작할 수 있다. OTT의 패키저에 대한 설명은 이전 도면에서 설명한 바와 같다. OTT의 컨텐트 서버 (Content server)에는 OTT에서 서비스할 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 컨텐트 서버는 또한 써드 파티에서 생성된 컨텐트 (3rd party content)를 저장하고 필요 시 멀티캐스트에 활용할 수 있다. 여기서, 컨텐트 서버에 저장되어 있는 컨텐트의 경우 별도의 인코딩 과정이 필요 없을 수 있다. 따라서 컨텐트 서버는 컨텐트를 인코딩 또는 패키징한 미디어 세그먼트 및 파일을 저장하고, 전송 요청이 있는 경우 전송할 수 있다. 실시예에 따라서는 미디어 데이터에 대한 인코딩 결과가 컨텐트 서버에 저장될 수도 있으며, 전송 네트워크의 형태에 따라 별도의 패키징 과정이 필요할 수 있다. OTT의 오퍼레이터 컨트롤러 (Operator Controller)는 멀티캐스트 데이터 및 유니캐스트 데이터와 관련한 일련의 과정을 관리하고 제어할 수 있다. 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 네트워크 내의 복수의 디바이스들 및 노드들(nodes)에 대해 컨트롤 및 시그널링 데이터를 수집 하고, 필요한 경우 멀티캐스트 네트워크로 전달할 수 있다. 이를 통해 오퍼레이터 컨트롤러 (Operator Controller)는 멀티캐스트 네트워크가 멀티캐스트와 관련된 시그널링 및 컨트롤을 수행하는 것을 가능하게 할 수 있다. 또한 오퍼레이터 컨트롤러는 디코딩 디바이스나 플레이어(player)로부터 전달되는 유니캐스트 (unicast) 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다. OTT와 CDN은 각각 별도의 오퍼레이터 컨트롤러를 포함할 수 있으며, OTT에 포함된 오퍼레이터 컨트롤러와 CDN에 포함된 오퍼레이터 컨트롤러는 상호 커뮤니케이션이 가능하다.
ABR 멀티캐스트 네트워크는 컨텐트 네트워크로부터 전달된 컨텐트를 IP network를 통해 멀티캐스트하는 너트워크이다. 여기서 IP network는 네트워크 제공자에 의해 QoS 등이 관리되며 비인가(Unauthorized) 트래픽이 제한될 수 있는 managed network 와 비인가 트래픽이 제한되지 않는 unmanaged network 중 어느 하나에 해당할 수 있다. 또한 IP network는 멀티캐스트 네트워크 또는 유저 네트워크에 포함된 디바이스들에 의해 유선 또는 무선 등의 접속방식으로 접속될 수 있다. 멀티캐스트를 위한 IP network를 이용하는데 있어서, 컨텐트 네트워크와 접속되어 있는 IP network는 유저 네트워크와 접속하고 있는 IP network와 다를 수 있다. 즉, 컨텐트 네트워크와 유저 네트워크는 각각 별도의 IP network와 접속할 수 있다. 이러한 경우, 별도의 IP network들은 각각의 network를 제공하는 ISP (Internet Service Provider) 간의 접속 규약을 따를 수 있다. 이러한 경우에도, 멀티캐스트 컨텐트에 대해 sender 와 receiver 사이는 transparent 하다. 즉, sender의 출력 데이터 (output data)는 network 상의 여러 ISP network 및 노드(node)를 거치더라도, receiver의 입력 데이터 (input data)와 동일하다.
멀티캐스트 스트림의 송신 및 수신을 위한 멀티캐스트 네트워크는 multicast sender (server), multicast receiver (client), multicast network controller를 포함할 수 있다. 멀티캐스트 네트워크는 멀티캐스트를 위한 네트워크의 sender 및 receiver의 위치 또는 접속 상태에 따라, 복수의 네트워크를 포함할 수 있다. 또한 이에 대해 각 network에 따라 별도의 protocol을 사용할 수도 있다.
도 5는 본 발명의 일 실시예에 따른 유선 (wired) 멀티캐스트 네트워크를 나타낸 도면이다. 멀티캐스트 스트림은 유선 IP network를 통해 전달될 수 있다. Multicast sender와 Multicast receiver 사이에는 ISP (Internet Service Provider)에서 제공하는 network를 이용할 수 있다. 실시예에 따라 멀티캐스트 스트림은 복수의 ISP에서 관리하는 IP network를 통해 전달될 수 있으며, Multicast sender, receiver, controller 와 IP network의 관리 주체가 다를 수 있다. 이 경우 멀티캐스트 스트림의 전송은 각 ISP에 대응하는 접속 protocol을 따를 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 센더 (Multicast sender)는 각 멀티캐스트 리시버 (multicast receiver)에 컨텐트 데이터 (contents data)를 전송할 수 있다. 멀티캐스트 센더 (Multicast sender)는 컨텐트 네트워크 (Content Network)로 부터 패키징된 컨텐트 (packaged content)를 수신하고, 멀티캐스트 프로토콜 (multicast protocol)을 이용하여 복수의 multicast receiver로 전송할 수 있다. 멀티캐스트 네트워크에 포함된 멀티캐스트 리시버 (Multicast receiver)는 멀티캐스트 센더에서 전송한 컨텐트 데이터를 수신하고, 이를 재생할 수 있는 디코딩 디바이스 (decoding device)에 컨텐트 데이터를 전달할 수 있다. 디코딩 디바이스가 컨텐트 데이터를 효율적으로 재생할 수 있도록, 멀티캐스트 리시버는 컨텐트 데이터를 캐쉬(cache)할 수 있다. 실시예에 따라, 멀티캐스트 리시버는 디코딩 디바이스와 동일한 장치 내에서 구성될 수 있다. 또한 실시예에 따라서는, 멀티캐스트 스트림을 유저 네트워크의 게이트웨이 (Gateway)를 통해 수신할 수도 있다. 이러한 실시예에서는 멀티캐스트 리시버가 유저 네트워크의 구성 요소가 될 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 네트워크 컨트롤러 (Multicast network controller)는 멀티캐스트 센더의 컨텐트 전송 및 관련 세션 (session) 정보를 제어할 수 있다. 또한 멀티캐스트 네트워크 컨트롤러는 각각의 멀티캐스트 센더 및 멀티캐스트 리시버에 대한 배치(configuration)을 위한 시그널링 정보를 관리 및 전달할 수 있다. 이러한 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 컨텐트와는 별도의 프로토콜을 이용하여 각각의 멀티캐스트 센더 및 멀티캐스트 리시버와 연결될 수 있다. 또한 실시예에 따라 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 센더에만 연결되고, 멀티캐스트 리시버로 전송되는 시그널링 정보는 멀티캐스트 컨텐트와 동일한 프로토콜을 따를 수 있다.
멀티캐스트 네트워크에 포함된 네트워크 캐쉬 (Network Cache)는 멀티캐스트 센더와 멀티캐스트 리시버 사이에 캐쉬 기능을 하는 노드 또는 장치를 포함할 수 있다. 네트워크 캐쉬는 멀티캐스트 전송시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐트를 저장하고, 멀티캐스트 리시버에 멀티캐스트 스트림을 전달할 수 있다. 실시예에 따라, 네트워크 캐쉬는 멀티캐스트 센더와 캐쉬된 컨텐트에 대한 갱신 절차를 수행할 수 있다.
도 6은 본 발명의 일 실시예에 따른 모바일 멀티캐스트 네트워크를 나타낸 도면이다. 멀티캐스트 스트림은 유선 IP network를 통해 전달될 수 있지만, 모바일 수신기에 대해서는 모바일 억세스 네트워크 (mobile access network)를 통해 전달될 수 있다. IP multicast를 위해 모바일 억세스 네트워크는 IP 전송을 지원하는 네트워크를 이용할 수 있다. 또한 모바일 억세스 네트워크는 복수의 모바일 수신기에 멀티캐스트 스트림을 서비스 하기 멀티캐스트를 지원 할 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 센더 (Multicast sender)는 각 멀티캐스트 리시버 (multicast receiver)에 컨텐트 데이터 (contents data)를 전송할 수 있다. 멀티캐스트 센더 (Multicast sender)는 컨텐트 네트워크 (Content Network)로 부터 패키징된 컨텐트 (packaged content)를 수신하고, 멀티캐스트 프로토콜 (multicast protocol)을 이용하여 복수의 멀티캐스트 리시버로 전송할 수 있다. 멀티캐스트 네트워크에 포함된 멀티캐스트 리시버 (Multicast receiver)는 멀티캐스트 센더에서 전송한 컨텐트 데이터를 수신하고, 이를 재생할 수 있는 디코딩 디바이스 (decoding device)에 컨텐트 데이터를 전달할 수 있다. 모바일 억세스 네트워크에 접속되어 있는 멀티캐스트 리시버는 해당 모바일 억세스 네트워크에 대한 무선 신호를 수신할 수 있다. 실시예에 따라, 모바일 억세스 네트워크에 접속되어 있는 멀티캐스트 리시버는 별도의 무선 접속 규격을 통해 디코딩 디바이스와 연결 될 수 있다. 디코딩 디바이스가 컨텐트 데이터를 효율적으로 재생할 수 있도록, 멀티캐스트 리시버는 컨텐트 데이터를 캐쉬(cache)할 수 있다. 실시예에 따라, 멀티캐스트 리시버는 디코딩 디바이스와 동일한 장치 내에서 구성될 수 있다.
멀티캐스트 네트워크에 포함된 멀티캐스트 네트워크 컨트롤러 (Multicast network controller)는 멀티캐스트 센더의 컨텐트 전송 및 관련 세션 (session) 정보를 제어할 수 있다. 또한 멀티캐스트 네트워크 컨트롤러는 각각의 멀티캐스트 센더 및 멀티캐스트 리시버에 대한 배치(configuration)을 위한 시그널링 정보를 관리 및 전달할 수 있다. 이러한 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 컨텐트와는 별도의 프로토콜을 이용하여 각각의 멀티캐스트 센더 및 멀티캐스트 리시버와 연결될 수 있다. 또한 실시예에 따라 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 센더에만 연결되고, 멀티캐스트 리시버로 전송되는 시그널링 정보는 멀티캐스트 컨텐트와 동일한 프로토콜을 따를 수 있다. 또한, IP 네트워크와 모바일 억세스 네트워크는 각각 멀티캐스트 네트워크 컨트롤러를 포함할 수 있다. 이 경우 멀티캐스트 네트워크 컨트롤러는 해당하는 네트워크에 대한 제어 및 시그널링 정보의 송수신이 가능하다. 각각의 멀티캐스트 네트워크 컨트롤러는 별도의 프로토콜을 이용해 멀티캐스트 네트워크 컨트롤러 간 통신 (communication)을 수행할 수 있다.
멀티캐스트 네트워크에 포함된 네트워크 캐쉬 (Network Cache)는 멀티캐스트 센더와 멀티캐스트 리시버 사이에 캐쉬 기능을 하는 노드 또는 장치를 포함할 수 있다. 네트워크 캐쉬는 멀티캐스트 네트워크를 구성하는 복수의 네트워크 각각에 포함될 수 있으며, 복수의 네트워크 캐쉬가 각 네트워크에 포함될 수도 있다. 또한, 각각의 네트워크의 일부 노드가 캐쉬 역할을 동시에 수행할 수도 있다. 네트워크 캐쉬는 멀티캐스트 전송시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐트를 저장하고, 멀티캐스트 리시버에 멀티캐스트 스트림을 전달할 수 있다. 실시예에 따라, 네트워크 캐쉬는 멀티캐스트 센더와 캐쉬된 컨텐트에 대한 갱신 절차를 수행할 수 있다.
유저 네트워크는 멀티캐스트 네트워크로부터 데이터를 수신하고, 해당 데이터에 포함된 컨텐트를 소비(consume)하는 디바이스로 전달하는 네트워크라 할 수 있다. 유저 네트워크의 구성 및 멀티캐스트를 통한 서비스의 종류에 따라 유저 네트워크는 다양하게 구성될 수 있다. 위에서 설명한 멀티캐스트 리시버는 실시예에 따라 유저 네트워크에 포함될 수 있다. 멀티캐스트 리시버가 유저 네트워크 내에 포함된 경우, 멀티캐스트 리시버는 유저 네트워크에 포함된 게이트웨이 (gateway) 또는 프록시 (proxy) 역할을 하는 장치를 통해 멀티캐스트 컨텐트를 수신 할 수 있다. 이러한 경우, 해당 게이트웨이 또는 프록시는 ABR 멀티캐스트 네트워크의 구성요소로써 간주될 수 있다.
멀티캐스트 리시버는 유저 네트워크 내에서 서버 또는 멀티캐스트 센더의 역할을 수행할 수 있다. 이로 인해, 유저 네트워크에 포함된 디코딩 디바이스는 멀티캐스트 컨텐트를 소비할 수 있으며, 디코딩 디바이스가 멀티캐스트 컨텐트의 직접 수신이 불가한 경우에도 멀티캐스트 스트리밍이 가능하게 할 수 있다.
도 7은 본 발명의 일 실시예에 따른 유저 네트워크를 나타낸 도면이다. 유저 네트워크의 실시예로써 홈 네트워크가 고려될 수 있다. 멀티캐스트로 전송되는 데이터는 멀티캐스트 리시버가 직접 수신 할 수도 있지만, 홈 네트워크에 속해있는 홈 게이트웨이(Home Gateway)가 데이터를 수신하고, 이를 멀티캐스트 리시버에 전달할 수 있다.
홈 게이트웨이는 홈 네트워크에 복수의 디바이스들이 포함되어 있는 경우, ABR 멀티캐스트 네트워크로부터 데이터를 수신 받을 수 있다. 홈 게이트웨이는 외부 네트워크와의 데이터 송수신을 수행할 수 있고, 또한 프록시의 역할을 동시에 수행할 수 있다. 홈 게이트웨이가 프록시의 역할을 하는 경우, 홈 게이트웨이는 멀티캐스트 리시버에게 전달할 데이터를 캐쉬(cache) 할 수 있다.
멀티캐스트 리시버는 앞서 기술한 ABR 멀티캐스트 네트워크에 포함될 수도 있으나, 네트워크의 구성상 홈 네트워크의 내부에 위치할 수 있다. 홈 네트워크의 구성에 따라 멀티캐스트 리시버가 프록시의 역할을 겸할 수 있다. 멀티캐스트 리시버가 멀티캐스트 스트림을 직접 재생(play)할 수 없는 경우, 멀티캐스트 리시버에는 멀티캐스트 스트림을 재생할 수 있는 디코딩 디바이스가 추가적으로 연결될 수 있다. 또한, 멀티캐스트 리시버는 복수의 디코딩 디바이스들과 연결되어 멀티캐스트 스트림을 전송할 수 있다.
디코딩 디바이스(Decoding device)는 멀티캐스트 스트림을 재생하여 사용자에게 제공하는 디바이스로 정의할 수 있다. 복수의 디코딩 디바이스들이 멀티캐스트 리시버에 접속할 수 있으며, 디코딩 디바이스는 유니캐스트 또는 멀티캐스트를 통해 데이터를 송수신 할 수 있다. 디코딩 디바이스는 멀티캐스트 스트림을 수신하는 멀티캐스트 네트워크 외에도 유니캐스트 네트워크에 접속할 수 있다. 디코딩 디바이스는 컨텐트 네트워크 또는 ABR 멀티캐스트 네트워크에 리퀘스트(request) 또는 리포트(report) 등을 전송할 수 있다. 실시예에 따라서는 디코딩 디바이스 외에 디코딩 모듈과 디스플레이 스크린 등이 별도의 장치로써 홈 네트워크에 포함될 수 있다. 또한 디코딩 디바이스는 멀티캐스트 리시버와 함께 단일 장치로써 구성될 수 있다.
도 8은 본 발명의 일 실시예에 따른 ABR 멀티캐스트를 위한 네트워크 구조를 나타낸 도면이다. 도면은 어댑티브 미디어 스트리밍 (Adaptive Media Streaming)을 위한 전체 네트워크 구조 (network architecture)의 예를 나타낸다. 어댑티브 미디어 스트리밍을 위한 네트워크 구조는 컨텐트 네트워크, ABR 멀티캐스트 네트워크, 유저 네트워크를 포함할 수 있다. 각 네트워크에 대한 자세한 설명은 이전 도면들에서 설명한 바와 같다. 본 발명에서 정의 하고 있는 노드 (node) 또는 엔터티 (entity)는 논리적인 구성이 될 수 있으며, 각각의 노드는 별도의 장치로 구성될 수 있으나, 실시예에 따라서 인접 노드와 같은 장치에서 동작할 수 있다. 도시된 바와 같이 복수 개의 network들이 서로 연결될 수 있으며 효율적인 멀티캐스트 스트리밍을 위해 시그널링 및 매니지먼트 정보를 교환할 수 있다.
아래에서는 어댑티브 미디어 스트리밍을 위한 네트워크 인터페이스 및 프로토콜에 대해 설명한다. 프로토콜은 실제 미디어 데이터가 전송되는 미디어 프로토콜과, 미디어 데이터를 전송하기 위해 각각의 노드 또는 엔터티를 제어하거나, 수신기를 포함하는 여러 노드 및 엔터티에 미디어 데이터에 대한 구성 정보를 전송하기 위한 시그널링 프로토콜로 구분할 수 있다. 시그널링 및 컨트롤 정보는 시그널링 프로토콜을 이용하여 전달 되지만, 수신기가 단일 연결에 의해 미디어 컨텐트를 수신하는 경우에는 별도의 시그널링 패스(path)가 구성되지 않을 수 있다. 이러한 경우에는 시그널링 및 컨트롤 정보는 미디어 프로토콜을 통해 전달 될 수 있다.
도 9는 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 도시된 바와 같이, 멀티캐스트 리시버가 디코더 (media player)와 동일한 장치 및 모듈로 구성될 수 있다. 컨텐트 네트워크에서 생성되거나 서버에 저장되어 있는 미디어 컨텐트는 사용자의 디코딩 디바이스에 전달될 수 있으며, 복수의 사용자에게 전달하기 위해 멀티캐스트로 전송될 수 있다.
어댑티브 멀티캐스트 스트리밍 (Adaptive multicast streaming) 환경에서, 컨텐트의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 멀티캐스트 전송을 수행하는 노드 (node) 및 엔터티 (entity)에게로 생성된 컨텐트를 전달 하기 위한 프로토콜과, 해당 컨텐트를 어댑티브 스트리밍 형식으로 멀티캐스트 송수신하는 프로토콜이 각각 정의될 수 있다. 도면에서는 노드 (node) 및 엔터티 (entity)가 멀티캐스트 센더로 도시되었다. 또한, 컨텐트 데이터는 복수의 노드 또는 엔터티를 거치게 되며 각각의 노드 및 엔터티 사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔터티 상의 프로토콜은 데이터를 효율적이면서 실시간으로 다음 노드로 전달하는 프로토콜을 사용할 수 있으며, 이러한 프로토콜을 터널링 (tunneling) 프로토콜이라 명명할 수 있다. 따라서 도시된 바와 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의될 수 있다. 이때, 터널링 프로토콜의 페이로드로써 미디어 컨텐트가 전달 되지만, 터널링 프로토콜은 해당 미디어 컨텐트가 어떠한 형식인지에 관계없이 동작할 수 있다.
멀티캐스트 센더에서는 멀티캐스트 리시버에 어댑티브 스트리밍을 지원 하는 프로토콜이 정의될 수 있고, 해당 어댑티브 스트리밍은 복수의 멀티캐스트 리시버들로 전달되기 위해 IP multicast 방식이 적용될 수 있다. 어댑티브 스트리밍의 프로토콜에 따라, IP multicast 방식은 TCP/IP 와 UDP/IP 의 조합으로 정의될 수 있다.
멀티캐스트 리시버가 디코더 및 플레이어을 수행할 수 있는 경우, 멀티캐스트 리시버는 IP multicast 패킷을 수신하여 어댑티브 스트리밍 데이터를 획득하고 해당 데이터에서 미디어 컨텐트 포맷에 해당하는 데이터를 디코딩 및 재생 (play)할 수 있다.
도 10은 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 도시된 바와 같이, 멀티캐스트 리시버가 디코더 (media player)와는 별도의 장치 또는 모듈로 구성될 수 있다. 컨텐트 네트워크에서 생성되거나 서버에 저장되어 있는 미디어 컨텐트는 사용자의 디코딩 디바이스에 전달될 수 있으며, 복수의 사용자에게 전달하기 위해 멀티캐스트로 전송될 수 있다.
어댑티브 멀티캐스트 스트리밍 (Adaptive multicast streaming) 환경에서, 컨텐트의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 멀티캐스트 전송을 수행하는 노드 (node) 및 엔터티 (entity)에게로 생성된 컨텐트를 전달 하기 위한 프로토콜과, 해당 컨텐트를 어댑티브 스트리밍 형식으로 멀티캐스트 송수신하는 프로토콜이 각각 정의될 수 있다. 도면에서는 노드 (node) 및 엔터티 (entity)가 멀티캐스트 센더로 도시되었다. 또한, 컨텐트 데이터는 복수의 노드 또는 엔터티를 거치게 되며 각각의 노드 및 엔터티 사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔터티 상의 프로토콜은 데이터를 효율적이면서 실시간으로 다음 노드로 전달하는 프로토콜을 사용할 수 있으며, 이러한 프로토콜을 터널링 (tunneling) 프로토콜이라 명명할 수 있다. 따라서 도시된 바와 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의될 수 있다. 이때, 터널링 프로토콜의 페이로드로써 미디어 컨텐트가 전달 되지만, 터널링 프로토콜은 해당 미디어 컨텐트가 어떠한 형식인지에 관계없이 동작할 수 있다.
멀티캐스트 센더에서는 멀티캐스트 리시버에 어댑티브 스트리밍을 지원 하는 프로토콜이 정의될 수 있고, 해당 어댑티브 스트리밍은 복수의 멀티캐스트 리시버들로 전달되기 위해 IP multicast 방식이 적용될 수 있다. 어댑티브 스트리밍의 프로토콜에 따라, IP multicast 방식은 TCP/IP 와 UDP/IP 의 조합으로 정의될 수 있다.
멀티캐스트 리시버와 디코더 (player)가 별도의 장치 또는 module로 구성되어 있는 경우에는, 멀티캐스트 리시버가 IP multicast 패킷을 수신하여 어댑티브 스트리밍 데이터를 획득하고 이를 다시 디코더에게 전달 할 수 있다. 여기서, 멀티캐스트 리시버와 디코더 사이에는 IP unicast 프로토콜이 사용될 수 있다. 멀티캐스트 리시버가 수신한 컨텐트 데이터는 다시 IP unicast를 통해 디코더로 전달 되고, 디코더는 수신된 미디어 컨텐트 포맷에 해당하는 데이터를 디코딩 및 재생(play)할 수 있다.
아래에서는 시그널링 및 컨트롤 메시지를 위한 프로토콜에 대해 설명한다. 시그널링 및 컨트롤 메시지의 전송은 각 노드 및 엔터티가 어댑티브 스트리밍을 수행하는데 있어서, 전송 제어(control), 스케줄링 (scheduling), configuration 정보 등을 제공하기 위해, 미디어 컨텐트 전송과는 구별되는 프로토콜로 정의 될 수 있다. 각각의 노드 및 엔터티가 접속 되어 있는 경우에 따라 별도의 프로토콜로 정의 될 수 있다. 앞서 기술한 네트워크 구조에서 미디어 컨텐트의 전송을 위한 프로토콜에 시그널링 및 컨트롤 메시지가 포함되어 전송될 수 있으나 그러한 시그널링 및 컨트롤 메시지는 미디어 컨텐트 딜리버리를 위한 프로토콜을 따른다.
도 11은 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다. 앞서 기술한 네트워크 구조에서 컨텐트 네트워크에 포함되는 오퍼레이터 컨트롤러(operator controller)와 멀티캐스트 네트워크에 포함되는 네트워크 컨트롤러 (network controller) 사이에 컨트롤 프로토콜이 정의될 수 있다. 또한 오퍼레이터 컨트롤러가 컨트롤 및 매니지먼트 메시지를 생성하기 위해 네트워크 컨트롤러는 컨트롤 메시지에 대한 응답(response) 또는 리포트 (report) 메시지를 오퍼레이터 컨트롤러로 보낼 수 있다. 따라서, 컨트롤 메시지를 보내기 위한 터널링 프로토콜 (tunneling protocol)은 양방향으로 구성 될 수 있다. 단일 오퍼레이터 컨트롤러는 복수의 멀티캐스트 네트워크 컨트롤러들과 컨트롤 메시지를 송수신할 수 있다. 또한 각각의 멀티캐스트 네트워크 컨트롤러는 별도의 운영주체에서 관리 될 수 있다.
네트워크 컨트롤러에서 네트워크의 configuration 관련 정보는 멀티캐스트 센더 (sender) 및 멀티캐스트 리시버로 전달될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 configuration 정보 및 네트워크의 노드 사이의 mapping 정보, routing 정보 등을 전달할 수 있다. 또한 오퍼레이터 컨트롤러로부터 수신된 configuration 정보 등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달할 수 있다. 이 과정에서, 멀티캐스트 네트워크 컨트롤러에서 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송되는 프로토콜은 구별될 수 있다. 도면 상단은 네트워크 컨트롤러에서 멀티캐스트 센더로 전송되는 프로토콜을 나타내며, 도면 하단은 네트워크 컨트롤러에서 멀티캐스트 리시버로 전송되는 프로토콜을 나타낸다.
또한, 하나의 네트워크 컨트롤러에서 복수의 멀티캐스트 센더 및 멀티캐스트 리시버로 configuration 메시지를 전달 하기 위해 IP multicast가 사용될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등은 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행할 수 있기 때문에 unicast 방식의 프로토콜이 이용될 수 있다. 이러한 일련의 컨트롤 정보, configuration 정보 등은 동적으로 업데이트 될 수 있고, 즉시 또는 스케쥴링을 통해 전송될 수 있다.
멀티캐스트 리시버는 수신된 어댑티브 스트리밍 데이터를 다시 디코딩 디바이스에 전송하기 위한 시그널링 프로토콜을 사용할 수 있다. 여기서, 개별 디코딩 디바이스에 별도의 정보를 제공하기 위해 IP unicast 방식의 프로토콜이 정의될 수 있다. 또한 디코딩 디바이스는 IP unicast 방식의 프로토콜을 이용하여 디코딩 디바이스가 요청하는 사항에 대한 시그널링을 멀티캐스트 리시버에게로 전달할 수 있다. 따라서 멀티캐스트 리시버와 디코딩 디바이스 사이에 양방향 프로토콜로써 정의 될 수 있다.
도 12는 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다. 도시된 바와 같이, 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 리시버에 직접 접속되지 않고, 멀티캐스트 센더를 통해 멀티캐스트 리시버에 접속될 수 있다.
네트워크 컨트롤러에서 네트워크의 configuration 관련 정보는 멀티캐스트 센더 (sender) 및 멀티캐스트 리시버로 전달될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 configuration 정보 및 네트워크의 노드 사이의 mapping 정보, routing 정보 등을 전달할 수 있다. 또한 오퍼레이터 컨트롤러로부터 수신된 configuration 정보 등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달할 수 있다. 그런데 여기서 멀티캐스트 컨트롤러는 멀티캐스트 센더에만 연결되어 있고, 멀티캐스트 리시버와는 연결되어 있지 않으므로, 멀티캐스트 센더가 네트워크 컨트롤러에서 멀티캐스트 리시버로 전달되는 configuration 메시지를 포워딩(forwarding) 해 줄 수 있다. 멀티캐스트 네트워크 컨트롤러에서 configuration 관련한 프로토콜 또는 message set은 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송되는 프로토콜이 구별될 수 있다.
또한, 하나의 네트워크 컨트롤러에서 복수의 멀티캐스트 센더 및 멀티캐스트 리시버로 configuration 메시지를 전달 하기 위해 IP multicast가 사용될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등은 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행할 수 있기 때문에 unicast 방식의 프로토콜이 이용될 수 있다. 이러한 일련의 컨트롤 정보, configuration 정보 등은 동적으로 업데이트 될 수 있고, 즉시 또는 스케쥴링을 통해 전송될 수 있다.
멀티캐스트 리시버에서 멀티캐스트 네트워크 컨트롤러로 전송되는 리포트 등의 정보는 멀티캐스트 센더를 통해 멀티캐스트 네트워크 컨트롤러로 전달 될 수 있다. 즉, 멀티캐스트 리시버로부터 멀티캐스트 네트워크 컨트롤러로 전달되는 리포트 메시지 등을 멀티캐스트 센더가 포워딩 해 줄 수 있다. 그 외의 프로토콜의 동작은 앞서 기술한 도면의 설명과 동일하게 적용될 수 있다.
도 13은 본 발명의 일 실시예에 따른 IP network를 통해 미디어 데이터를 전송하기 위한 프로토콜을 나타낸 도면이다. 각 레이어 (layer) 별로 해당하는 프로토콜 및 패킷 포맷 (packet format)이 결정될 수 있다. 각각의 프로토콜은 독립적으로 구성되거나 상호 동작을 위해 특정 프로토콜들이 조합될 수 있다. 인코더에서 수집된 비디오 및 오디오 데이터를 압축하고 적절한 코덱(codec)으로 변환하여 패키저 (packager)로 전달하는 작업은 송신 시스템 내부적인 데이터 처리로써 수행될 수 있다. 비디오 및 오디오의 멀티캐스트를 위해, 효율적인 codec이 사용 될 수 있으며, 비디오 데이터에 대해서는 HEVC(High Efficiency Video Coding), AVC (Advanced Video Coding) 등의 codec이 사용될 수 있고, 오디오 데이터에 대해서는 AAC (Advanced Audio Coding), AC4 (audio compression 4), MPEG-H (Moving Picture Experts Group-H) audio codec등이 이용될 수 있다.
각각의 codec은 전송 또는 저장에 적합한 형태로 패키징 (packaging) 될 수 있다. 이를 위해서 ISOBMFF (ISO base media file format), CMAF (Common Media Application Format), MPEG-2 TS (Transport Stream) 형태의 포맷 등이 사용될 수 있다. Codec으로 인코딩된 컨텐트 데이터가 패키징되는 과정에서, 특정 수신기에서만 해당 contents가 재생될 수 있도록 DRM (Digital Rights Management)이 추가될 수 있고, DRM에 사용되는 인증 key값은 별도의 링크 또는 채널을 통해 전달될 수 있다.
파일 형태로 구성된 미디어 데이터는 전송 방식에 따라 FLUTE (File Delivery over Unidirectional Transport)과 같이 파일을 직접 전송 할 수 있는 프로토콜이 적용될 수 있다. 또한, DASH (Dynamic Adaptive Streaming over HTTP)와 같은 어댑티브 스트리밍을 지원 하는 프로토콜이 이용될 수 있다. FLUTE 또는 DASH의 구성에 따라 하위 레이어의 프로토콜이 적용될 수 있다. 예를 들어 DASH 가 적용되어 있는 경우 하위 레이어 프로토콜로써 HTTP가 적용되거나, DASH 세그먼트를 파일로 간주하고 FLUTE가 하위 레이어 프로토콜로 사용될 수 있다.
IP multicast를 위해 상위 프로토콜의 구성에 따라 TCP/IP (Transmission Control Protocol/Internet Protocol) 또는 UDP/IP (User Datagram Protocol/Internet Protocol)가 사용될 수 있다. 또한, 멀티캐스트 리시버에서 IP multicast 그룹의 가입 등을 관리해 줄 수 있는 IGMP (Internet Group Management Protocol) 등이 병행될 수 있다. 레이어2 및 레이어1 프로토콜은 각각의 전송 링크에 따라 정의될 수 있다. 즉, 네트워크 상에 구성되는 노드 및 엔터티 사이의 링크에 따라 최적화 된 프로토콜이 구성 될 수 있다. 예를 들어 LAN (Local Area Network) 환경에서 레이어2는 Ethernet, 레이어1은 CSMA/CD (Carrier sense multiple access with collision detection) 프로토콜로 정의될 수 있다.
도 14는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. 미디어 딜리버리 프로토콜은 미디어 컨텐트가 전송되는 경로에 따른 프로토콜의 구체적인 실시 예를 나타낸 것이다. 여기에서, 멀티캐스트 리시버는 디코더 (media player)와 동일한 장치 및 모듈로 구성되어 있는 경우를 나타낸다.
컨텐트를 위해 서버에서 사용되는 프로토콜은 미디어 코덱 (media codec)과 파일 포맷 (file format)이다. 미디어 코덱은 비디오, 오디오 또는 그 외의 인코딩 포맷을 포함할 수 있다. 비디오에 대해서는 HEVC, AVC 등의 코덱을 포함할 수 있고, 오디오에 대해서는 AAC, AC4, MPEG-H audio codec 등의 코덱을 포함할 수 있다. 파일 포맷에 대한 프로토콜은, 코덱 포맷을 파일 형태로 전송 또는 저장하기 위한 포맷으로써 정의될 수 있다. 이를 위해 ISOBMFF, CMAF 등의 파일 포맷이 사용될 수 있고, 기존 방송 네트워크가 연결되는 경우에는 MPEG-2 TS의 포맷을 이용하여 전송될 수 있다. 파일 포맷을 전송의 효율화를 위해 복수개의 포맷이 사용될 수 있다.
서버와 멀티캐스트 센더 사이의 프로토콜은 주로 파일 포맷의 효율적인 전달을 위한 프로토콜을 정의 할 수 있다. 따라서, 서버에서 생성된 컨텐트의 데이터를 터널링 프로토콜 (tunneling protocol)을 이용하여 전달 할 수 있다. 터널링 프로토콜은 주로 RTP 와 같은 실시간 전송 프로토콜을 이용할 수 있고, 그 외 해당 네트워크에서 사용할 수 있는 IP 기반의 다른 터널링 프로토콜을 이용할 수 있다. 이때 기존의 프로토콜을 그대로 이용 하거나, 해당 네트워크에 적합하도록 필드 (field)의 정의를 변경할 수 있다. 멀티캐스트 센더에서는 서버로부터 터널링 프로토콜을 이용하여 전달되는 파일을 수신하기 위해 입력단에 터널링 프로토콜이 정의 될 수 있다. 이때 터널링 프로토콜을 이용하여 전송되는 파일 포맷은 멀티캐스트 센더로부터 멀티캐스트 리시버로 전달해야 하는 데이터이므로, 해당 데이터의 포맷에 무관하게 터널링 프로토콜이 동작할 수 있다.
멀티캐스트 센더와 멀티캐스트 리시버 사이의 프로토콜은 주로 어댑티브 스트리밍(adaptive streaming)을 위한 프로토콜로 정의될 수 있다. 이러한 프로토콜은 DASH 기반의 프로토콜로 구성될 수 있으며, 이를 위해 하위 레이어 프로토콜은 IP multicast를 기반으로 한다. DASH가 동작하기 위해 HTTP 등의 프로토콜이 함께 사용될 수 있으며, DASH 세그먼트가 파일 형태로 이용되는 경우에는 FLUTE 등의 파일 전송 프로토콜이 구성 될 수 있다. 추가로, DASH/HTTP 프로토콜의 효과적인 네트워크 상의 컨넥션 및 멀티캐스트 전송을 위해 TCP/IP가 사용될 수 있다.
멀티캐스트 리시버는 멀티캐스트로 전송된 패킷 스트림 (packet stream)을 수신하기 위해 TCP/IP를 이용할 수 있다. 또한, 멀티캐스트 리시버는 패킷 스트림에 대한 요청 (request), 수신된 데이터에 대한 응답 (response) 등을 위해 HTTP를 사용할 수 있다. 멀티캐스트 센더에서 DASH를 사용하여 어댑티브 스트리밍하는 경우, 멀티캐스트 리시버는 DASH client를 포함할 수 있다. DASH를 이용하여 어댑티브 스트리밍되는 데이터는 서버에서 송신한 파일 포맷으로 구성되어 있다. 따라서, 멀티캐스트 리시버는 해당 파일 포맷을 식별할 수 있는 파일 포맷 관련 프로토콜과, 식별된 미디어 포맷을 디코딩할 수 있는 미디어 코덱을 사용할 수 있다.
도 15는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. 미디어 딜리버리 프로토콜은 미디어 컨텐트가 전송되는 경로에 따른 프로토콜의 구체적인 실시 예를 나타낸 것이다. 본 실시예는, 멀티캐스트 리시버가 디코더 (media player)와는 별도의 장치 또는 모듈로 구성되어 있는 경우를 나타낸다. 따라서, 멀티캐스트 리시버는 수신된 멀티캐스트 스트림을 디코딩 디바이스 (디코더)에 전송하는 과정이 필요하다.
멀티캐스트 리시버는 멀티캐스트로 전송된 패킷 스트림 (packet stream)을 수신하기 위해 TCP/IP를 이용할 수 있다. 또한, 멀티캐스트 리시버는 패킷 스트림에 대한 요청 (request), 수신된 데이터에 대한 응답 (response) 등을 위해 HTTP를 사용할 수 있다. 멀티캐스트 센더에서 DASH를 사용하여 어댑티브 스트리밍하는 경우, 멀티캐스트 리시버는 DASH client를 포함할 수 있다. DASH를 이용하여 어댑티브 스트리밍되는 데이터에 대해 멀티캐스트 리시버는 프록시(proxy) 역할을 수행할 수 있다. 멀티캐스트 리시버는 데이터를 디코딩 디바이스로 전달할 수 있다. 멀티캐스트 리시버에 접속되어 있는 디코딩 디바이스의 수는 한정될 수 있으므로 해당 연결은 유니캐스트 전송을 기반으로 할 수 있다. 따라서, 멀티캐스트 리시버는 유니캐스트 연결을 위한 HTTP와 TCP/IP protocol를 이용할 수 있다.
디코딩 디바이스는 멀티캐스트 리시버로부터 전송되는 데이터를 수신하기 위해 유니캐스트 프로토콜을 이용할 수 있다. HTTP 유니캐스트를 통해 전달된 데이터는 서버에서 송신한 파일 포맷을 가질 수 있다. 따라서 디코딩 디바이스는 해당 파일 포맷을 식별할 수 있는 파일 포맷 관련 프로토콜과 식별된 미디어 포맷을 디코딩할 수 있는 미디어 코덱을 사용할 수 있다. 그 외의 프로토콜에 대한 동작은 이전 도면에서 기술한 실시 예와 동일 하다.
도 16은 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. DASH 세그먼트를 전송하는 방식은 QUIC (Quick UDP Internet Connections) 프로토콜을 이용할 수 있다. TCP/IP를 사용한 멀티캐스트 방식은 컨넥션 (connection)을 형성하는데 딜레이(delay)가 발생 될 수 있고, 스트리밍 데이터를 즉시 전송하는데 부적합할 수 있다. QUIC 기반의 프로토콜은 컨넥션 및 플로우 (flow) 제어에 대한 과정을 QUIC에서 담당한다. 또한 QUIC는 HTTP/2를 사용할 수 있으며, 이로 인해 기존의 HTTP에서 발생하는 전송 지연을 개선할 수 있으며, UDP/IP를 이용하여 스트리밍 데이터를 즉시 전송 할 수도 있다. 그 외의 protocol에 대한 동작은 앞서 기술한 실시 예와 동일 하다.
도 17은 본 발명의 일 실시예에 따른 DASH 전송 방식을 나타낸다. DASH 시스템은 HTTP 서버 및 DASH 클라이언트 간의 데이터 송수신으로 구현될 수 있다. 여기서 DASH 클라이언트는 DASH 억세스 엔진(access engine) 및 미디어 엔진 (media engine)을 포함할 수 있다. DASH에서 HTTP 서버는 다양한 품질의 콘텐트를 일정한 시간 단위의 조각(segment)으로 분할하여 서버에 저장할 수 있다. HTTP 서버는 사용자 디바이스인 DASH 클라이언트의 미디어 요청 시에 분할된 데이터 단위를 HTTP 프로토콜을 이용하여 전송할 수 있다. 여기서 유동적인 HTTP 네트워크 상태를 고려하여, 다양한 품질로 HTTP 서버에 저장되어 있는 미디어 콘텐츠를 선택적으로 전송할 수 있다. 이로 인해, 사용자는 끊김 없는 적응적 스트리밍 서비스를 수신할 수 있다. 위에서 설명한 분할된 파일들에 대한 타임라인 (timeline) 순서 및 품질의 순서에 대한 정보를 포함하는 별도의 파일이 MPD (Media Presentation Description)이다. MPD는 DASH 클라이언트에게 HTTP 서버에 저장된 미디어 데이터에 대한 정보를 제공할 수 있다. MPD는 XML문서로써, 분할된 세그먼트에 부여된 각 URL, 시작시간, 컨텐트 종류 등의 속성을 포함할 수 있다. DASH 클라이언트는 미디어 파일의 수신에 선행하여 서버에 MPD 파일을 요청하고, MPD 파일을 수신할 수 있다. MPD 파일이 수신되면, DASH 클라이언트는 MPD에 포함된 미디어 파일에 관한 정보를 이용하여 HTTP 서버에 저장되어 있는 컨텐트에 대한 세그먼트 파일을 요청할 수 있다.
도 18은 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조를 나타낸 도면이다. DASH 세그먼트는 전송할 콘텐츠를 미디어 세그먼트로 분할하여 일정 기간(duration) 동안 재생될 수 있는 전송 오브젝트의 데이터 단위이다. DASH 미디어 세그먼트는 세그먼트 유형(type)을 나타내는 'styp'박스를 포함하고, 세그먼트 인덱스 정보를 포함하는 'sidx'박스를 포함한다. 또한 DASH 미디어 세그먼트는 fragment단위로 잘려진 미디어 스트림을 포함하고 있는 'mdat'박스와 이에 대한 메타데이터를 담고 있는 'moof'박스를 포함할 수 있다. DASH 클라이언트는 서비스를 요청하기 위해 매니페스트(manifest) 파일인 MPD 파일의 전송을 요청하고, 각 segment URL (Uniform Resource Locator)을 통해 미디어 세그먼트를 요청할 수 있다. 미디어 세그먼트를 디코딩하기 위해서, DASH 클라이언트는 초기화 정보를 담고 있는 초기화 세그먼트 (Initialization segment, IS) 파일을 수신하고 파싱하여 디코더 초기화를 수행한 후, 요청한 미디어 세그먼트 파일을 수신하여 미디어 파싱과 디코딩을 수행할 수 있다.
DASH 클라이언트가 수신하는 파일들은 미디어 재생을 위한 구성요소에 따라 구분될 수 있다. DASH 클라이언트는 Manifest 파일인 MPD, 초기화 세그먼트 파일 및 미디어 세그먼트 파일을 수신한 후 미디어를 재생할 수 있다. 따라서 송신단의 미디어 인코더는 전체 재생 블록 (MPD+IS+sidx+moof+mdat) 을 위해 미디어 데이터를 포함하는 mdat을 인코딩하고, 인코딩 정보를 포함한 메타데이터 헤더(styp+sidx+moof)를 생성할 수 있다. 이후 송신단은 디코더 초기화 정보인 IS.mp4 파일을 생성하고, 세그먼트의 URL 정보를 포함하는 MPD에 작성하여 DASH 클라이언트에게로 전송할 수 있다. 수신단의 파싱 오더(parsing order)는 다음과 같다. 수신단은 MPD 파일을 수신하여 파싱하고, 디코더를 초기화하고, 네트워크 상황에 따른 미디어 세그먼트를 요청할 수 있다.
다양한 품질로 저장된 DASH 세그먼트가 라이브(live) 타입의 서비스를 제공하거나, 라이브 방송 콘텐츠를 인코딩하여 데이터를 전송하는 서비스의 경우는 미디어 서비스 프레임워크(framework) 전체의 실시간성(real-time)이 적용되어야 한다. 따라서, seamless한 서비스의 구현을 위해 딜레이 발생을 최소화해야 한다. DASH 프로토콜을 적용한 라이브 방송시 실시간 컨텐트를 인코딩 및 패킷화하는 과정과 실시간 콘텐츠를 파싱하고 디코딩하는 과정에서 딜레이가 발생하는 경우, 서비스 시작 시점의 딜레이가 발생할 수 있다. 다시 말해, 각 미디어 파일을 생성하고 패킷화하여 송신하면, 패킷의 reception time, 파싱(parsing)을 위해서 전체 패킷이 만들어 질 때까지 기다려야 하는 지연시간이 발생할 수 있다. 이로 인해, 클라이언트 측에서는 버퍼링의 시간이 길어진다. 이와 같은 문제점을 해결하기 위해 아래와 같은 방법을 제안한다.
도 19는 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조와 생성 및 파싱 순서를 나타낸 도면이다. 미디어 데이터의 송수신 딜레이를 줄이고, 수신단에서의 빠른 미디어 재생을 위해, 이전 도면에서 설명한 MPD, IS, sidx, moof, I 프레임들을 하나의 단일 빌딩 블록 (building block)으로 만들어, 미리 전송할 수 있다. 이를 패스트 스타트업 빌딩 블록 (fast startup building block)으로 칭할 수 있다. 전송된 MPD를 이용하여 DASH 클라이언트는 유니캐스트로 기존 모델 (conventional model)에 따라 MPD 전송 및 segment 요청을 통해 playback 을 실행할 수 있다. 상기 DASH 프레임워크를 동작하는 동안, DASH 클라이언트는 단일 빌딩 블록에 포함되어 MPD와 함께 수신된 I 프레임을 이용하여 fast startup을 실행할 수 있다. 다시말하면, 송신단 서버는 moof 헤더가 커버하는 mdat 전체의 프레임을 보내지 않고, I 프레임을 선택적으로 전송하여 수신 딜레이 (reception delay)를 줄일 수 있다. 또한, DASH 클라이언트는 RAP(Random Access Point)인 I 프레임부터 재생을 시작하여 빠른 AV (audio and video) startup을 수행할 수 한다. 또한 live 방송의 경우 송신단 서버는 전체 quality의 세그먼트를 모두 만드는 대신, 네트워크 상황을 고려하거나, Network 사업자가 고려하여 패스트 스타트업을 가능하게 하는 representation/segment을 선택적으로 생성하고, 이에 대한 light MPD 를 만들어 전송할 수 있다. DASH 클라이언트는 light MPD는 수신하여 상기 fast startup building block을 구성하여 신속하여 플레이를 시작할 수 있다. 이후 DASH 클라이언트는 다른 품질 (quality)의 세그먼트를 프록시 (proxy) 에 수신하여, 세그먼트들의 quality 에 따른 비트스트림 스위칭을 수행할 수 있다. 정리하면, 송신단 서버는 패스트 스타트업을 위한 세그먼트만을 고려하여 전송할 수 있으며, MPD 내에도 패스트 스타트업을 위한 세그먼트 정보를 포함시켜 미디어 데이터의 재생까지의 딜레이를 최소화 할 수 있다.
도 20은 본 발명의 일 실시예에 따른 유저 네트워크 및 MPD를 나타낸 도면이다. 도면 상단과 같이 클라이언트가 서비스를 받기 위해 프록시(proxy)에 저장된 DASH 컨텐트를 요청하는 경우, 기존 MPD에는 이전 도면에서 설명한 Fast startup segment mode (Fastmode)를 나타내는 내용이 존재하지 않는다. 따라서 클라이언트가 해당 컴포넌트에 접근했을 때, 빠르게 접근하기 위한 세그먼트, 즉 Fast startup segment 임을 나타내는 시그널링이 필요하다. 도면 하단은 MPD의 계층적 구조를 나타낸다. MPD는 요소(element) 및 속성(attribute)들을 포함한 계층적인 구조로 구성되어 있다. 각 계층 내에는 미디어 컨텐트에 관한 정보를 담고 있는 요소 및 속성 등이 구조적 기능 및 역할 등을 기술하고 있다. 비디오, 오디오 컨포넌트 레벨에 대한 기술은 Adaptation-Set 부터 기술되고, Adaptation-Set은 하나 이상의 Representation entry들을 가지고 있다. Representation은 세그먼트들의 URL 경로에 대한 정보를 포함하고, 클라이언트는 네트워크 상황에 따라 Representation 간의 비트스트림 스위칭을 수행할 수 있다.
도 21은 본 발명의 일 실시예에 따른 MPD의 세부 내용을 나타낸 도면이다. 전술한 MPD 내의 representation에는 공통 속성(Common attribute)을 나타낼 수 있는 descriptor를 포함 할 수 있는데 도면 상단과 같은 Common attribute descriptor를 포함할 수 있다. Common attribute는 supplemental Property descriptor를 포함할 수 있으며, 이를 통해 해당 representation의 프레임워크(framework) 에 필요한 요소(element)를 정의할 수 잇다. 이러한 descriptor 형태(descriptor type)의 요소(element)는 도면 중단에 도시된 바와 같이, schemeIdUri 속성을 통해 어떤 동작을 해야 하는지의 attribute를 정의할 수 있으며, value 속성들을 통해 특정 동작에 대한 구체적인 code point를 정의할 수 있다. 위에서 설명한 패스트 스타트업을 위한 정보는 새로운 supplemental Property descriptor의 확장을 통해 MPD 내에서 정의될 수 있으며, 이를 통해 representation entry중 패스트 스타트업이 가능한 representation을 시그널링할 수 있다. 즉, 도면 하단에 도시된 바와 같이, schemeIdUri 속성을 패스트 스타트업으로 정의하고, value 속성들에 대해 기존의 segment mode와 패스트 스타트업을 위한 Fastmode를 정의할 수 있다. Fastmode는 이전 도면에서 설명한 패스트 스타트업 빌딩 블록을 이용한 패스트 스타트업이 가능함을 DASH 클라이언트에게 시그널링할 수 있다.
도 22는 본 발명의 일 실시예에 따른 패스트 스타트업을 위한 MPD를 나타낸 도면이다. 도시된 바와 같이, MPD는 XML로 표현될 수 있으며, 패스트 스타트업을 지원하는 Representation에 대해 supplemental property element의 schemeIdUri 속성을 패스트 스타트업(Faststartup)으로 정의하고, value 속성을 패스트모드(Fastmode) 로 설정할 수 있다. 이를 통해 MPD는 해당 representation이 전술한 패스트 스타트업을 지원하는 representation임을 DASH 클라이언트에게 시그널링할 수 있다.
도 23은 본 발명의 일 실시예에 따른 멀티캐스트를 위한 네트워크 구성을 나타낸 도면이다. 전술한 실시예들과 달리 서버로부터 MPD 파일을 수신하지 않는 실시예로써 멀티캐스트를 구현할 수도 있다. 이를 MPD less 방식이라고 칭할 수 있다. 멀티캐스트 서비스를 위한 DASH live 스트리밍에서, 멀티캐스트 센더인 DASH 서버는 컨텐트를 생성하고 각 세그먼트에 URL을 부여한 후, MPD를 작성 및 전송하고 스트리밍 서비스를 시작할 수 있다. 하지만, 네트워크의 불안정성 및 bit-rate에 대한 보장이 안되는 네트워크 컨디션의 상황으로 인해, 퀄리티 별로 DASH 컨텐트를 생성하고 DASH 서비스를 시작하기까지 딜레이가 발생할 수 있다. 이에 반해, 유저 네트워크 내의 통신망은 bit-rate가 보장되기 때문에 DASH 서비스를 위한 네트워크 컨디션을 지원할 수 있다.
따라서 유저 네트워크 내에 DASH 서버를 위치시키는 방법을 이용할 수 있다. 즉, 유저 네트워크까지는 기존 conventional multicast model을 유지하여, 컨텐트 네트워크에서 패킷들을 생성 후 바로 전송하는 형태를 이용할 수 있다. 유저 네트워크 내의 DASH 서버는 수신된 패킷을 모아서 세그먼트들의 URL을 생성하고, DASH hierarchy에 맞게 MPD를 생성하고 유니캐스트의 형태로 DASH 클라이언트와 스트리밍 서비스를 진행하는 방법을 사용할 수 있다. 다시 말해, 기존 DASH 서버를 유저 네트워크로 옮겨 놓고, DASH 서버가 멀티캐스트 센더로부터 수신되는 세그먼트 파일들을 모아 MPD를 업데이트하면서 서비스를 진행할 수 있다.
예를 들어, 컨텐트 서버는 HD 급의 세그먼트를 우선적으로 생성하여 멀티캐스트 센더를 통해 전송을 시작하고, 유저 네트워크의 DASH 서버는 세그먼트 패킷들 중 우선적으로 생성된 representation의 정보를 포함하는 MPD를 생성한다. 이때 멀티캐스트 네트워크 컨트롤러는 서비스 관점에서 MPD 타임슬롯 (timeslot)의 동기화 및 관리를 통해 컨트롤 패킷들을 전송할 수 있다. DASH 클라이언트인 디코딩 디바이스는 생성된 MPD를 통해 기존 DASH 모델의 따라 유니캐스트 HTTP 스트리밍을 받을 수 있다. 이를 통해 기존 DASH 클라이언트에 대한 변경 없이, 홈 게이트웨이 (Home gateway) 또는 멀티캐스트 리시버 (multicast receiver)만을 변경하여 신속한 서비스를 받을 수 있다.
DASH, HLS (Http Live Streaming) 등 어댑티브 스트리밍은 전송할 컨텐트 파일과 해당 파일의 속성을 담고 있는 메타데이터의 생성까지 완료되어야 스트리밍을 시작할 수 있다. 이전 도면에서 언급한 대로 전송할 미디어 세그먼트 파일이 모두 생성되기 전에, 우선적으로 전송할 수 있는 미디어 세그먼트 파일이 기존 멀티캐스트 모델을 이용하여 전송될 수 있다. 프록시(proxy)에서 파일을 재생시킬 수 있는 ordering이 만들어지면, 우선적으로 전송된 미디어 세그먼트 파일을 재생할 수 있도록 manifest (ex. MPD) 파일이 생성될 수 있다. 즉, 기존 멀티캐스트 모델에 따라, 멀티캐스트 ABR 모델 내 멀티캐스트 리시버 또는 프록시에 멀티캐스트 데이터가 캐싱 (caching) 되거나, 수신 가능한 유니캐스트 (unicast) 패킷들이 캐싱되면, 특정 시점을 기준으로 멀티캐스트 리시버 또는 프록시에서 MPD 를 만들 수 있다. 복수의 품질로 저장된 DASH 세그먼트가 linear 서비스를 제공하는 경우, 복수의 품질에 해당하는 세그먼트들을 IP 네트워크로 순차적으로 전송해야 하고, 이로 인해 서비스 딜레이가 발생할 수 있다. 이를 극복하기 위해, 빠른 데이터 수신과 일부 미디어 세그먼트를 우선적으로 수신하여 신속하게 재생(playback) 할 수 있다. 아래에서는 데이터의 크기 및 재생 가능한 단위로의 수신하는 시간을 고려하여, 패킷 전송의 우선순위를 정의할 수 있다. 이를 통해 우선순위에 따른 패킷 전송으로 인해 재생 가능한 단위의 렌더링(rendering)이 신속해지므로, 시작 delay 가 낮아질 수 있다.
도 24는 본 발명의 일 실시예에 따른 DASH 세그먼트를 발생하는 과정을 나타낸 도면이다. 즉, 전송될 세그먼트는 도시된 gernerating order에 따라 생성될 수 있으며, 전송블록에 따라 전송될 수 있다. 미디어 세그먼트는 도시된 바와 같이 Quality가 높아질수록 세그먼트 길이가 길어지므로, 전체 세그먼트를 생성하고 전송하는데 지연시간(delay)이 발생할 수 있다. 따라서, 상기 세그먼트 중 신속하게 startup 할 수 있는 세그먼트를 별도로 생성하고, 전송할 필요가 있다. 또한 생성된 블록에 따라 만들어진 데이터를 전송 오브젝트에 따라 부분적으로 패킷화하여 전송해야 한다. 이를 위해 상기 패킷에는 전체 sequence가 아닌 RAP가 가능한 I 프레임만을 포함한 object을 전송할 수 있다. 도시된 바와 같이, 생성 순서(generating order)에 따라 1,2,3,4,5,6을 생성한 후, 전송 오브젝트는 I 프레임만을 포함하도록 구성할 수 있다. 이러한 전송 오브젝트가 수신단에서 수신되는 경우, 수신단은 전송오브젝트를 수신하는 즉시 RAP를 통한 디코딩을 수행할 수 있다. 이후 송신단은 연속하여 나머지 media chunk 패킷을 포함하는 오브젝트를 전송하여 수신단의 후속 프레임들에 대한 재생을 가능하게 할 수 있다. 위에서 설명한 I 프레임만을 선택적으로 포함하는 전송 오브젝트를 송신하는 모드를 패스트 스타트업 모드(fast startup mode)라고 하고, 이를 위해 protocol의 확장을 통해 multicast ABR을 구현할 수 있다. 아래에서는 scalable IP-based TV distribution system에 적용할 수 있는 프로토콜인 QUIC(Quick UDP Internet Connections)의 확장을 제안한다.
도 25는 본 발명의 일 실시예에 따른 QUIC 프로토콜 스택을 나타낸 도면이다. QUIC는 scalable IP-based TV distribution system을 위한 UDP 기반 object 전송 프로토콜이다. QUIC는 TCP 기반 유저와 서버 사이에 connection long-standing 의 과정의 단점을 보완할 수 있으며, TCP 와 유사하게 FEC를 활용한 UDP 데이터 그램을 전송할 수 있다. 또한 QUIC는 연관된 어플리케이션 레벨의 데이터 (Application level data)를 다중화(multiplexing) 하여 전송할 수 있으며, HTTP 기반 Web-oriented 메커니즘으로 Multicast를 지원할 수 있다. 즉, QUIC는 멀티캐스트와 유니캐스트를 각각 지원할 수 있다.
도 26은 본 발명의 일 실시예에 따른 QUIC 프로토콜을 적용한 멀티캐스트 방법을 나타낸 도면이다. QUIC 프로토콜은 UDP-HTTP 기반 멀티캐스트/유니캐스트를 지원하는 프로토콜로써, 미디어 세그먼트를 전송하는 딜리버리 프로토콜이다. HTTP Alternative Services (Alt-Svc) 는 클라이언트가 유니캐스트로 접속 후, 멀티캐스트 서버를 통해 서비스를 제공하는 기능을 지원할 수 있다. QUIC 와 Alt-Svc 시나리오의 구체적인 동작 방법은 아래에서 설명한다. 도 26은 QUIC 프로토콜을 적용한 multicast ABR을 위한 서비스를 나타낸다. 하기 서술은 multicast ABR을 위한 서비스 Reverse proxy procedure에 대한 설명이다. 본 시나리오는 proxy를 기준으로 리니어 서비스를 요청하여 특정 실시간 시점에서 데이터를 수신하는 시나리오를 의미한다.
먼저 첫번째 단계로써 클라이언트가 디스커버리(discovery)를 통해 service handshake 완료할 수 있다. 두번째 단계로써, 클라이언트의 어플리케이션 (application)이나 linear 서비스 플레이어가 현재 시점에 대응하는 timeslot의 playback을 위해 unicast 를 통해 CDN의 service session에 접속할 수 있다. 클라이언트는 HTTP GET 을 통해 request 및 response를 수행하고, response로부터 접속할 수 있는 multicast network 주소 정보를 획득할 수 있다. 클라이언트는 해당 multicast network 주소를 통해 subscribe를 요청할 수 있다. 세번째 단계로써, 클라이언트는 HTTP server push의 형태로 패킷을 수신하여 서비스를 수신할 수 있다.
도 27은 본 발명의 일 실시예에 따른 QUIC 헤더 확장을 나타낸 도면이다. UPD 패킷은 UDP 헤더와 UDP 페이로드로 구분될 수 있다. UDP 페이로드는 QUIC 패킷 헤더 및 QUIC 패킷 페이로드를 포함할 수 있다. QUIC 패킷 헤더는 Public flag 필드, connection ID 필드, QUIC version 필드, sequence number 필드, Private flag 필드, FEC 필드, Frame type 필드, stream ID 필드, offset 필드, length 필드를 포함할 수 있으며, 이에 추가적으로 Header extension 필드를 더 포함할 수 있다. 여기서 Frame type 필드, stream ID 필드, offset 필드, length 필드는 스트림 프레임 헤더로 분류될 수 있다. Public flag 필드는 패킷 내에 QUIC 버전 필드가 포함되었는지 여부, 해당 패킷이 public reset 패킷인지 여부를 나타낼 수 있다. 또한 Public flag 필드는 connection ID 필드의 사이즈 및 패킷에 패킷 시퀀스 넘버가 존재하는지 여부도 나타낼 수 있다. connection ID 필드는 client에 의해 선택된 컨넥션의 식별자를 나타낸다. QUIC version 필드는 QUIC 프로토콜의 버전을 나타낸다. 해당 필드는 public flags가 FLAG_VERSION을 포함할 때 존재할 수 있다. sequence number 필드는 public flags가 시퀀스 넘버의 존재를 나타내는 경우, 시퀀스 넘버의 lower bits를 나타낼 수 있다. Private flag 필드는 해당 패킷이 entropy를 포함하는지, fec byte가 존재하는지, 해당 패킷이 FEC 패킷인지를 나타낼 수 있다. FEC 필드는 FEC 그룹 내의 첫번째 패킷의 패킷 시퀀스 넘버를 나타낼 수 있다. Frame type 필드는 프레임의 타입을 나타낼 수 있으며, 해당 프레임이 스트림 프레임인지 여부를 나타낼 수 있다. 또한 Frame type 필드는 data length 필드가 존재하는지 여부를 나타낼 수 있으며, offset 필드의 길이를 나타내거나 stream ID 필드의 길이를 나타낼 수 있다. 또한 본 발명의 일 실시예에 따라 ABR segment 확장 case를 지시할 수 있다. stream ID 필드는 해당 스트림의 식별자를 나타낼 수 있다. offset 필드는 해당 데이터 블록을 위한 스트림 내에서의 byte offset을 나타낼 수 있다. length 필드는 해당 스트림 프레임 내의 데이터의 길이를 나타낼 수 있다.
컨텐트 제공자가 QUIC 프로토콜 기반 리니어 서비스(linear service) 를 제공하는 경우, QUIC 헤더 정보를 확장하면 QUIC 프로토콜은 신속한 AV startup을 지원할 수 있다. 도시된 바와 같이, QUIC 헤더에 포함된 Frame type에서 새로운 value를 이용하여 ABR segment 확장 case를 지시하고, 상기 value로 세그먼트를 전송하는 경우, QUIC 헤더에 포함된 header extension 값을 확장할 수 있다. QUIC 헤더에 포함된 header extension 필드는 FS, repID, Code point 및 QUIC PTS 필드를 포함할 수 있다. 실시예에 따라 FS, repID, Code point 및 QUIC PTS 필드는 QUIC 헤더에 별도의 필드로써 포함될 수 있다. FS필드는 DASH segment 를 담고 있는 packet의 Fast start 값을 의미하며, 이를 통해 linear 서비스의 패킷의 형태가 Fast startup을 위한 패킷인지 여부를 나타낼 수 있다. FS필드가 0x0인 경우, 해당 패킷에 포함된 세그먼트가 MPD 및 기존 DASH model, complete segment임을 나타낼 수 있다. FS필드가 0x1인 경우에는 Fast startup mode이고 MPD가 존재함을 나타낼 수 있다. 즉, FS필드 0x1은 해당 패킷이 fast startup block을 구성하고, MPD가 존재하여 MPD 내의 타임라인과 representation 정보를 통해 컨텐트를 구성할 수 있음을 나타낼 수 있다. FS필드가 0x2인 경우에는 Fast startup mode이고 MPD가 필요하지 않음을 나타낼 수 있다. 이 경우, 클라이언트는 MPD timeline을 따르지 않고 UDP의 NTP reference와 QUIC PTS값에 따라 바로 디코딩을 시작할 수 있다. FS필드 0x3은 추후 활용될 수 있다. RepID 필드는 해당 스트림의 representationID(DASH 와 aligned) 을 의미하며, 또한 해당 필드는 quality 또는 스트림의 bandwidth 값을 포함한 value를 나타낼 수 있다. Codepoint 필드는 IS의 포함여부, 전체 세그먼트가 fragmented 되어있는지를 나타낼 수 있다. Code point 필드의 값이 0이면 Default, 1이면 패킷 내에 새로운 초기화 세그먼트 (New Initialization Segment, IS)가 포함되고 전체 세그먼트가 Unfragmented 되었음을 나타낼 수 있다. 또한 Code point 필드의 값이 2이면 패킷 내에 새로운 IS가 포함되고, 전체 세그먼트가 fragmented 되었음을 나타낼 수 있다. 또한 Code point 필드의 값이 3이면 패킷 내에 미디어 세그먼트가 포함되고 전체 세그먼트가 Unfragmented 되었음을 나타낼 수 있으며, 4이면 패킷 내에 미디어 세그먼트가 포함되고 전체 세그먼트가 fragmented 되었음을 나타낼 수 있다. QUIC_PTS 필드는 MPD less의 전송으로 수신된 fast startup block 의 시작을 위한 타임 스탬프를 의미할 수 있으며, 해당 필드는 MPD less일때만 사용할 수 있다. 여기서 MPD less란 도 23에서 설명한 바와 같이 별도의 MPD가 전송되지 않아 수신기가 available start time을 획득할 수 없는 시나리오를 의미할 수 있다. 즉, MPD가 전송되지 않아, 수신기가 QUIC 패킷의 파싱 시점 또는 방송의 시작 시점을 획득할 수 없는 경우, 수신기는 QUIC_PTS를 이용하여 파싱 시점 또는 방송의 시작 시점을 결정할 수 있다. 상술한 바와 같이 QUIC 프로토콜의 헤더를 확장하여 FAST startup을 지원할 수 있다.
도 28은 본 발명의 일 실시예에 따른 수신기 구조를 나타낸 도면이다. 수신기는 tuner를 이용하여 방송 신호 또는 멀티캐스트 신호를 수신할 수 있다. 수신기는 ADC (Analog Digital converter)를 이용하여 아날로그 신호를 디지털 신호로 변환하고, Demodulator를 이용하여 수신된 신호를 복조(demodulating)할 수 있다. 수신기는 channel sync. & EQ를 이용하여 수신된 신호에 대해 동기화 및 이퀄라이징을 수행하고, 채널 디코더를 이용하여 수신된 신호에 대한 디코딩을 수행할 수 있다. 디코딩된 신호는 L1(layer 1) 시그널링 파서에 의해 파싱되어 수신기는 L1 시그널링 정보를 획득할 수 있다. L1 시그널링 정보는 수신기의 baseband controller에 전달되어 피지컬 레이어 데이터를 획득하는데 사용될 수 있다. 또한 L1 시그널링 정보는 수신기의 시그널링 컨트롤러에 입력될 수 있다. 또한 디코딩된 신호는 링크 레이어 인터페이스에 입력되어 L2 시그널링 파서에 의해 파싱되고, L2 시그널링 정보는 시그널링 컨트롤러에 입력될 수 있다. 시그널링 컨트롤러는 서비스 시그널링 채널 (service signaling channel, ssc) 프로세싱 버퍼 및 파서와 커뮤니케이션 할 수 있으며, 이를 통해 서비스 MAP DB(data base)를 업데이트 할 수 있다. 또한 서비스 가이드 (service guide, SG) 프로세서는 서비스 가이드 DB를 업데이트할 수 있다. 수신기는 시그널링 컨트롤러에 입력된 시그널링 정보에 따라 패킷 헤더를 복원하고 IP 패킷 필터를 이용하여 IP 패킷을 수신할 수 있다. 또한 수신기의 네트워크 스위치는 유무선 통신을 통해 IP 패킷을 수신할 수 있으며, TCP/IP 스택을 통해 이를 수신할 수 있다. 이렇게 수신된 IP 패킷은 common protocol stack을 거쳐 A/V 서비스 컨트롤러에 입력된다. 수신기의 디멀티플렉서는 오디오 데이터와 비디오 데이터를 역다중화할 수 있다. 수신기는 오디오 디코더 및 오디오 렌더러(renderer)를 이용하여 오디오 데이터를 출력하고, 비디오 디코더 및 비디오 렌더러(renderer)를 이용하여 비디오 데이터를 출력할 수 있다.
도 29는 본 발명의 일 실시예에 따른 컨텐트 서버, 멀티캐스트 서버 및 멀티캐스트 리시버를 나타낸 도면이다. 컨텐트 서버는 인코더(d29010) 및 송신부(d29020)를 포함할 수 있으며, 멀티캐스트 서버는 수신부(d29030), 패킷화부(d29035) 및 송신부(d29040)를 포함할 수 있다. 멀티캐스트 리시버는 수신부(d29050) 및 디코더(d29060)를 포함할 수 있다. 컨텐트 서버는 인코더(d29010)를 이용하여 컨텐트를 생성할 수 있으며, 이전 도면들에서 설명한 바와 같이 생성된 컨텐트를 분할하여 미디어 세그먼트로 저장할 수 있다. 컨텐트 서버는 송신부(d29020)를 이용하여 멀티캐스트 서버에게 미디어 세그먼트를 전송할 수 있다. 또한 컨텐트 서버는 MPD를 생성할 수 있으며, 도 21에서 설명한 바와 같이, 패스트 스타트업을 위한 정보가 새로운 supplemental Property descriptor의 확장을 통해 MPD 내에서 정의될 수 있다. 이를 통해 representation entry 중 패스트 스타트업이 가능한 representation을 시그널링할 수 있다. 즉, schemeIdUri 속성을 패스트 스타트업으로 정의하고, value 속성들에 대해 기존의 segment mode와 패스트 스타트업을 위한 Fastmode를 정의하여, 패스트 스타트업 빌딩 블록을 이용한 패스트 스타트업이 가능함을 DASH 클라이언트에게 시그널링할 수 있다.
멀티캐스트 서버는 컨텐트 서버로부터 미디어 데이터를 수신하여 멀티캐스트로 전송할 수 있다. 즉, 멀티캐스트 서버 내의 수신부(d29030)는 컨텐트 서버의 송신부로부터 미디어 데이터를 수신할 수 있으며, 멀티캐스트 서버 내의 송신부(d29040)는 멀티캐스트 프로토콜을 이용하여 미디어 데이터를 멀티캐스팅할 수 있다. 멀티캐스트 서버 내의 패킷화부(d29035)는 QUIC 프로토콜을 사용하여 미디어 데이터를 미디어 데이터 패킷으로 패킷화할 수 있다. 미디어 데이터 패킷은 QUIC 패킷일 수 있으며, 도 27에서 설명한 바와 같이 QUIC 헤더를 확장하여 패스트 스타트업 관련 정보를 시그널링할 수 있다. 즉, QUIC 헤더에 포함된 Frame type에서 ABR segment 확장 case를 인디케이트하고, 이 경우, QUIC 헤더에 포함된 header extension 값을 확장할 수 있다. QUIC 헤더에 포함된 header extension 필드는 FS, repID, Code point 및 QUIC PTS 필드를 포함하여 패스트 스타트업에 대해 시그널링하고, 패스트 스타트업을 지원할 수 있다.
멀티캐스트 리시버는 수신부(d29050)를 이용하여 멀티캐스트 서버로부터 미디어 데이터를 수신할 수 있다. 멀티캐스트 리시버의 수신부(d29050)는 QUIC 프로토콜을 이용하여 미디어 데이터를 수신할 수 있으며, 위에서 설명한 바와 같이 QUIC 헤더에 포함된 header extension 필드의 패스트 스타트업 관련 정보를 획득할 수 있다. 멀티캐스트 리시버는 디코더(d29060)를 이용하여 미디어 데이터를 디코딩할 수 있으며, 이 때 패스트 스타트업 관련 정보를 이용하여 신속한 미디어 스타트업을 수행할 수 있다. 실시에에 따라 디코더는 별도의 디코딩 디바이스에 포함될 수도 있으며, 이 경우에는 멀티캐스트 리시버가 디코딩 디바이스에 미디어 데이터와 함께 패스트 스타트업 관련 정보를 전달할 수 있다.
도 30은 본 발명의 일 실시예에 따른 멀티캐스트 서버의 동작 방법을 나타낸다. 멀티캐스트 서버는 컨텐트 서버로부터 미디어 데이터를 수신할 수 있다(ds30010). 멀티캐스트 서버는 수신된 미디어 데이터를 멀티캐스트하기 위해 QUIC 프로토콜을 사용할 수 있다. 멀티캐스트 서버는 도 27에서 설명한 바와 같이, UDP 패킷 내에 포함된 QUIC 헤더를 확장하여 패스트 스타트업 관련 정보를 시그널링할 수 있다. 멀티캐스트 서버는 QUIC 헤더에 패스트 스타트업을 지원하는지 여부, 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 삽입할 수 있다. 실시예에 따라 상기 정보들은 QUIC 헤더에 포함된 헤더 확장부(header extension)에 포함될 수 있다. 멀티캐스트 서버는 QUIC 프로토콜을 사용하여 미디어 데이터를 멀티캐스팅 할 수 있다(ds30020). 클라이언트는 QUIC 헤더 또는 헤더 확장부에 포함된 상기 정보들을 이용하여 패스트 스타트업을 수행할 수 있다.
도 31은 본 발명의 일 실시예에 따른 멀티캐스트 리시버의 동작 방법을 나타낸다. 멀티캐스트 리시버는 멀티캐스트 스트림을 수신할 수 있으며, 실시예에 따라 디코딩 디바이스를 포함할 수 있다. 아래에서는 디코딩 디바이스를 포함하는 멀티캐스트 리시버의 동작 방법을 설명한다. 멀티캐스트 리시버는 멀티캐스트 서버로부터 미디어 데이터를 수신할 수 있다 (ds31010). 미디어 데이터는 QUIC 프로토콜을 이용하여 송수신될 수 있다. 멀티캐스트 리시버는 QUIC 패킷 헤더를 파싱하여 패스트 스타트업 관련 정보를 획득할 수 있다. 패스트 스타트업 관련 정보는 QUIC 패킷 헤더 또는 헤더에 포함된 QUIC 헤더 확장부(header extension)에 포함될 수 있다. 멀티캐스트 리시버는 패스트 스타트업 관련 정보에 기초하여 미디어 데이터를 디코딩하고 사용자에게 멀티캐스트 서비스를 제공할 수 있다.
본 발명의 실시예에 따르면, 기존의 방송 네트워크 (network), 인터넷 (internet), 홈네트워크 (home network) 등에 속해있는 장치들(devices) 사이의 멀티캐스트 (multicast) 전송을 효과적으로 제공할 수 있다.
본 발명의 실시예에 따르면, 기존 unicast 전송을 multicast로 전환하여 network의 부하를 감소시킬 수 있다.
본 발명의 실시예에 따르면, 리니어 (Linear) 서비스 및 실시간 라이브 인코딩 시 네트워크 상황에 따라 발생되는 딜레이 문제를 극복하고, 신속한 컨텐츠의 재생 시작 (AV startup)을 지원할 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명의 영상 처리 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.
발명의 실시를 위한 형태는 위의 발명의 실시를 위한 최선의 형태에서 함께 기술되었다.
본원 발명은 방송 및 비디오 신호 처리 분야에서 사용 가능하고 반복 가능성이 있는 산업상 이용가능성이 있다.

Claims (15)

  1. 미디어 데이터를 수신하는 단계;
    상기 수신된 미디어 데이터를 전송 프로토콜을 이용하여 미디어 데이터 패킷들로 패킷화하는 단계; 및
    상기 미디어 데이터 패킷들을 멀티캐스팅하는 단계를 포함하는 멀티캐스트 송신 방법으로써,
    상기 전송 프로토콜에 의해 생성되는 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함하는 멀티캐스트 송신 방법.
  2. 제 1 항에 있어서,
    상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하는 것을 특징으로 하는 멀티캐스트 송신 방법.
  3. 제 2 항에 있어서,
    상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 하는 멀티캐스트 송신 방법.
  4. 제 1 항에 있어서,
    상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하는 멀티캐스트 송신 방법.
  5. 제 2 항에 있어서,
    상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 멀티캐스트 송신 방법.
  6. 미디어 데이터를 수신하는 수신부;
    상기 수신된 미디어 데이터를 전송 프로토콜을 이용하여 미디어 데이터 패킷들로 패킷화하는 패킷화부; 및
    상기 미디어 데이터 패킷들을 멀티캐스팅하는 송신부를 포함하는 멀티캐스트 송신 장치으로써,
    상기 전송 프로토콜에 의해 생성되는 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함하는 멀티캐스트 송신 장치.
  7. 제 6 항에 있어서,
    상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하는 것을 특징으로 하는 멀티캐스트 송신 장치.
  8. 제 7 항에 있어서,
    상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 하는 멀티캐스트 송신 장치.
  9. 제 6 항에 있어서,
    상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하는 멀티캐스트 송신 장치.
  10. 제 7 항에 있어서,
    상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 멀티캐스트 송신 장치.
  11. 전송 프로토콜에 따라 미디어 데이터 패킷들을 수신하는 단계, 상기 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함함;
    상기 패스트 스타트업에 대한 정보를 획득하고, 수신된 미디어 데이터 패킷들을 디코딩하여 패스트 스타트업을 수행하는 디코더를 포함하는 멀티캐스트 수신 방법으로써,
    상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하고,
    상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 하는 멀티캐스트 수신 방법.
  12. 제 11 항에 있어서,
    상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하는 멀티캐스트 수신 방법.
  13. 제 11 항에 있어서,
    상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 멀티캐스트 수신 방법.
  14. 전송 프로토콜에 따라 미디어 데이터 패킷들을 수신하는 수신부, 상기 미디어 데이터 패킷들은 각각 패킷 헤더와 페이로드를 포함하고, 상기 패킷 헤더는 패스트 스타트업 (fast startup)에 대한 정보를 포함함;
    상기 패스트 스타트업에 대한 정보를 획득하고, 수신된 미디어 데이터 패킷들을 디코딩하여 패스트 스타트업을 수행하는 디코더를 포함하는 멀티캐스트 수신 장치로써,
    상기 패스트 스타트업은 미디어 프리젠테이션 디스크립션 (Media Presentation Description, MPD), 초기화 세그먼트 (initialization segment) 파일 및 ISOBMFF (ISO base media file format) 파일을 포함하는 단일 빌딩 블록 (building block)을 이용하여 신속한 미디어 데이터를 프리젠테이션을 지원하고,
    상기 ISOBMFF 파일은 세그먼트 타입 박스 (segment type box, styp), 세그먼트 인덱스 박스 (segment index box, sidx), 무비 프래그먼트 박스 (movie Fragment Box, moof) 및 미디어 데이터 박스 (media data box, mdat)를 포함하고, 상기 mdat 박스는 미디어 데이터의 I 프레임만을 선택적으로 포함하는 것을 특징으로 하는 멀티캐스트 수신 장치.
  15. 제 14 항에 있어서,
    상기 전송 프로토콜은 QUIC (Quick UDP Internet Connections) 프로토콜이고, 상기 패킷 헤더는 상기 패스트 스타트업을 지원하는지 여부, 상기 미디어 데이터의 representation ID, code point 및 QUIC PTS (presentation time stamp) 정보 중 적어도 하나를 포함하고,
    상기 MPD는 상기 미디어 데이터에 속하는 representation이 패스트 스타업을 지원하는지 여부를 나타내는 디스크립터를 포함하는 멀티캐스트 수신 장치.
PCT/KR2017/013069 2017-03-22 2017-11-17 방송 신호 송수신 방법 및 장치 WO2018174367A1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/495,365 US20200021867A1 (en) 2017-03-22 2017-11-17 Broadcast signal transmitting and receiving method and device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762475214P 2017-03-22 2017-03-22
US62/475,214 2017-03-22
US201762478043P 2017-03-29 2017-03-29
US62/478,043 2017-03-29

Publications (1)

Publication Number Publication Date
WO2018174367A1 true WO2018174367A1 (ko) 2018-09-27

Family

ID=63584526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2017/013069 WO2018174367A1 (ko) 2017-03-22 2017-11-17 방송 신호 송수신 방법 및 장치

Country Status (2)

Country Link
US (1) US20200021867A1 (ko)
WO (1) WO2018174367A1 (ko)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11184665B2 (en) * 2018-10-03 2021-11-23 Qualcomm Incorporated Initialization set for network streaming of media data
EP3888319A1 (en) * 2018-11-30 2021-10-06 British Telecommunications public limited company Multicast to unicast conversion
US11564018B2 (en) * 2019-10-02 2023-01-24 Qualcomm Incorporated Random access at resync points of dash segments
US11831702B2 (en) * 2019-10-04 2023-11-28 Eexpway Method for broadcasting DASH/HLS hybrid multimedia streams
WO2022197169A1 (ko) * 2021-03-16 2022-09-22 엘지전자 주식회사 멀티캐스트 신호 처리 방법 및 장치
WO2024026025A1 (en) * 2022-07-27 2024-02-01 Audazzio, Inc. Secure scalable transmission of packet url instructions for second screen applications in digital transmitted program material

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060083263A1 (en) * 2004-10-20 2006-04-20 Cisco Technology, Inc. System and method for fast start-up of live multicast streams transmitted over a packet network
US20080046575A1 (en) * 2006-08-21 2008-02-21 Nokia Corporation Caching directives for a file delivery protocol
JP2008187723A (ja) * 2001-06-28 2008-08-14 Microsoft Corp コンテンツのストリーミングに使用するための改善された起動方法および装置
KR20150003296A (ko) * 2012-04-26 2015-01-08 퀄컴 인코포레이티드 저-레이턴시 스트림을 처리하기 위한 개선된 블록-요청 스트리밍 시스템
WO2016111563A1 (ko) * 2015-01-07 2016-07-14 삼성전자 주식회사 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008187723A (ja) * 2001-06-28 2008-08-14 Microsoft Corp コンテンツのストリーミングに使用するための改善された起動方法および装置
US20060083263A1 (en) * 2004-10-20 2006-04-20 Cisco Technology, Inc. System and method for fast start-up of live multicast streams transmitted over a packet network
US20080046575A1 (en) * 2006-08-21 2008-02-21 Nokia Corporation Caching directives for a file delivery protocol
KR20150003296A (ko) * 2012-04-26 2015-01-08 퀄컴 인코포레이티드 저-레이턴시 스트림을 처리하기 위한 개선된 블록-요청 스트리밍 시스템
WO2016111563A1 (ko) * 2015-01-07 2016-07-14 삼성전자 주식회사 통신 시스템에서 미디어 정보를 송수신하는 방법 및 장치

Also Published As

Publication number Publication date
US20200021867A1 (en) 2020-01-16

Similar Documents

Publication Publication Date Title
WO2018174367A1 (ko) 방송 신호 송수신 방법 및 장치
US9838329B2 (en) Devices, systems and methods for adaptive switching of multicast content delivery to optimize bandwidth usage
WO2012099423A2 (ko) 방송 시스템에서의 제어 메시지 구성 장치 및 방법
US8495688B2 (en) System and method for fast start-up of live multicast streams transmitted over a packet network
WO2012128563A2 (ko) 이종망 기반 연동형 방송콘텐츠 송수신 장치 및 방법
EP2385707B1 (en) Channel switching method, device, and system
US10171167B2 (en) Multimedia network data processing system
US20110219414A1 (en) Method, apparatus, and system for switching channels
WO2013169084A1 (ko) Mmt 패킷 포맷 확장을 통한 하이브리드 전송 방법
JP4195030B2 (ja) 連続的なビデオディスプレイのためのビデオデータの送信方法及び受信方法
WO2013077698A1 (ko) Mmt 미디어와 dash 미디어와의 연동 방법
WO2013077697A1 (ko) Ｍｍｔ 패키지화 컨텐츠의하이브리드 전송 방법 및 컨텐츠 수신 방법
WO2011068355A2 (ko) 상호 계층 최적화를 이용한 멀티미디어 데이터 패킷을 송신하는 방법 및 장치
WO2016129981A1 (ko) 미디어 데이터를 송수신하는 방법 및 장치
WO2011159093A2 (en) Hybrid delivery mechanism in a multimedia transmission system
US20110088069A1 (en) Network device, information processing apparatus, stream switching method, information processing method, program, and content distribution system
JP2002152301A (ja) データ通信システム、データ受信装置、データ通信方法、並びにプログラム記憶媒体
WO2018164355A1 (ko) 멀티캐스트 신호 송수신 방법 및 장치
WO2018186550A1 (ko) 방송 신호 송수신 방법 및 장치
WO2016043432A1 (ko) 멀티미디어의 전송 또는 수신 방법 및 그 장치
WO2017142347A1 (ko) 멀티미디어 서비스의 컨텐츠 관련 정보 제공 방법 및 장치
WO2013055168A1 (ko) 콤포지션 정보 및 전송 특성 정보가 연동된 미디어 데이터를 이종 ip 네트워크를 통하여 전송하는 방법
US20100002779A1 (en) Mechanism for the management of receivers/decoders connections
WO2018155798A1 (ko) 멀티캐스트 신호 송수신 방법 및 장치
WO2018016694A1 (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: 17902098

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17902098

Country of ref document: EP

Kind code of ref document: A1