WO2018226045A1 - Method for transmitting and receiving broadcast signal and apparatus therefor - Google Patents

Method for transmitting and receiving broadcast signal and apparatus therefor Download PDF

Info

Publication number
WO2018226045A1
WO2018226045A1 PCT/KR2018/006479 KR2018006479W WO2018226045A1 WO 2018226045 A1 WO2018226045 A1 WO 2018226045A1 KR 2018006479 W KR2018006479 W KR 2018006479W WO 2018226045 A1 WO2018226045 A1 WO 2018226045A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
media
information
content
segment
Prior art date
Application number
PCT/KR2018/006479
Other languages
French (fr)
Korean (ko)
Inventor
박종환
권우석
윤준희
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to DE112018002893.3T priority Critical patent/DE112018002893T5/en
Publication of WO2018226045A1 publication Critical patent/WO2018226045A1/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1863—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast comprising mechanisms for improved reliability, e.g. status reports
    • H04L12/1877—Measures taken prior to transmission
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64753—Control signals issued by the network directed to the server or the client directed to the client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/858—Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot

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.
  • Another object of the present invention is to provide a device and method compatible with the existing ABR service by defining a delivery method through baseURL without changing the structure of the existing manifest.
  • the media service receiving method receives and stores media presentation description information including segment Uniform Resource Locator (URL) information for media segments and timing information for presentation of the media segments.
  • a control message including at least one URL base pattern information for identifying at least one media segment transmitted in the multicast and at least one URL base pattern information for identifying at least one media segment transmitted in the unicast.
  • the control message further includes priority information of a representation including at least one media segment transmitted in the multicast and priority information of a representation including at least one media segment transmitted in the unicast. In one embodiment.
  • the control message may further include IP (Internet Protocol) address information and port information of a transport session for transmitting at least one media segment through the multicast.
  • IP Internet Protocol
  • control message further includes service identification information.
  • the control message may further include timing compensation information.
  • the control message may further include adjusting timing of a segment presentation by updating timing information in the stored media presentation description information based on the timing compensation information. .
  • the media service apparatus transmits media presentation description information including segment Uniform Resource Locator (URL) information on media segments and timing information for presentation of the media segments,
  • a transmission server for transmitting media segments transmitted over at least one of cast and unicast;
  • a multicast gateway that receives and stores the media presentation description information, receives and stores the media segments, and outputs a media segment requested for content playback among the stored media segments;
  • at least one URL basepattern information for identifying at least one media segment transmitted in the multicast and at least one URL basepattern information for identifying at least one media segment transmitted in unicast.
  • a network controller for generating and transmitting a message, wherein the multicast gateway receives the control message and transmits segment URL information in the stored media presentation description information based on each URL base pattern information included in the control message. Update.
  • the control message further includes timing compensation information, and the multicast gateway adjusts segment presentation time by updating timing information in the stored media presentation description information based on the timing compensation information.
  • the multicast gateway is located in at least one of a home gateway and a connected set-top box.
  • the proxy server may operate in an in-gateway transparent proxy mode.
  • playback at the receiver for the multicast service can be started quickly.
  • each delivery path can be distinguished using a baseurl in a segment, so that unicast and multicast networks can be used simultaneously, thereby shortening the switching time of the delivery path and increasing data bandwidth. It works. In particular, it is possible to identify whether the URL of the data selected for reproduction is the URL of the segment for multicast or the URL for unicast of a specific server.
  • 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. 3 is a diagram illustrating a case in which a content network includes a satellite relay according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating a case in which a content network includes a content delivery network (CDN) according to an embodiment of the present invention.
  • CDN content delivery network
  • FIG. 5 illustrates a wired multicast 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. 8 is a diagram illustrating a network structure for ABR multicast 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. 10 illustrates 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. 15 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. 20 illustrates a user network and an MPD according to an embodiment of the present invention.
  • 21 is a diagram illustrating details of an MPD according to an embodiment of the present invention.
  • FIG 22 illustrates an MPD for fast startup according to an embodiment of the present invention.
  • FIG. 23 is a diagram illustrating a system architecture for an ABR multicast service according to an embodiment of the present invention.
  • FIG. 24 illustrates an embodiment of defining a baseurl according to the multicast ABR delivery method according to the present invention.
  • 25 is a view showing embodiments of a baseurl included in the MPD according to the present invention.
  • 26 illustrates an embodiment of semantics of a control message according to the present invention.
  • FIG. 27 shows another embodiment of semantics of a control message according to the present invention.
  • FIG. 28 is a diagram schematically illustrating a corresponding part of the system architecture of FIG. 23 when the multicast gateway according to the present invention operates as a proxy server.
  • 29 to 33 are diagrams showing embodiments of operating methods according to proxy modes according to the present invention.
  • 34 illustrates an example of semantics of a segment timeline element included in an MPD according to the present invention.
  • 35 is a diagram illustrating an example of time information defined in a 'sidx' box in an index segment according to the present invention.
  • FIG 36 illustrates an example of time information elements included in an MPD according to the present invention.
  • 40 and 41 illustrate another embodiment of semantics of a control message according to 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 multi-cas 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.
  • the content network may include a broadcaster head-end.
  • Content generated by the broadcaster may be delivered to a multicast sender through encoding and packaging, and may be multicasted, or may be stored in a content server and delivered to a multicast sender when necessary.
  • the following describes each component included in the broadcaster head-end of the content network.
  • 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 stored in the content server may not need a separate encoding process.
  • 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.
  • the operator controller included in the broadcaster head-end manages content production and content server, and manages and controls a series of processes related to multicasting.
  • 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 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 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 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 user network may be referred to as a network that receives data from a multicast network and delivers the content included in the data to a device that consumes the content.
  • the user network may be variously configured according to the configuration of the user network and the type of service through multicast.
  • the multicast receiver described above may be included in a user network according to an embodiment. When the multicast receiver is included in the user network, the multicast receiver may receive the multicast content through a device serving as a gateway or proxy included in the user network. In this case, the gateway or proxy may be considered as a component of the ABR multicast network.
  • 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.
  • the home gateway may receive data from the ABR multicast network when the home network includes a plurality of devices.
  • the home gateway can perform data transmission and reception with an external network and can also simultaneously act as a proxy. If the home gateway acts as a proxy, the home gateway can cache data for delivery to the multicast receiver.
  • the multicast receiver may be included in the ABR multicast network described above, but may be located inside the home network due to the configuration of the network. Depending on the configuration of the home network, the multicast receiver can act as a proxy. If the multicast receiver cannot directly play the multicast stream, a decoding device capable of playing the multicast stream may be additionally connected to the multicast receiver. In addition, the multicast receiver may be connected with a plurality of decoding devices to transmit a multicast stream.
  • 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.
  • the protocol can be classified into a media protocol through which actual media data is transmitted, and a signaling protocol for controlling configuration of each node or entity for transmitting media data or for transmitting configuration information about media data to various nodes and entities including a receiver.
  • a signaling protocol for controlling configuration of each node or entity for transmitting media data or for transmitting configuration information about media data to various nodes and entities including a receiver.
  • Signaling and control information is transmitted using a signaling protocol, but when a receiver receives media content through a single connection, a separate signaling path may not be configured. In this case, signaling and control information can be delivered through the media protocol.
  • 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.
  • the multicast receiver may receive IP multicast packets to obtain adaptive streaming data and deliver them back to the decoder.
  • IP unicast protocol may be used between the multicast receiver and the decoder.
  • the content data received by the multicast receiver is delivered to the decoder again through IP unicast, and the decoder can decode and play data corresponding to the received media content format.
  • Transmission of signaling and control messages may be defined as a protocol distinct from media content transmission in order to provide transmission control, scheduling, configuration information, etc. in each node and entity performing adaptive streaming. have. Depending on the case where each node and entity is connected, it can be defined as a separate protocol.
  • signaling and control messages may be included and transmitted in a protocol for transmitting media content, but such signaling and control messages follow a protocol for media content delivery.
  • a control protocol may be defined between an operator controller included in a content network and a network controller included in a multicast network.
  • the network controller can also send a response or report message to the operator controller in order for the operator controller to generate control and management messages.
  • the tunneling protocol tunneling protocol
  • the tunneling protocol for sending a control message can be configured in both directions.
  • a single operator controller can send and receive control messages with multiple multicast network controllers.
  • each multicast network controller can be managed by a separate operator.
  • the configuration related information of the network may be transmitted to the multicast sender and the multicast receiver.
  • the network controller may transmit configuration information about network resources, mapping information between nodes of the network, routing information, and the like.
  • the configuration information received from the operator controller may be transmitted to the multicast sender or the multicast receiver.
  • the protocol transmitted from the multicast network controller to the multicast sender and the protocol transmitted to the multicast receiver may be distinguished. The upper part of the figure shows the protocol transmitted from the network controller to the multicast sender, and the lower part of the figure shows the protocol transmitted from the network controller to the multicast receiver.
  • IP multicast may be used to deliver configuration messages from a single network controller to a plurality of multicast senders and multicast receivers. Connections, statistical information, etc. collected by the multicast sender and the multicast receiver may be reported to the multicast network controller. Since this process can be performed independently by each multicast sender and multicast receiver, a unicast protocol can be used. This set of control information, configuration information, etc. can be dynamically updated and transmitted immediately or through scheduling.
  • the multicast receiver may use a signaling protocol for sending the received adaptive streaming data back to the decoding device.
  • an IP unicast protocol may be defined to provide separate information to individual decoding devices.
  • the decoding device may transmit signaling of the request of the decoding device to the multicast receiver using an IP unicast protocol. Therefore, it can be defined as a bidirectional protocol between the multicast receiver and the decoding device.
  • the multicast network controller may be connected to the multicast receiver via a multicast sender rather than directly to the multicast receiver.
  • the configuration related information of the network may be transmitted to the multicast sender and the multicast receiver.
  • the network controller may transmit configuration information about network resources, mapping information between nodes of the network, routing information, and the like.
  • the configuration information received from the operator controller may be transmitted to the multicast sender or the multicast receiver.
  • the multicast sender can forward the configuration message transmitted from the network controller to the multicast receiver.
  • a protocol or message set related to configuration may be distinguished from a protocol transmitted to a multicast sender and a protocol transmitted to a multicast receiver.
  • IP multicast may be used to deliver configuration messages from a single network controller to a plurality of multicast senders and multicast receivers. Connections, statistical information, etc. collected by the multicast sender and the multicast receiver may be reported to the multicast network controller. Since this process can be performed independently by each multicast sender and multicast receiver, a unicast protocol can be used. This set of control information, configuration information, etc. can be dynamically updated and transmitted immediately or through scheduling.
  • Information such as reports sent from the multicast receiver to the multicast network controller can be delivered to the multicast network controller through the multicast sender. 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.
  • a protocol and a packet format corresponding to each layer may be determined. Each protocol may be configured independently or specific protocols may be combined for interoperability.
  • the operation of compressing the video and audio data collected by the encoder, converting it into an appropriate codec, and delivering it to a packager may be performed as data processing inside the transmission system.
  • efficient codec can be used, codec such as HEVC (High Efficiency Video Coding), AVC (Advanced Video Coding) can be used for video data, and AAC (Advanced) for audio data. Audio Coding), AC4 (audio compression 4), Moving Picture Experts Group-H (MPEG-H) audio codec and the like can be used.
  • Each codec can be packaged in a form suitable for transmission or storage.
  • ISO base media file format ISOBMFF
  • CMAF Common Media Application Format
  • MPEG-2 TS Transport Stream
  • DRM Digital Rights Management
  • DRM Digital Rights Management
  • 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.
  • Transmission Control Protocol / Internet Protocol (TCP / IP) or User Datagram Protocol / Internet Protocol (UDP / IP) may be used depending on the configuration of the upper protocol.
  • IGMP Internet Group Management Protocol
  • Layer 2 and Layer 1 protocols may be defined for each transport link. That is, an optimized protocol may be configured according to a link between nodes and entities configured on a network. For example, in a LAN (Local Area Network) environment, Layer 2 may be defined as Ethernet, and Layer 1 may be defined as CSMA / CD (Carrier sense multiple access with collision detection) 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).
  • the protocols used on the server for content are the media codec and file format.
  • the media codec may include video, audio or other encoding formats.
  • the video may include a codec such as HEVC and AVC
  • the audio may include a codec such as AAC, AC4, and MPEG-H audio codec.
  • the protocol for the file format may be defined as a format for transmitting or storing the codec format in the form of a file.
  • file formats such as ISOBMFF and CMAF may be used, and may be transmitted using the format of MPEG-2 TS when the existing broadcast network is connected.
  • a plurality of formats may be used for streamlining the file format.
  • the protocol between the server and the multicast sender can mainly define a protocol for efficient delivery of file formats. Therefore, the data of the content generated in the server can be delivered using a tunneling protocol.
  • the tunneling protocol may mainly use a real-time transmission protocol such as RTP, and other IP-based tunneling protocols that may be used in the corresponding network. At this time, the existing protocol may be used as it is or the definition of the field may be changed to suit the network.
  • a tunneling protocol may be defined at an input terminal to receive a file transferred from the server using the tunneling protocol. In this case, since the file format transmitted using the tunneling protocol is data to be transmitted from the multicast sender to the multicast receiver, the tunneling protocol may operate regardless of the format of the corresponding data.
  • the protocol between the multicast sender and the multicast receiver can be defined primarily as a protocol for adaptive streaming. These protocols can be composed of DASH-based protocols.
  • the lower layer protocol is based on IP multicast.
  • a protocol such as HTTP may be used together for DASH to operate, and when a DASH segment is used as a file, a file transfer protocol such as FLUTE may be configured.
  • TCP / IP can be used for the connection and multicast transmissions on an effective network of the DASH / HTTP protocol.
  • Multicast receivers can use TCP / IP to receive packet streams sent in multicast.
  • the multicast receiver may use HTTP for a request for a packet stream, a response for received data, and the like.
  • the multicast receiver may include a DASH client. Data streamed adaptively using DASH consists of a file format sent by the server. Accordingly, the multicast receiver may use a file format related protocol capable of identifying the corresponding file format and a media codec capable of decoding the identified media format.
  • the media delivery protocol illustrates a specific embodiment of the protocol according to a path through which media content is transmitted.
  • This embodiment shows a case in which the multicast receiver is composed of a device or module separate from the decoder (media player). Therefore, the multicast receiver needs to transmit the received multicast stream to the decoding device (decoder).
  • Multicast receivers can use TCP / IP to receive packet streams sent in multicast.
  • the multicast receiver may use HTTP for a request for a packet stream, a response for received data, and the like.
  • the multicast receiver may include a DASH client.
  • the multicast receiver may act as a proxy for data adaptively streamed using DASH.
  • the multicast receiver can deliver data to the decoding device. Since the number of decoding devices connected to the multicast receiver can be limited, the connection can be based on unicast transmissions. Thus, multicast receivers can use the HTTP and TCP / IP protocols for unicast connections.
  • the decoding device may use a unicast protocol to receive data sent from the multicast receiver.
  • Data delivered via HTTP unicast may have a file format sent by the server.
  • the decoding device may use a file format related protocol capable of identifying the corresponding file format and a media codec capable of decoding the identified media format. Operation for other protocols is the same as the embodiment described in the previous drawings.
  • the method of transmitting the DASH segment may use the Quick UDP Internet Connections (QUIC) protocol.
  • QUIC Quick UDP Internet Connections
  • Multicast schemes using TCP / IP may incur delays in establishing connections and may not be suitable for immediate delivery of streaming data.
  • the QUIC-based protocol takes care of the connection and flow control at QUIC.
  • QUIC can use HTTP / 2, which can improve the transmission delay incurred by the existing HTTP, and can also immediately transmit streaming data using UDP / IP. Operation for other protocols is the same as the above-described embodiment.
  • the DASH system may be implemented by transmitting and receiving data between the HTTP server and the DASH client.
  • the DASH client may include a DASH access engine and a media engine.
  • an HTTP server can divide content of varying quality into segments on a regular basis and store them on the server.
  • the HTTP server may transmit the divided data unit by using the HTTP protocol when a media request of the DASH client which is a user device is performed.
  • it is possible to selectively transmit the media content stored in the HTTP server in various qualities. This allows the user to receive a seamless adaptive streaming service.
  • a separate file including information on a timeline order and a quality order of the divided files described above is a media presentation description (MPD).
  • the MPD may provide the DASH client with information about the media data stored on the HTTP server.
  • the MPD is an XML document and may include attributes such as URL, start time, content type, and the like assigned to the divided segment.
  • the DASH client may request the MPD file from the server prior to receiving the media file and receive the MPD file. When the MPD file is received, the DASH client may request a segment file for the content stored in the HTTP server by using the information about the media file included in the MPD.
  • the DASH segment is a data unit of a transport object that can be reproduced for a predetermined period by dividing the content to be transmitted into media segments.
  • the DASH media segment includes a 'styp' box indicating a segment type and a 'sidx' box containing segment index information.
  • the DASH media segment may include a 'mdat' box containing a media stream cut in fragment units and a 'moof' box containing metadata thereof.
  • the DASH client may request transmission of an MPD file, a manifest file, to request a service, and may request a media segment through each segment Uniform Resource Locator (URL).
  • the DASH client receives and parses an initialization segment (IS) file containing the initialization information, performs decoder initialization, and then receives the requested media segment file to perform media parsing and decoding. Can be.
  • IS initialization segment
  • Files received by the DASH client may be classified according to components for media playback.
  • the DASH client can play the media after receiving the manifest file, the MPD, the initialization segment file, and the media segment file. Therefore, the transmitting media encoder can encode mdat including media data for the entire play block (MPD + IS + sidx + moof + mdat) and generate a metadata header (styp + sidx + moof) containing the encoding information. have. Thereafter, the transmitting end may generate an IS.mp4 file, which is decoder initialization information, write the MPD including the URL information of the segment and transmit the same to the DASH client.
  • the parsing order of the receiving end is as follows. The receiving end may receive and parse the MPD file, initialize the decoder, and request a media segment according to network conditions.
  • FIG. 19 illustrates a structure, a generation, and a parsing sequence of a DASH segment according to an embodiment of the present invention.
  • MPD, IS, sidx, moof, and I frames described in the previous drawings may be made into a single building block and transmitted in advance in order to reduce transmission / reception delay of media data and fast media playback at a receiving end. This may be referred to as a fast startup building block.
  • the DASH client can perform playback via MPD transmission and segment request according to the conventional model in unicast. While operating the DASH framework, the DASH client can be included in a single building block to execute fast startup using the I frame received with the MPD.
  • the transmitting end server may reduce the reception delay by selectively transmitting the I frame without transmitting the entire mdat frame covered by the moof header.
  • the DASH client may perform a fast audio and video (AV) startup by starting playback from an I frame which is a random access point (RAP).
  • the transmitter server instead of making all segments of the full quality, the transmitter server considers the network situation or selectively creates the representation / segment that enables fast start-up considering the network operator, and creates the light MPD for this.
  • Can transmit can receive the light MPD and configure the fast startup building block to quickly start playing. Thereafter, the DASH client may receive a different quality segment from the proxy to perform bitstream switching according to the quality of the segments.
  • the transmitting end server may transmit only considering segments for fast start-up, and may include delay information for fast start-up in the MPD to minimize delays until media data is played.
  • 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.
  • the representation in the aforementioned MPD may include a descriptor that can indicate a common attribute, and may include a common attribute descriptor as shown in the upper part of the figure.
  • the common attribute may include supplemental property descriptors, and through this, an element necessary for the framework of the representation may be defined.
  • Such a descriptor type element may define an attribute of what operation should be performed through the schemeIdUri attribute as shown in the middle of the drawing, and a specific code point for a specific operation may be defined through the value attribute.
  • the information for fast startup described above can be defined in the MPD through the extension of a new supplemental property descriptor, thereby signaling the fast startable representation among the representation entries. That is, as shown at the bottom of the figure, the schemeIdUri attribute may be defined as fast startup, and the existing segment mode and the fast mode for the fast startup may be defined for the value attributes.
  • the fastmode may signal to the DASH client that fast startup is possible using the fast startup building block described in the previous figure.
  • MPD for fast startup according to an embodiment of the present invention.
  • MPD can be expressed in XML, define the schemeIdUri attribute of the supplemental property element to Faststartup, and set the value attribute to Fastmode for Representation that supports fast startup Can be.
  • the MPD may signal to the DASH client that the representation is a representation that supports the aforementioned fast startup.
  • FIG. 23 illustrates a system architecture for ABR multicast service according to an embodiment of the present invention.
  • 23 shows a content provider metrics reporting capture unit 1010, a content provider controller 1020, a content preparation unit 1030, and a content hosting unit. (content hosting unit) 1040, multicast server 1050, provisioning unit 1060, multicast gateway 1070, and content playback unit (1080). 23 further includes a service discovery unit 1091, a DRM license management unit 1093, and a unicast repair unit 1095. Can be.
  • the content preparation unit 1030 may include a content encoding unit 1031, a content encryption unit 1033, and a content packaging unit 1035.
  • the multicast server 1050 may include a content ingest unit 1051 and a multicast transmitter 1053.
  • the provisioning unit 1060 may include a service reporting capture unit 1061 and a network controller 1063.
  • the multicast gateway 1070 may include a service reporting unit 1071, a service management unit 1072, a multicast receiving unit 1073, an asset storage unit 1074, and a unicast repair client ( 1075).
  • the content playback unit 1080 includes a playback metric reporting unit 1081, a content unpackaging unit 1083, a content decoding unit 1085, and a content decryption unit. (1087).
  • the next reference points in FIG. 23 are mainly used for transmitting content.
  • the interface L is a unicast HTTP interaction interface between the multicast gateway 1070 and the content playback unit 1080, which includes fetching of all specified types of content (This interface L includes the fetching of all). specified types of content). If the multicast gateway 1070 and the content player 1080 co-locate together in a single end device such as a set-top box, the interface L may be a local application programming interface (API). may be realised as a local API).
  • API application programming interface
  • This interface B is a bootstrap unicast HTTP (S) interaction between the content hosting unit 1040 and the content reproducing unit 1080. This interface B is used to fetch manifests and retrieve content in an unmediated case.
  • S bootstrap unicast HTTP
  • A is an HTTP (S) acquisition interface for content that is not provided through interface M. It is also used by the multicast gateway 1070 to receive and retrieve content directly from the content hosting unit 1040 via unicast when the interface U cannot perform content repair.
  • S HTTP
  • the M is an interface for transmitting multicast IP content from the multicast server 1050 to the multicast gateway 1080.
  • the interface M may also be used to transmit multicast IP content from the multicast server 1050 to the unicast repair unit 1095.
  • U is a unicast interaction interface between the unicast repair unit 1095 and the unicast repair client 1075 of the multicast gateway 1070.
  • U ' is a unicast interaction interface between the unicast repair unit 1095 and the multicast server 1050.
  • P in is a publication of content provided from the content packaging unit 1035 of the content preparation unit 1030 to the content hosting unit 1040. This can be done with the push interface, or the content can be pulled on demand.
  • O in is an ingest of content exchanged between the content hosting unit 1040 and the multicast server 1050. This is usually done with the pull interface.
  • P in ′ is an ingest of content provided from the content packaging unit 1035 of the content preparation unit 1030 to the multicast server 1050. This is usually done with the push interface.
  • C MR Control interface for configuration of multicast gateway (1070).
  • C CP Control interface for configuration of provisioning unit (1060).
  • R S Service reporting by service reporting unit (1071) to service reporting capture unit (1061).
  • R CP Service reporting by service reporting capture unit (1061) to content provider metrics reporting capture unit (1010).
  • R PM Reporting of playback metrics by content playback unit (1080) to content provider metrics reporting capture unit (1010).
  • the multicast server 1050 may be referred to as a multicast sender, and the multicast gateway 1070 may be referred to as a multicast proxy.
  • the content playback unit 1080 may also be referred to as a client or a DASH client.
  • the present invention describes a case where the manifest is an MPD according to an embodiment.
  • the content encoding unit 1031 of the content preparation unit 1030 receives the content from the content provider controller 1020 and performs encoding. That is, the content encoding unit 1031 converts the source media streams into encoded media to reduce the bit rate. The single source media stream can then be converted into many different encoded representations.
  • the content encryption unit 1033 performs encryption on the content encoded by the content encoding unit 1031 under the control of the DRM license management unit 1093. The encryption of the content encryption unit 1033 is optional. When the encryption is performed in the content encryption unit 1033, the content decryption unit 1087 of the content playback unit 1080 may also decrypt the encrypted content under the control of the DRM license management unit 1093. Perform.
  • the DRM license management unit 1093 provides the encryption keys to the content encryption unit 1033 and the content decryption unit 1087.
  • the content that is output by bypassing or encrypting the content encryption unit 1033 is packaged in a format suitable for multicast transmission in the content packaging unit 1035 and transmitted to the multicast server 1050 and / or the content hosting unit 1040. Is sent to.
  • a format suitable for multicast transmission may be, for example, a media segment created by dividing one content.
  • the content packaging unit 1035 may generate a manifest and transmit the manifest to the multicast server 1050.
  • the manifest may be generated by the content hosting unit 1040 and provided to the multicast server 1050.
  • the manifest may be generated by the content provider controller 1020 and provided to the content preparation unit 1030.
  • the manifest may be generated in the multicast server 1050.
  • the content prepared by the content preparation unit 1030 may be available by the content hosting unit 1040 for unicast delivery.
  • the content hosting unit 1040 may be implemented as a part of simple web servers, an origin cluster, or may be operated as a distributed content delivery network (CNS) system. Therefore, load balancing and request balancing techniques (eg DNS round-robin, HTTP 302 redirect) can be used to direct clients to the most appropriate content server.
  • DNS distributed content delivery network
  • the multicast server 1050 encapsulates media content (eg, media segments) output from the content preparation unit 1030 into a packet format suitable for multicast transmission, and then uses a specific transport protocol stack. Transmit to multicast gateway 1070.
  • media content eg, media segments
  • transport protocol stack one of Real-Time Object Delivery over Unidirectional Transport (ROUTE), HTTP QUIC, FLUTE, and NORM (NACK-Oriented Reliable Multicast) of cable IPTV may be used. That is, in the multicast server 1050, the payload of the ingested media stream is encapsulated into a delivery unit of a multicast transport protocol and then subscribed to using multicast gateways over IP interface M. 1070 is sent over the network to the clients. Both push and pull content ingest methods are possible in the multicast server 1050.
  • the unicast repair unit 1095 listens to multicast content transmission through the reference point M, and copies a copy of the packet stream used to satisfy the repair request received from the unicast repair client 1075. Cache locally.
  • the multicast gateway 1070 provides the packetized content segments to the content playback unit 1080.
  • the multicast gateway 1070 may receive media segments multicast from the multicast server 1050. In addition, the multicast gateway 1070 may receive media segments in unicast through at least one of the content hosting unit 1040, the multicast server 1050, and the unicast repair unit 1095. In particular, when the multicast gateway 1070 fails to perform content repair in the unicast repair unit 1095, the multicast gateway 1070 may receive content directly from the content hosting unit 1040 through unicast through the interface A.
  • the present invention locates the multicast gateway 1070 closest to the content player 1080 and stores media segments (ie, content segments) provided from the multicast server 1050 to a specific transport protocol stack. After the dispersion is an embodiment. That is, the multicast gateway 1070 located closest to the content playback unit 1080 stores the media segments packetized according to the transmission format in the multicast server 1050 and provided to a specific protocol stack, and then the content. According to an embodiment of the present disclosure, a corresponding media segment among the stored media segments is provided to the content playback unit 1080 according to a request of the playback unit 1080 (for example, execution of a specific application or channel switching). In other words, the media segment requested by the content player 1080 does not go to the multicast server 1050, but is provided directly to the content player 1080 from the multicast gateway 1070.
  • media segments ie, content segments
  • the multicast gateway 1070 having the above function is located in a customer premises equipment such as a home gateway or an IP-connected set-top box.
  • the multicast gateway 1070 may operate as a proxy server.
  • content requests when received from content playback unit 1080 via interface L, they may be serviced directly from content cached in asset storage 1073 or indirectly from content recovered via interface A.
  • the recovered content may be cached in the asset storage 1073.
  • the service management unit 1072 of the multicast gateway 1070 collects and analyzes service configuration information regarding the multicast content stream available through the interface M as well as the location of the service reporting capture unit 1061.
  • the information may be directly received from the network controller 1063 through the reference point C MR or indirectly from the multicast receiver 1073 of the multicast gateway 1070.
  • the multicast receiver 1073 ingests the content streams through the interface M.
  • the received content may then be cached in asset storage 1074 for later use.
  • the unicast repair client 1075 recovers the losted multicast packet.
  • the asset storage 1074 provides temporary storage of assets provided through interface L.
  • the service reporting unit 1071 reports service-related metrics (eg, telemetry and analytics data) to the service reporting capture unit 1061 through the interface Rs.
  • service-related metrics eg, telemetry and analytics data
  • the network controller 1063 controls, configures, and provisions network resources. These network resources include resources for multicast transmission and resources for unicast transmission.
  • the network controller 1063 distributes configuration information about available multicast streams to network resources.
  • the configuration information may be distributed to the multicast server 1050 through the reference point C MS and / or to the multicast gateway 1070 through the reference point C MR .
  • the configuration information about the available multicast streams may be updated according to the number of content provider controllers 1020 and / or client requests.
  • the content reproduction unit 1080 is an entity managing for requesting, receiving, decrypting, and presenting content.
  • the content playback unit 1080 may be located separately from the multicast gateway 1070 on an end device such as a smart phone. In addition, the content playback unit 1080 may be combined with the multicast gateway 1070 in a set-top box or a connected TV set.
  • the content unpackaging unit 1083 extracts elementary stream data from the retrieved transport object and provides the extracted elementary stream data to the content decoding unit 1085 or the content decryption unit 1087.
  • media data box es
  • es is extracted for ISO Base Media File Format segments
  • payloads of reconstructed PES are extracted for MPEG-2 Transport Streams.
  • the content decoding unit 1085 parses and interprets the contents of the elementary media streams and renders them for playback on a screen or speaker.
  • the content decoding unit 1085 may include a plurality of decoding devices, and the plurality of decoding devices may simultaneously access the multicast gateway 1070.
  • Each decoding device may transmit and receive data with the multicast gateway 1070 through unicast or multicast. That is, the decoding device may connect to a unicast network that receives a unicast stream in addition to the multicast network that receives the multicast stream.
  • the application 1097 controls the content playback unit 1080.
  • the application may include a control application (eg, an EPG application) embedded on an integrated television or set top box or a third application provided by a content provider.
  • the application 1097 interacts with the service management portion 1072 of the multicast gateway 1070 to discover the existence of linear services and to control their reception by the multicast gateway 1070.
  • the content playback unit 1080 receives a manifest through a bootstrap, which is an interface B.
  • the content playback unit 1080 receiving the manifest sends a specific media segment to the multicast gateway 1070 based on the information in the manifest that contains the information (for example, IP address, hostname) of the multicast gateway 1070.
  • the multicast gateway 1070 finds a media segment requested by the content playback unit 1080 among the stored media segments received from the multicast server 1050 and provides the media segment to the content playback unit 1080.
  • the content playback unit 1080 when the content playback unit 1080 receives the manifest, the content playback unit 1080 selects a representation of an appropriate quality according to the DASH model, and then transmits the URL of the media segment to the multicast gateway 1070. Receive a media segment corresponding to the URL from gateway 1070.
  • the content playback unit 1080 receives a representation including the media segment from the multicast gateway 1070 according to the segment template in the manifest.
  • a specific service for example, a linear service
  • the choice of representation is necessary.
  • the service is transmitted in another delivery path, for example, in multicast and simultaneously in unicast.
  • the content playback unit 1080 may select and service the representation transmitted in unicast.
  • the present invention refers to multicast as a first delivery pass (or first delivery method), unicast as a second delivery pass (or second delivery method), and vice versa.
  • the broadcast will be referred to as a third delivery pass (or third delivery method).
  • the multicast gateway in which the URL of the media segment included in the selected representation supports ABR is encapsulated. It is not possible to identify whether the URL is a segment of my segment or an HTTP URL for unicast of a particular server.
  • the content playback unit 1080 requests in the form of round the side and receives the media segment url of the new unicast service.
  • the process is necessary. This process may cause a service black out issue during live, and may cause an increase in latency.
  • the live service since the multicast protocol and the unicast protocol are different, different buffer management considering different parsing process and capacity is performed. For this reason, it is important to distinguish the delivery path.
  • data is delivered in multicast form through interface M ⁇ , and the unicast repair unit 1095 receives the data and receives the multicast gateway.
  • the multicast gateway 1070 and the lost media segment may be received in the form of a unicast request.
  • the multicast gateway 1070 since the multicast gateway 1070 needs to receive and process a media segment through a unicast path, the multicast gateway 1070 needs to be distinguished from segment information of the existing multicast.
  • the present invention proposes a method of identifying the URL of a segment transmitted by multicast and the URL of a segment transmitted by unicast.
  • each representation of the MPD of FIG. 20 has a baseurl for each segment to define a string that is the basis for obtaining the segment.
  • the baseurl is manipulated according to a delivery method, so that the delivery path is known to which delivery path should be requested.
  • the baseurl for each delivery method defined in FIG. 24 is included in a control message provided from the network controller 1063 of the provisioning unit 1060 and provided to the service management unit 1072 of the multicast gateway 1070. do.
  • the service management unit 1072 of the multicast gateway 1070 updates the baseurl of the MPD stored in advance with the baseurl provided in the control message of the network controller 1063.
  • the IP-based media service may be provided in one of multicast and unicast, but may be simultaneously provided in multicast and unicast.
  • the media service is provided in one of multicast and unicast, only the baseurl according to the corresponding delivery method is provided by the network controller 1063.
  • the baseurl according to multicast is provided.
  • a baseurl according to unicast may be provided together in the network controller 1063.
  • the MPD is a representation and unicast including the baseurl of the media segment transmitted in multicast Each may include a representation including the baseurl of the media segment transmitted to.
  • the multicast gateway 1070 creates a base string pattern based on the configuration of FIG. 24 and generates an address for accessing a media segment through a base URL and a segment template.
  • FIG. 25 illustrates embodiments of a baseurl included in an MPD according to the present invention. If the baseurl of a media segment included in the representation selected by the content playback unit 1080 is the same as a in FIG. 25, the representation is transmitted by multicast. Determine and request a media segment to be transmitted in multicast. As another example, if the baseurl of the media segment included in the representation selected by the content playback unit 1080 is the same as that of b of FIG. 25, it is determined that the representation is transmitted in unicast, and the media segment transmitted in unicast is requested.
  • the manifest is manipulated through the base pattern, and the media segment is requested based on the base string that can be distinguished according to the delivery path.
  • the present invention can simultaneously provide a unicast-based service and a multicast-based service capable of distributing packet traffic when providing an IP-based media service. This has the advantage of allowing greater use of data bandwidth.
  • the present invention provides a method compatible with the existing ABR service by defining a delivery method through baseURL without changing the structure of the existing manifest.
  • FIG. 26 shows an embodiment of the semantics of a control message (or multicast network control message) provided by the network controller 1063 to the multicast gateway 1070 using the interface C MR in accordance with the present invention.
  • the control message may be in XML (eXtensible Markup Language) format and / or HTTP restful API message format.
  • a control message for providing an ABR multicast service is in the form of an HTTP restful API message.
  • the control message is C MS and C MR It can be delivered through an interface that can transmit control messages.
  • the control message may generate manifest information (eg, MPD) for service initialization in consideration of information processing interoperability of the service provider / Internet service provider and a linear network environment.
  • manifest information eg, MPD
  • the delivery control may include an @sIPaddr element, an @dIPaddr element, an @dport element, an @serviceId element, and a deliverymethod element as lower elements.
  • the @sIPaddr element indicates a source IP address of a multicast session (eg, a ROUTE session) carrying a media service.
  • the @dIPaddr element indicates a destination IP address of a multicast session for transmitting a media service.
  • the @dport element indicates a destination port number of a multicast session for transmitting a media service.
  • the @serviceId element is used to identify a media service and may be one of a service entry, adaptation-set @ id, and MPD @ id.
  • the deliverymethod element may be a container of delivery related information belonging to the content of the media service on the multicast or unicast mode of access.
  • the deliverymethod element may include a multicast_service element and / or a unicast_service element. Each of these elements may have a basepattern element and a priority element as subelements.
  • the multicast_service element may be a DASH representation delivered on a multicast including corresponding media component (s) belonging to a multicast service. That is, each of the present fields may refer to DASH representations delivered through multicast.
  • the basepattern element which is a sub-element of the multicast_service element, may indicate a character pattern used by the multicast ABR receiver to match the segment URL used by the DASH client. This can be used by the DASH client to request DASH media segments of the parent DASH representation. Matching may imply that the corresponding DASH media segment is delivered via multicast.
  • the priority element which is a lower element of the multicast_service element, indicates the priority of the DASH representation delivery considering the network and the capacitor in order to provide a multicast service.
  • the unicast_service element may be a DASH representation delivered on unicast including corresponding media component (s) belonging to a unicast service. That is, each of the present fields may mean DASH representations transmitted through unicast.
  • the basepattern element which is a sub-element of the unicast_service element, may indicate a character pattern used by the multicast ABR receiver to match the segment URL used by the DASH client. This can be used by the DASH client to request DASH media segments of the parent DASH representation. Matching may imply that the corresponding DASH media segment is delivered via unicast.
  • the priority element which is a lower element of the unicast_service element, indicates the priority of the DASH representation delivery considering the network and the capacitor to provide the unicast service.
  • FIG. 27 is the same as FIG. 26 except that the broadcast_service element is included as a lower element in the deliverymethod element and the basepattern element and the priority element are included as the lower element in the broadcast_service element. Therefore, description of each element will be referred to FIG. 26 and will be omitted here.
  • the multicast gateway 1070 may be provided to the multicast gateway 1070 periodically or whenever data in the semantics is updated.
  • the control message may be transmitted to the multicast gateway 1070 in advance to adaptively correspond to the operation of the multicast gateway 1070. That is, the string of the multicast path and the string of the unicast path included in the control message are delivered to the multicast gateway 1070 in advance.
  • the multicast gateway 1070 is transmitted through the path of the strings. It can adaptively cope with the operation of.
  • the network controller 1063 may transmit a control message as shown in FIG. 26 or FIG. 27 to the multicast gateway 1070.
  • the multicast gateway 1070 transmits the data to the multicast gateway 1070 before being transmitted.
  • the media segment is sent from the multicast server 1050 to the multicast gateway 1070.
  • a string included in Fig. 27 in another embodiment is included in the periodic configuration information of the SDP, DVB IPTV used by the 3GPP STP, or a 3 rd party may be transmitted to the multicast gateway 1070 .
  • the present invention will be described in one embodiment by the network controller 1063 to be included in the control message to the multicast gateway 1070.
  • the network controller 1063 may control the operation of the multicast gateway 1070 by transmitting a service query or control message such as acquisition, initialization, etc. of a service through the multicast gateway 1070. Can be.
  • the network controller 1063 may transmit a control message for controlling a media service transmitted from the multicast server 1050 using the interface C MR .
  • a control message for controlling a media service transmitted from the multicast server 1050 using the interface C MR .
  • the network controller 1063 may transmit a control message for controlling a media service transmitted from the multicast server 1050 using the interface C MR .
  • the network controller 1063 may transmit a control message for controlling a media service transmitted from the multicast server 1050 using the interface C MR .
  • a control message for controlling a media service transmitted from the multicast server 1050 using the interface C MR .
  • the segment URL defined in the media representation is accessible as an IP and a port of the corresponding multicast session, and can be accessed through at least one of component / adaptation identification information, MPD identification information, and service entry identification information in a transmitted manifest. Access to strings is possible.
  • the base pattern distinguishing the multicast / unicast service and the base URL in the manifest file can be matched to find out which path the media segment can serve. In other words, it is possible to identify whether the protocol supporting ABR is the URL of a segment in the encapsulated multicast gateway 1070 or an HTTP URL for unicast of a specific server.
  • the delivery method can be defined to implement proper receiver operation and to be able to switch services immediately without rounding the site.
  • the priority information may define a priority of the multicast / unicast path considering the media segment capacitor in the current interface M and the multicast gateway 1070 to implement a seamless service.
  • the network controller 1063 includes both the multicast route information and the unicast route information in the control message and delivers the multicast gateway information to the multicast gateway 1070 to periodically update the multicast service information and the unicast service information of the MPD.
  • the service switching time can be reduced when switching from a multicast service to a unicast service or vice versa.
  • priority can be set by the priority element.
  • the mode of the proxy server may configure various operation modes.
  • the multicast gateway 1070 may include an in-gateway transparent proxy mode, an in-gateway forward proxy mode, and an in-gateway DNS redirection (reverse proxy).
  • In-gateway DNS redirection with reverse proxy mode sticky HTTP redirection + reverse proxy (Sticky HTTP redirection plus reverse proxy) mode, Manipulation of URLs in manifest plus reverse proxy mode.
  • the multicast gateway 1070 may be configured as a home gateway or an IP set-top box (STB) according to proxy mode, and located in a network gateway, premises of the content playback unit 1080 (that is, a client). It is possible to connect with.
  • STB IP set-top box
  • FIG. 28 is a simplified illustration of the corresponding portion of the system architecture of FIG. 23 when the multicast gateway 1070 according to the present invention operates as a proxy server.
  • the user network may include a multicast gateway 1070 and a content player 1080 (ie, a client).
  • the multicast gateway 1070 operates as a proxy server, and the proxy mode is an in-gateway transparent proxy mode or an in-gateway forward proxy mode, the multicast gateway 1070 may include a home gateway and a multicast receiver. Can be.
  • the proxy mode is In-gateway DNS redirection with reverse proxy mode, the multicast gateway 1070 includes a multicast receiver that directly exchanges data with the multicast server 1050, and the multicast receiver is a local DNS. And a media caching unit.
  • the multicast receiver may receive multicast content through a device serving as a gateway or proxy included in the user network.
  • the gateway or proxy may be considered as a component of the ABR multicast network.
  • the multicast receiver may serve as a server or a multicast sender in a 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.
  • the client 1080 may include the IP information of the target server (ie, the multicast server 1050) or the content hosting unit 1040.
  • the access information of the multicast server 1050 is known in advance. That is, since the connection is based on the IP information of the multicast server 1050 or the content hosting unit 1040, DNS setting and a host name are not necessary.
  • the network controller 1063 may transfer the server IP information to the multicast gateway 1070 in advance through the interface C MR . Multicast availability is also delivered in a unicast response.
  • the in-gate transparent proxy mode is end to end connected to the content hosting unit 1040 or the multicast server 1050 as an HTTP kernel, and is typically in the form of a transparent mode server in a set-top box (STB) or TV.
  • STB set-top box
  • the terminal and the content hosting unit 1040 (that is, the origin server) in a bypass form do not recognize whether there is an intermediate caching.
  • 2.Client (1080) makes a GET request for manifest or media.
  • Multicast gateway (1070) lazily initiates a multicast session to start storing a local cache.
  • the multicast gateway 1070 of FIG. 23 performs a forward operation.
  • the in-gateway forward proxy mode knows and accesses all the access IP information of the multicast server 1050 or the content hosting unit 1040, which is the final target server, and thus does not require DNS setting.
  • the in-gateway transparent proxy mode but knows the identity of the server to connect to the data request, the in-gateway forward proxy mode, as shown in Figure 30 to the server, that is, the multicast gateway 1070 Mediate.
  • the client setting is proxy.com, but target.com in the address bar. That is, all requests are forwarded to the final destination via a proxy, i.e., multicast gateway 1070.
  • the client 1080 and the multicast gateway 1070 do not operate HTTP communication. .
  • the multicast availability is delivered in a unicast response as in the in-gate transparent proxy mode.
  • 1.Client (1080) is explicitly configured to use multicast gateway (1070) as a proxy for all (or some) of its HTTP (S) interactions.
  • TheClient (1080) requests the manifest via multicast gateway (1070).
  • Client (1080) requests media via multicast gateway (1070).
  • Multicast gateway (1070) lazily initiates a multicast session to start storing a local cache.
  • the client (1080) would use CONNECT to create a secure tunnel to the unicast source, and multicast gateway (1070) would be unable to see and intercept these requests / responses.
  • the reverse proxy relays requests to physically and logically divided servers for the purpose of load balancing or service.
  • it has only reverse proxy information. That is, as shown in FIG. 31, the client 1080 recognizes the proxy as a general server. Therefore, since the client 1080 sees the proxy IP, the client 1080 needs to go through the proxy 1070 and set the DNS as the proxy IP. For example, when a request is made to a target server, all accesses of the target server are requested to the target server at an address mapped to the reverse proxy and data is received. When you access a specific site with Youtube, you can filter it so that it cannot be delivered through a proxy.
  • the In gateway DNS redirection with proxy mode assigns a request to the origin target server of the client 1080, that is, the content hosting unit 1040, to an IP / host name through DNS redirection / interception of the multicast gateway 1070 to connect.
  • reverse proxy In the context of the content hosting unit 1040, that is, Origin, it transmits a request and a data response through the host name of the reverse proxy. Therefore, DNS is not required in the in-gateway forward proxy mode, whereas a DNS server is required in the in gateway DNS redirection with proxy mode.
  • DHCP lease issued to client device by home gateway device specifies that all clients should use the local DNS service to resolve host names.
  • 4.Client (1080) looks inside the manifest and attempts to resolve unicast host name.
  • 6.Client (1080) makes a request for media to the IP address of multicast gateway (1070), believing it to be the unicast source.
  • Multicast gateway (1070) can then respond with media received via multicast.
  • Sticky HTTP redirection plus reverse proxy mode is to add the HTTP 302 redirection mode.
  • HTTP responds with HTTP Response Status Code in response to the web server.
  • the 302 code in the HTTP Response Status Code is a code for moving a user to a new URL.
  • the meaning of 302 redirect indicates that the requested resource has been temporarily moved to a new URL. This is how to make the new URL accessible while maintaining the existing URL.
  • the client 1080 receives the MPD through the bootstrapping process through the content hosting unit 1040 (that is, the origin server) and the interface B as shown in FIG. 32.
  • the content hosting unit 1040 may redirection to the IP or hostname of the multicast gateway 1070 through the HTTP 302, so that the multicast gateway 1070 may download data as the origin.
  • Content hosting unit (1040) issues a HTTP 302 redirect pointing the client (1080) at the hostname or IP address of multicast gateway (1070).
  • 3.Client (1080) requests media from multicast gateway (1070), believing it to be the origin.
  • the manipulation of URLs in manifest plus reverse proxy mode delivers the host name / IP of the multicast gateway 1070 to act as a server such as the origin of the multicast gateway 1070 as the reverse proxy described above (FIG. 33). Reference).
  • URLs are selected in the manifest and hostname can be selected to select a server according to the multicast situation.
  • the content hosting unit 1040 that is, the origin server
  • 2.Content hosting unit (1040) serves a personalized manifest containing hostname the resolves to multicast gateway (1070), or the IP address of multicast gateway (1070).
  • 3.Client (1080) requests media from multicast gateway (1070), believing it to be the origin.
  • MPEG-DASH defines a timeline as a start time and duration of a segment through chunk / file delivery in segment mode.
  • the element defining the segment timeline in the MPD can calculate the transmission and reception synchronization information of segment availability timing and segment presentation timing based on the timescale provided during encoding. have.
  • FIG. 34 shows an example of semantics of a segmenttimeline element for creating a segment timeline of the segment availability timing and segment presentation timing in MPEG DASH. That is, FIG. 34 shows MPEG DASH MPD semantics of the segmenttimeline element.
  • the @t elements which are sub-elements of the segmenttimeline element of FIG. 34, represent the earliest presentation time of the segment, and the @d element represents the segment duration.
  • Information corresponding to the @t element and the @d element of FIG. 34 may be defined even within a segment.
  • the 'sidx' box including segment index information in the index segment may be defined.
  • the first offset information and the earliest presentation time of the media sample of the segment may be defined as 32 bits or 64 bits.
  • the value of baseMediaDecodeTime in 'tfdt' of the moof box may replace the earliest presentation time.
  • the segment timeline thus created can define the segment presentation time by considering the overall MPD properties and applying Equation 1 below.
  • the MPD @ availabilityStartTime element, the Period @ start element, and the MPD @ suggestedPresentationDelay element are elements included in the MPD as shown in FIG. 36.
  • the MPD @ availabilityStartTime element represents a point in time when the DASH client accesses the DASH server to secure the MPD
  • the period @ start element is a point in time at which a period divided into one or more time slots starts from a service point of view within the MPD.
  • the SegmentBase @ presentationTimeoffset element and timescale calculate a relative time between the start time of a period and the timeline at which the actual media A / V (Audio / Video) pops.
  • the MPD @ SuggestedPresentationDelay element is a value determined in consideration of device-to-device synchronization, jitter, and transmission delay (transmission delay or xmit delay) of DASH clients.
  • FIG. 37 is a diagram illustrating an embodiment of an MPEG DASH synchronization timeline.
  • FIG. 37A is an encoder timeline for encoding a media segment
  • FIG. 37B is an availability timeline reflecting the segment duration (that is, a timeline in which a segment is prepared in a DASH server).
  • (c) is a timeline of transmission frames transmitted from the DASH server.
  • FIG. 37D is a timeline of received frames received by the DASH client
  • FIG. 37E is a segment presentation timeline calculated by considering all delay factors. That is, FIG. 37E illustrates an example of a segment presentation timeline calculated by applying Equation 1 above.
  • the timeline is configured from the viewpoint that the time when the segment is available in the DASH server can be transmitted when data is accumulated during the segment duration and a complete file is formed as shown in the availability timeline of FIG. 37 (b).
  • the timeline may be disadvantages in terms of latency in which file chunks are available and transmitted.
  • the present invention proposes an embodiment which can be transmitted in advance even if a segment is not completely available at the time of linear service transmission.
  • the segment availability start time is reduced by the value of the SegmentBase @ availabilityTimeOffset element in the MPD so that the segment can be requested in advance even if the segment is not completely available.
  • this value is obtained by subtracting the availabilityTimeOffset value from the segment availability start time, and the segment can be requested in advance by this value.
  • the information is defined in the SegmentBase @ availabilityTimeOffset element or the BaseURL @ availabilityTimeOffset element as shown in FIG. 38. Details of the availabilityTimeOffset information will be described with reference to FIG. 38.
  • Equation 2 Equation 2.
  • a delay occurs while the media content encoded by the content encoding unit 1031 passes through the content hosting unit 1040 and / or the multicast server 1050.
  • the multicast gateway 1070 operates as a proxy server, a delay (that is, latency) from connection to generation of data flow may occur depending on the proxy mode.
  • the present invention proposes an embodiment for compensating for such delay in MPEG DASH technology.
  • the output of the content encoding unit 1031 is encapsulated in a delivery format by the multicast server 1050, and then transmitted to a specific protocol stack (eg, a ROUTE protocol).
  • a specific protocol stack eg, a ROUTE protocol
  • the segment presentation time is defined by reflecting the transmission delay using the MPD @ SuggestedPresentationDelay element.
  • the MPD previously defined
  • the value of the @SuggestedPresentationDelay element is meaningless or difficult to apply in practice.
  • the segment availability start time may be different because the segment modes for each channel are different. In other words, timing information of an encoded manifest and timing information obtained through data transmission interface called multicast ABR may be different.
  • the network controller 1063 may generate timing compensation information capable of reconfiguring DASH timing information, signal the control message, and transmit the signal to a multicast gateway 1070 and / or a multicast server 1050. It is set as an Example. In this embodiment, the network controller 1063 generates the timing compensation information based on the timing information provided from the content provider controller 1020. In the present invention, the timing compensation information is also referred to as timing update information or synchronization information for convenience of description.
  • timing information provided from the content provider controller 1020 is directly provided to the network controller 1063 without passing through other blocks, no delay occurs. However, when the timing information provided from the content provider controller 1020 passes through the content preparation unit 1030, the multiplexer server 1050, a delay occurs, and a difference occurs between the two timing information.
  • the content provider controller 1020 may provide information on a segment currently being played based on a representative reference play time of a linear service currently provided by RF or a reference time line according to a network condition.
  • the timing information is transmitted to the network controller 1063.
  • the network controller 1063 is a proxy when a network condition and the multicast gateway 1070 operate as a proxy server based on segment information and timing information provided by the content provider controller 1020.
  • the timing compensation information is generated in consideration of the server mode.
  • the timing compensation information includes an @availabilityStartTime element, an @suggestedPresentationDelay element, and an @availabilityTimeOffset element. Details of the elements will be described with reference to FIGS. 40 and 41.
  • the timing compensation information is transmitted to the multicast server 1050 using the interface C MS or to the multicast gateway 1070 using the interface C MR .
  • the multicast server 1050 may reconfigure the synchronization information based on the timing compensation information when switching through delivery reformat from the viewpoint of backward compatibility or when timing change occurs during re-encoding.
  • the network controller 1063 generates timing compensation information based on the timing information provided from the content provider controller 1020 and then includes it in a control message, and then multicast server 1050 through the interface Cms and / or Cmr. And / or to the multicast gateway 1070.
  • the SuggestedPresentationDelay value is determined in consideration of the segment duration, jitter, transmission delay (also referred to as transmission delay, xmit delay), physical stack delay, etc. as shown in FIG. .
  • the multicast gateway 1070 or the client 1080 adjusts the segment presentation time using the SuggestedPresentationDelay value.
  • the multicast gateway 1070 or the client 1080 controls the corresponding element values in the MPD received from the multicast server 1050. Update the corresponding element values included in the message, and adjust the segment availability start time and the segment presentation time using the updated element values.
  • the multicast server 1050 uses the timing compensation information in the control message transmitted to the interface C MS and / or C MR to determine the MPD provided by the content preparation unit 1030 and / or the content hosting unit 1040. You can also modify the value to enable re-encoding.
  • the information of the k-th segment is transmitted through the control interface (SP-MC-X or client), By applying earliest presentation time, it is possible to realize maximum synchronization between devices.
  • a timeline can be created by adding or subtracting the availabilityTimeOffset value from the segment availability start time. If the delivery format of the multicast server 1050 is re-encoded to reduce the movie fragment size, and thus, the moof interval in the segment is narrowed, the segment availability start time must be reconfigured through the availabilityTimeOffset value. Therefore, if there is a change in delivery format in order to reduce the request of the content provider (or service provider) or the latency of the linear service, the segment availability start time may be reconfigured using the timing compensation information provided by the network controller 1063. have.
  • FIG. 39A is an encoder timeline for encoding a media segment
  • FIG. 39B is a reception timeline reflecting a segment duration
  • FIG. 39C illustrates a reception timeline reflecting both a segment duration and a availability time offset. That is, in FIG. 39 (c), the reception time (ATO) requests the segment by reducing the sliced chunk mode of the segment or the SegmentBase @ availabilityTimeOffset value reflecting the network status of the MABR at the time of the segment availability start time. can do.
  • FIG. 39D illustrates a segment presentation timeline defined using information in the MPD provided by the multicast server 1050, and FIG.
  • segment presentation timeline that is, the presentation timeline-1 of FIG. 39E is a segment presentation timeline defined using the updated MPD @ suggestedPresentationDelay value based on the timing compensation information provided from the network controller 1063.
  • Presentation timeline-2 of FIG. 39 (f) attempts to buffer segment (k) without buffering playback of segment 1 on the basis of the linear service AV start up as the current criterion.
  • Information to be applied at this time is information corresponding to segment (k) and new MPD @ availabilityStartTime, Period @ starttime, MPD @ suggestedPresentationDelay, SegmentBase @ availabilityTimeOffset received through network controller 1063, and the like. Segment presentation timeline.
  • FIG. 40 and 41 illustrate another embodiment of a control message generated by the network controller 1063 according to the present invention.
  • FIG. 40 and FIG. 41 are semantics of adding the timing compensation information described above to the control message of FIG. 26.
  • the control message of FIGS. 40 and 41 may be in XML (eXtensible Markup Language) format or HTTP restful API message format.
  • the timing compensation information includes an @id element, an @availabilityStartTime element, an @suggestedPresentationDelay element, and an @availabilityTimeOffset element.
  • the @id element indicates an identifier for media presentation.
  • the @availabilityStartTime element indicates an anchor for calculating the earliest availability time (in UTC) of any segment included in the media presentation when the @type field is 'dynamic'. If the @type field is 'static', it indicates sgement availability start time for all segments referenced in the MPD.
  • the @suggestedPresentationDelay element indicates a fixed delay offset from the presentation time of each access unit to be used for the presentation of each access unit when the @type field is 'dynamic'. If the @type field is 'static', the value of this attribute is ignored.
  • the @availabilityTimeOffset element indicates an offset for defining the adjusted segment availability time.
  • the control message may further include a segmenttemplate element indicating segment template information, and include @media element and @skip_number element as lower elements of the segmenttemplate element.
  • the @media element indicates a template for generating a media segment list.
  • the @skip_number element indicates the number of media segments to skip for synchronization.
  • the receiver 42 illustrates a receiver structure according to an embodiment of the present invention.
  • the receiver may be the content playback unit 1080 or may be part of the content playback unit 1080.
  • the receiver of FIG. 42 may receive a signal including a multicast service and / or a unicast service using a tuner.
  • the receiver may receive a signal including a multicast service and / or a unicast service from the multicast gateway 1070.
  • the multicast service and / or the unicast service are broadcast services.
  • the receiver may also previously receive an MPD from a tuner and / or the multicast gateway 1070.
  • the MPD is updated by the multicast gateway 1070 based on the information included in the control messages shown in FIGS. 41 and 42 output from the network controller 1063 and transmitted to the receiver. .
  • the receiver converts the received analog signal into a digital signal using an analog digital converter (ADC), and demodulates the digitized signal using a demodulator.
  • Receiver is channel sync.
  • the & EQ may be used to perform synchronization and equalization on the demodulated signal, and the channel decoder may be used to perform channel decoding on the received signal.
  • the L1 signaling parser may obtain L1 signaling information from the decoded signal.
  • the L1 signaling information may be delivered to the baseband controller of the receiver and used to acquire physical layer data.
  • the L1 signaling information may be input to the signaling controller of the receiver.
  • the L2 signaling parser may obtain L2 signaling information from the decoded signal.
  • the L2 signaling information may include service layer signaling information for service acquisition, and the service layer signaling information may further include user service bundle description (USBD) information and service-based transport session instance description (S ⁇ ).
  • TSID user service bundle description
  • API Associated Procedure Description
  • MPD DASH Media Presentation Description
  • HELD HTML Entry pages Location Description
  • DWD Distribution Window Description
  • the obtained L2 signaling information may be input to a signaling controller.
  • the signaling controller may communicate with a service layer signaling channel (or service signaling channel (ssc)) processing buffer and parser, thereby updating the service MAP DB (data base).
  • 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. The received IP packet is input to the A / V service controller via the common protocol stack.
  • the demultiplexer of the receiver can demultiplex audio and video data.
  • the receiver may output audio data using an audio decoder and an audio renderer, and output video data using a video decoder and a video renderer.
  • the load on the network can be reduced by switching the existing unicast transmission to multicast.
  • Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.
  • the image processing method of the present invention can be implemented as a processor-readable code on a processor-readable recording medium provided in the network device.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. .
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention has industrial applicability that is usable and repeatable in the field of broadcast and video signal processing.

Landscapes

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

Abstract

The present invention relates to an apparatus and a method for transmitting and receiving a media service. In particular, a method for receiving a media service may comprise the steps of: receiving and storing media presentation description information including segment Uniform Resource Locator (URL) information for media segments and timing information for presentation of the media segments, receiving and storing media segments transmitted via at least one of multicast and unicast, and outputting a media segment requested for content playback among the stored media segments; receiving a control message including at least one URL base pattern information for identifying at least one media segment transmitted through multicast and at least one URL base pattern information for identifying at least one media segment transmitted through unicast; and updating the segment URL information in the stored media presentation description information on the basis of each URL base pattern information included in the received control message.

Description

방송 신호 송수신 방법 및 장치Broadcast signal transmission and reception method and apparatus
본 발명은 방송 신호를 송수신하는 장치 및 방법에 관한 것이다.The present invention relates to an apparatus and method for transmitting and receiving broadcast signals.
디지털 기술 및 통신 기술의 발전으로 방송, 영화뿐만 아니라 인터넷 및 개인 미디어 등의 다양한 영역에서 오디오/비디오 중심의 멀티미디어 컨텐츠 보급 및 수요가 급속도로 확대되고 있다. 또한, 디스플레이 기술의 발전과 더불어 가정에서의 TV 화면이 대형화 됨에 따라 UHD (Ultra High Definition) 방송 서비스에 대한 논의가 증가되고 있는 추세이다.With the development of digital technology and communication technology, the distribution and demand of audio / video-oriented multimedia contents are rapidly expanding in various areas such as broadcasting, movies, internet and personal media. In addition, with the development of display technology, as the size of TV screens at home increases, discussions about ultra high definition (UHD) broadcasting services are increasing.
방송 서비스와 관련하여, 복수의 사용자에게 동일한 컨텐츠를 전송하는 멀티캐스트 (multicast) 전송 방식은 유니캐스트 (unicast)와 브로드캐스트 (broadcast)의 장점을 모두 활용할 수 있으므로 효과적이다. 하지만, 기존의 멀티캐스트 전송 방식은 단일 네트워크 내에서만 가능했으며 이종망 간의 멀티캐스트 서비스가 불가능한 단점이 있었다. 또한 실시간 IP 멀티캐스트 방송환경에서 파일 기반 멀티캐스트 컨텐츠를 전송하는 경우, 수신기의 초기화 및 AV (audio/video) startup 동작에 긴 시간이 소요되는 단점이 있었다.In relation to a broadcast service, 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). However, the conventional multicast transmission method was possible only within a single network, and multicast service between heterogeneous networks was impossible. In addition, when transmitting file-based multicast content in a real-time IP multicast broadcasting environment, a long time is required for the initialization and AV (audio / video) startup operation of the receiver.
본 발명의 목적은, 방송 신호를 전송하는 방법 및 장치에 있어서 전송 효율을 높이는 것이다. 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.
본 발명의 다른 목적은, 멀티캐스트 서비스에 대한 수신기에서의 재생을 신속하게 시작하기 위한 장치 및 방법을 제공하는 것이다. It is another object of the present invention to provide an apparatus and method for quickly starting playback at a receiver for a multicast service.
본 발명의 또 다른 목적은 기존의 매니페스트의 구조는 변경하지 않고, baseURL을 통한 딜리버리 방법을 정의하여 기존 ABR 서비스에 호환 가능한 장치 및 방법을 제공하는 것이다. Another object of the present invention is to provide a device and method compatible with the existing ABR service by defining a delivery method through baseURL without changing the structure of the existing manifest.
본 발명의 일 실시예에 따른 미디어 서비스 수신 방법은 미디어 세그먼트들에 대한 세그먼트 URL (Uniform Resource Locator) 정보와 상기 미디어 세그먼트들의 프리젠테이션을 위한 타이밍 정보를 포함하는 미디어 프리젠테이션 디스크립션 정보를 수신하여 저장하고, 멀티캐스트와 유니캐스트 중 적어도 하나를 통해 전송되는 미디어 세그먼트들을 수신하여 저장하며, 상기 저장된 미디어 세그먼트들 중 컨텐트 재생을 위해 요청되는 미디어 세그먼트를 출력하는 단계; 상기 멀티캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보와 상기 유니캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보를 포함하는 콘트롤 메시지를 수신하는 단계; 및 상기 수신된 콘트롤 메시지에 포함된 각 URL 베이스패턴 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 세그먼트 URL 정보를 업데이트하는 단계를 포함한다.The media service receiving method according to an embodiment of the present invention receives and stores media presentation description information including segment Uniform Resource Locator (URL) information for media segments and timing information for presentation of the media segments. Receiving and storing media segments transmitted through at least one of multicast and unicast, and outputting a media segment requested for content playback among the stored media segments; A control message including at least one URL base pattern information for identifying at least one media segment transmitted in the multicast and at least one URL base pattern information for identifying at least one media segment transmitted in the unicast. Receiving; And updating segment URL information in the stored media presentation description information based on each URL base pattern information included in the received control message.
상기 콘트롤 메시지는 상기 멀티캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 포함하는 리프리젠테이션의 우선 순위 정보와 상기 유니캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 포함하는 리프리젠테이션의 우선 순위 정보를 더 포함하는 것을 일 실시예로 한다.The control message further includes priority information of a representation including at least one media segment transmitted in the multicast and priority information of a representation including at least one media segment transmitted in the unicast. In one embodiment.
상기 콘트롤 메시지는 상기 멀티캐스트를 통해 적어도 하나의 미디어 세그먼트를 전송하는 전송 세션의 IP (Internet Protocol) 어드레스 정보와 포트 정보를 더 포함하는 것을 일 실시예로 한다.The control message may further include IP (Internet Protocol) address information and port information of a transport session for transmitting at least one media segment through the multicast.
상기 콘트롤 메시지는 서비스 식별 정보를 더 포함하는 것을 일 실시예로 한다.According to an embodiment of the present invention, the control message further includes service identification information.
상기 콘트롤 메시지는 타이밍 보상 정보를 더 포함하며, 상기 타이밍 보상 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 타이밍 정보를 업데이트하여 세그먼트 프리젠테이션 타임을 조정하는 단계를 더 포함하는 것을 일 실시예로 한다.The control message may further include timing compensation information. The control message may further include adjusting timing of a segment presentation by updating timing information in the stored media presentation description information based on the timing compensation information. .
본 발명의 일 실시예에 따른 미디어 서비스 장치는, 미디어 세그먼트들에 대한 세그먼트 URL (Uniform Resource Locator) 정보와 상기 미디어 세그먼트들의 프리젠테이션을 위한 타이밍 정보를 포함하는 미디어 프리젠테이션 디스크립션 정보를 전송하고, 멀티캐스트와 유니캐스트 중 적어도 하나를 통해 전송되는 미디어 세그먼트들을 전송하는 전송 서버; 상기 미디어 프리젠테이션 디스크립션 정보를 수신하여 저장하고, 상기 미디어 세그먼트들을 수신하여 저장하며, 상기 저장된 미디어 세그먼트들 중 컨텐트 재생을 위해 요청되는 미디어 세그먼트를 출력하는 멀티캐스트 게이트웨이; 및 상기 멀티캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보와 상기 유니캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보를 포함하는 콘트롤 메시지를 생성하여 전송하는 네트워크 콘트롤러를 포함하며, 상기 멀티캐스트 게이트웨이는 상기 콘트롤 메시지를 수신하고, 상기 콘트롤 메시지에 포함된 각 URL 베이스패턴 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 세그먼트 URL 정보를 업데이트한다.The media service apparatus according to an embodiment of the present invention transmits media presentation description information including segment Uniform Resource Locator (URL) information on media segments and timing information for presentation of the media segments, A transmission server for transmitting media segments transmitted over at least one of cast and unicast; A multicast gateway that receives and stores the media presentation description information, receives and stores the media segments, and outputs a media segment requested for content playback among the stored media segments; And at least one URL basepattern information for identifying at least one media segment transmitted in the multicast and at least one URL basepattern information for identifying at least one media segment transmitted in unicast. And a network controller for generating and transmitting a message, wherein the multicast gateway receives the control message and transmits segment URL information in the stored media presentation description information based on each URL base pattern information included in the control message. Update.
상기 콘트롤 메시지는 타이밍 보상 정보를 더 포함하며, 상기 멀티캐스트 게이트웨이는 상기 타이밍 보상 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 타이밍 정보를 업데이트하여 세그먼트 프리젠테이션 타임을 조정하는 것을 일 실시예로 한다.The control message further includes timing compensation information, and the multicast gateway adjusts segment presentation time by updating timing information in the stored media presentation description information based on the timing compensation information. .
상기 멀티캐스트 게이트웨이는 홈 게이트웨이와 커넥티드 셋톱박스 중 적어도 하나에 위치되는 것을 일 실시예로 한다.In an embodiment, the multicast gateway is located in at least one of a home gateway and a connected set-top box.
상기 멀티캐스트 게이트웨이가 프록시 서버로 동작하면, 상기 프록시 서버는 인-게이트웨이 트랜스페어런트 프록시(transparent proxy) 모드로 동작하는 것을 일 실시예로 한다.When the multicast gateway operates as a proxy server, the proxy server may operate in an in-gateway transparent proxy mode.
본 발명의 실시예에 따르면, 방송 시스템의 전송 효율을 높일 수 있다. According to an embodiment of the present invention, it is possible to increase transmission efficiency of a broadcast system.
본 발명의 실시예에 따르면, 이종망 간에 멀티캐스트 서비스를 제공할 수 있다. According to an embodiment of the present invention, it is possible to provide a multicast service between heterogeneous networks.
본 발명의 실시예에 따르면, 멀티캐스트 서비스에 대한 수신기에서의 재생을 신속하게 시작할 수 있다. According to an embodiment of the present invention, playback at the receiver for the multicast service can be started quickly.
본 발명의 실시예에 따르면, 세그먼트 내 baseurl를 이용하여 각 딜리버리 경로를 구분할 수 있도록 함으로써, 유니캐스트와 멀티캐스트 네트워크를 동시에 사용할 수 있고 이로 인해, 딜리버리 경로의 전환 시간이 짧아지고, 데이터 대역폭을 늘리는 효과가 있다. 특히, 재생을 위해 선택된 데이터의 URL이 멀티캐스트를 위한 세그먼트의 URL인지 특정 서버의 유니캐스트를 위한 URL인지를 식별할 수 있게 된다. According to an embodiment of the present invention, each delivery path can be distinguished using a baseurl in a segment, so that unicast and multicast networks can be used simultaneously, thereby shortening the switching time of the delivery path and increasing data bandwidth. It works. In particular, it is possible to identify whether the URL of the data selected for reproduction is the URL of the segment for multicast or the URL for unicast of a specific server.
본 발명의 실시예에 따르면, 멀티캐스트 서버로부터 제공되는 매니페스트 내 타이밍 정보를 보상하도록 함으로써, 세그먼트의 시작 및 presentation을 정확하게 동기화시킬 수 있는 효과가 있다.According to an embodiment of the present invention, by compensating timing information in a manifest provided from a multicast server, there is an effect of accurately synchronizing the start and presentation of a segment.
도 1은 본 발명의 일 실시예에 따른 네트워크 구조를 나타낸 도면이다. 1 is a diagram illustrating a network structure according to an embodiment of the present invention.
도 2는 본 발명의 일 실시예에 따른 컨텐트 네트워크를 나타낸 도면이다. 2 illustrates a content network according to an embodiment of the present invention.
도 3은 본 발명의 일 실시예에 따른 컨텐트 네트워크가 위성 릴레이 (satellite relay)를 포함하는 경우를 나타낸 도면이다.3 is a diagram illustrating a case in which a content network includes a satellite relay according to an embodiment of the present invention.
도 4는 본 발명의 일 실시예에 따른 컨텐트 네트워크가 컨텐트 딜리버리 네트워크 (CDN)를 포함하는 경우를 나타낸 도면이다.4 is a diagram illustrating a case in which a content network includes a content delivery network (CDN) according to an embodiment of the present invention.
도 5는 본 발명의 일 실시예에 따른 유선 (wired) 멀티캐스트 네트워크를 나타낸 도면이다. 5 illustrates a wired multicast network according to an embodiment of the present invention.
도 6은 본 발명의 일 실시예에 따른 모바일 멀티캐스트 네트워크를 나타낸 도면이다.6 illustrates a mobile multicast network according to an embodiment of the present invention.
도 7은 본 발명의 일 실시예에 따른 유저 네트워크를 나타낸 도면이다. 7 illustrates a user network according to an embodiment of the present invention.
도 8은 본 발명의 일 실시예에 따른 ABR 멀티캐스트를 위한 네트워크 구조를 나타낸 도면이다. 8 is a diagram illustrating a network structure for ABR multicast according to an embodiment of the present invention.
도 9는 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 9 is a diagram illustrating a protocol for adaptive multicast streaming according to an embodiment of the present invention.
도 10은 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 10 illustrates a protocol for adaptive multicast streaming according to an embodiment of the present invention.
도 11은 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다.11 illustrates a protocol for signaling and control messages according to an embodiment of the present invention.
도 12는 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다. 12 illustrates a protocol for signaling and control messages according to an embodiment of the present invention.
도 13은 본 발명의 일 실시예에 따른 IP network를 통해 미디어 데이터를 전송하기 위한 프로토콜을 나타낸 도면이다. 13 illustrates a protocol for transmitting media data through an IP network according to an embodiment of the present invention.
도 14는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.14 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
도 15는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. 15 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
도 16은 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다.16 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention.
도 17은 본 발명의 일 실시예에 따른 DASH 전송 방식을 나타낸다. 17 shows a DASH transmission scheme according to an embodiment of the present invention.
도 18은 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조를 나타낸 도면이다. 18 illustrates a structure of a DASH segment according to an embodiment of the present invention.
도 19는 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조와 생성 및 파싱 순서를 나타낸 도면이다. 19 illustrates a structure, a generation, and a parsing sequence of a DASH segment according to an embodiment of the present invention.
도 20은 본 발명의 일 실시예에 따른 유저 네트워크 및 MPD를 나타낸 도면이다. 20 illustrates a user network and an MPD according to an embodiment of the present invention.
도 21은 본 발명의 일 실시예에 따른 MPD의 세부 내용을 나타낸 도면이다. 21 is a diagram illustrating details of an MPD according to an embodiment of the present invention.
도 22는 본 발명의 일 실시예에 따른 패스트 스타트업을 위한 MPD를 나타낸 도면이다. 22 illustrates an MPD for fast startup according to an embodiment of the present invention.
도 23은 본 발명의 일 실시예에 따른 ABR 멀티캐스트 서비스를 위한 시스템 아키텍쳐를 보인 도면이다. 23 is a diagram illustrating a system architecture for an ABR multicast service according to an embodiment of the present invention.
도 24는 본 발명에 따른 멀티캐스트 ABR delivery method에 따라 baseurl을 정의한 일 실시예를 보인 도면이다.24 illustrates an embodiment of defining a baseurl according to the multicast ABR delivery method according to the present invention.
도 25는 본 발명에 따른 MPD에 포함되는 baseurl의 실시예들을 보인 도면이다.25 is a view showing embodiments of a baseurl included in the MPD according to the present invention.
도 26은 본 발명에 따른 콘트롤 메시지의 시맨틱스의 일 실시예를 보인 도면이다.26 illustrates an embodiment of semantics of a control message according to the present invention.
도 27은 본 발명에 따른 콘트롤 메시지의 시맨틱스의 다른 실시예를 보인 도면이다.27 shows another embodiment of semantics of a control message according to the present invention.
도 28은 본 발명에 따른 멀티캐스트 게이트웨이가 프록시 서버로 동작할 때, 도 23의 시스템 아키텍쳐의 해당 부분을 간략히 도시한 도면이다. FIG. 28 is a diagram schematically illustrating a corresponding part of the system architecture of FIG. 23 when the multicast gateway according to the present invention operates as a proxy server.
도 29 내지 도 33은 본 발명에 따른 프록시 모드들에 따른 동작 방법들의 실시예들을 보인 도면이다.29 to 33 are diagrams showing embodiments of operating methods according to proxy modes according to the present invention.
도 34는 본 발명에 따른 MPD에 포함되는 세그먼트 타임라인 엘레먼트의 시맨틱스의 일 예를 보인 도면이다.34 illustrates an example of semantics of a segment timeline element included in an MPD according to the present invention.
도 35는 본 발명에 따른 인덱스 세그먼트 내 'sidx'박스에 정의되는 타임 정보의 일 예를 보인 도면이다.35 is a diagram illustrating an example of time information defined in a 'sidx' box in an index segment according to the present invention.
도 36은 본 발명에 따른 MPD에 포함되는 타임 정보 엘레먼트들의 예를 보인 도면이다.36 illustrates an example of time information elements included in an MPD according to the present invention.
도 37의 (a) 내지 (e)는 본 발명에 따른 세그먼트 프리젠테이션 타임라인의 예를 보인 도면이다.37 (a) to (e) are diagrams showing an example of a segment presentation timeline according to the present invention.
도 38은 본 발명에 따른 MPD에 포함되는 availability Time Offset 정보의 일 예를 보인 도면이다.38 illustrates an example of availability time offset information included in an MPD according to the present invention.
도 39의 (a) 내지 (f)는 본 발명에 따른 타이밍 보상 정보를 기반으로 조정된 세그먼트 프리젠테이션 타임라인의 예를 보인 도면이다.39 (a) to (f) illustrate an example of a segment presentation timeline adjusted based on timing compensation information according to the present invention.
도 40과 도 41은 본 발명에 따른 콘트롤 메시지의 시맨틱스의 또 다른 실시예를 보인 도면이다. 40 and 41 illustrate another embodiment of semantics of a control message according to the present invention.
도 42는 본 발명의 일 실시예에 따른 수신기 구조를 나타낸 도면이다.42 illustrates a receiver structure according to an embodiment of the present invention.
도 1은 본 발명의 일 실시예에 따른 네트워크 구조를 나타낸 도면이다. 도 1에 도시된 바와 같이, 어댑티브 미디어 스트리밍 (Adaptive Media Streaming)을 위한 네트워크는 컨텐트 네트워크 (Content Network), 어댑티브 비트 레이트 (Adaptive Bit Rate, ABR) 멀티캐스트 네트워크 (ABR Multicast Network) 및 유저 네트워크 (User Network)를 포함할 수 있다. 이는 인터넷 프로토콜 (Internet Protocol, IP) 기반의 멀티캐스트 네트워크 (Multicast Network)에서, 어댑티브 미디어 스트리밍을 지원하기 위해 사용되는 네트워크들을 기능별로 구분한 것이다. 또한 각각의 네트워크는 어댑티브 미디어 스트리밍 이외의 다른 기능을 지원하기 위한 부가적인 네트워크에 접속할 수 있다. 예를 들면 컨텐트 네트워크와 유저 네트워크는 유니캐스트 서비스를 위한 유니캐스트 네트워크에 각각 접속할 수 있다. 1 is a diagram illustrating a network structure according to an embodiment of the present invention. As shown in FIG. 1, a network for adaptive media streaming includes a content network, an adaptive bit rate (ABR) multicast network, and a user network (User). Network) may be included. This is a functional classification of the networks used to support adaptive media streaming in a multicast network based on the Internet Protocol (IP). Each network can also connect to additional networks to support other functions than adaptive media streaming. For example, the content network and the user network may each connect to a unicast network for unicast services.
유저 네트워크는 ABR 멀티캐스트 네트워크에게 수신하고자 하는 컨텐트에 대한 요청(request), 보고 (report), 피드백 (feedback)을 전송할 수 있다. ABR 멀티캐스트 네트워크는 유저 네트워크로부터 수신된 정보에 기초하여 컨텐트 네트워크에게 요청(request), 보고 (report), 피드백 (feedback)을 전송할 수 있다. 컨텐트 네트워크는 ABR 멀티캐스트 네트워크로부터 수신된 정보에 기초하여, 멀티 캐스 컨텐트 및 시그널링 정보를 ABR 멀티캐스트 네트워크에게 전송할 수 있다. ABR 멀티캐스트 네트워크는 수신된 멀티 캐스 컨텐트 및 시그널링 정보를 유저 네트워크에게 전송하여 멀티캐스트 서비스를 제공할 수 있다. 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 multi-cas 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.
도 2는 본 발명의 일 실시예에 따른 컨텐트 네트워크를 나타낸 도면이다. 컨텐트 네트워크 (Content Network)는 어댑티브 멀티캐스트 스트리밍 (adaptive multicast streaming)을 위한 컨텐트의 생성, 수집, 패키징 (packaging) 등의 기능을 담당할 수 있으며, 다양한 컨텐트 소스 (contents source)를 포함할 수 있다. 컨텐트 네트워크는 방송 컨텐트를 서비스 하기 위해, 지상파 (terrestrial) 및 케이블 (cable) 방송 등을 서비스 하는 방송국 (broadcaster)의 헤드 엔드 (head-end)를 포함할 수 있다. 방송국 헤드 엔드는 컨텐트 프로덕션에서 생성된 컨텐트를 인코딩하는 인코더, 인코딩된 컨텐트를 변환하는 packager, 컨텐트를 저장하는 컨텐트 서버 중 적어도 하나를 포함할 수 있다. 2 illustrates a content network according to an embodiment of the present invention. 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.
또한, 컨텐트 네트워크는 지리적으로 멀리 떨어진 지역으로부터 제작된 서비스를 수신하기 위한 위성 수신 네트워크를 더 포함할 수 있다. 또한 미리 저장된 컨텐트를 서비스 하기 위해 컨텐트 서버 (content server)를 포함 할 수 있다. 컨텐트 네트워크는 컨텐트 서버와 함께, 미디어 전송을 서비스하는 컨텐트 딜리버리 네트워크 (Contents Delivery Network, CDN)를 포함할 수 있다. 따라서 컨텐트 네트워크는 컨텐트와 관련된 시그널링 메시지 (signaling message), 컨트롤 메시지 (control message) 등을 생성 및 전송 할 수 있다. In addition, 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.
컨텐트, 시그널링 메시지, 컨트롤 메시지 등의 적절한 상호동작을 위해 컨텐트 네트워크에 속하는 여러 노드들 (nodes) 사이에는 별도의 시그널링 메시지 또는 컨트롤 메시지가 교환될 수 있으며, 이러한 메시지들은 다른 외부 네트워크로 전달되지 않을 수 있다. 이렇게 외부 네트워크로 전달되지 않는 시그널링 메시지 또는 컨트롤 메시지는 인터널 네트워크 시그널링 (internal network signaling)이라 명명할 수 있다.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.
위에서 설명한 바와 같이, 컨텐트 네트워크에는 브로드캐스터 헤드-엔드 (head-end) 를 포함할 수 있다. 브로드캐스터에서 생성된 컨텐트는 인코딩 및 패키징을 거쳐 멀티캐스트 센더 (multicast sender)로 전달되어 멀티캐스팅 되거나, 컨텐트 서버에 저장 되어 필요 시에 멀티캐스트 센더 (multicast sender)로 전달될 수 있다. 아래에서는 컨텐트 네트워크의 브로드캐스터 헤드-엔드에 포함된 각 구성요소에 대해 설명한다.As described above, the content network may include a broadcaster head-end. Content generated by the broadcaster may be delivered to a multicast sender through encoding and packaging, and may be multicasted, or may be stored in a content server and delivered to a multicast sender when necessary. The following describes each component included in the broadcaster head-end of the content network.
먼저, 브로드캐스터 헤드-엔드에 포함된 인코더 (Encoder)는 컨텐트에 대한 인코딩을 수행한다. 브로드캐스터 헤드-엔드에 포함된 패키저 (Packager)는 인코딩된 컨텐트 및 데이터를 멀티캐스트 전송에 적합한 포맷으로 변환할 수 있다. 멀티캐스트 전송에 적합한 포맷은 예를 들어, 하나의 컨텐트를 분할하여 생성된 미디어 세그먼트일 수 있다. 또한 패키저는 필요시 수신기 또는 네트워크에 소속된 장치에서 수신할 수 있는 시그널링을 생성할 수 있다. 패키저에서 생성한 미디어 세그먼트는 직접 멀티캐스트 센더로 전달되어 멀티캐스트될 수 있으나, 해당 미디어 세그먼트가 즉시 전달될 필요가 없는 데이터인 경우에는 컨텐트 서버에 저장될 수 있다. 브로드캐스터 헤드-엔드에 포함된 컨텐트 서버 (Content Server)는 미디어 데이터 및 이와 관련된 시그널링 등을 저장할 수 있다. 컨텐트 서버는 또한 써드 파티에서 생성된 컨텐트 (3rd party content)를 저장하고 필요 시 멀티캐스트에 활용할 수 있다. 여기서, 컨텐트 서버에 저장되어 있는 컨텐트의 경우 별도의 인코딩 과정이 필요 없을 수 있다. 따라서 컨텐트 서버는 컨텐트를 인코딩 또는 패키징한 미디어 세그먼트 및 파일을 저장하고, 전송 요청이 있는 경우 전송할 수 있다. 실시예에 따라서는 미디어 데이터에 대한 인코딩 결과가 컨텐트 서버에 저장될 수도 있으며, 전송 네트워크의 형태에 따라 별도의 패키징 과정이 필요할 수 있다. 브로드캐스터 헤드-엔드에 포함된 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 프로덕션 (Content production) 및 컨텐트 서버 (content server) 등을 관리하고, 멀티캐스팅과 관련한 일련의 과정을 관리 및 제어할 수 있다. 오퍼레이터 컨트롤러 (Operator Controller)는 컨텐트 네트워크 내의 복수의 디바이스들 및 노드들(nodes)에 대해 컨트롤 및 시그널링 데이터를 수집 하고, 필요한 경우 멀티캐스트 네트워크로 전달할 수 있다. 이를 통해 오퍼레이터 컨트롤러 (Operator Controller)는 멀티캐스트 네트워크가 멀티캐스트와 관련된 시그널링 및 컨트롤을 수행하는 것을 가능하게 할 수 있다. 또한 오퍼레이터 컨트롤러는 디코딩 디바이스나 플레이어(player)로부터 전달되는 유니캐스트 (unicast) 정보를 수신 및 처리하여 멀티캐스트에 이용할 수 있다.First, 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. In addition, 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. 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. According to an embodiment, 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. The operator controller included in the broadcaster head-end manages content production and content server, and manages and controls a series of processes related to multicasting. 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. In addition, the operator controller can receive and process unicast information transmitted from a decoding device or a player and use it for multicast.
도 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)가 포함된 컨텐트 네트워크의 오퍼레이터 컨트롤러에 대한 설명은 이전 도면에서 설명한 바와 같다.3 is a diagram illustrating a case in which a content network includes a satellite relay according to an embodiment of the present invention. 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. In this case, 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. Here, 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. The description of the packager of the content network including the satellite relay is as described in the previous drawings. A content server of a content network including a satellite relay may store media data and related signaling. In live broadcasts to geographically distant locations, 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. Detailed description thereof has been described with reference to the previous drawings. The description of the operator controller of the content network including the satellite relay is as described in the previous drawings.
도 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에 포함된 오퍼레이터 컨트롤러는 상호 커뮤니케이션이 가능하다. 4 is a diagram illustrating a case in which a content network includes a content delivery network (CDN) according to an embodiment of the present invention. Over the top (OTT) for serving video content using an IP network may be considered as one embodiment of a content network. In the case of OTT, CDN can be connected for efficient use of network resources. A content network, including a content delivery network (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. In addition, 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. According to an embodiment, 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. In OTT, 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. According to an embodiment, 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. In addition, 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.
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)와 동일하다. An ABR multicast network is a network that multicasts content delivered from a content network over an IP network. Here, 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. In addition, the IP network may be connected in a wired or wireless manner by devices included in a multicast network or a user network. In using an IP network for multicast, 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. In this case, separate IP networks may follow a connection protocol between an ISP (Internet Service Provider) providing each network. Even in this case, 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.
멀티캐스트 스트림의 송신 및 수신을 위한 멀티캐스트 네트워크는 multicast sender (server), multicast receiver (client), multicast network controller를 포함할 수 있다. 멀티캐스트 네트워크는 멀티캐스트를 위한 네트워크의 sender 및 receiver의 위치 또는 접속 상태에 따라, 복수의 네트워크를 포함할 수 있다. 또한 이에 대해 각 network에 따라 별도의 protocol을 사용할 수도 있다.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.
도 5는 본 발명의 일 실시예에 따른 유선 (wired) 멀티캐스트 네트워크를 나타낸 도면이다. 멀티캐스트 스트림은 유선 IP network를 통해 전달될 수 있다. Multicast sender와 Multicast receiver 사이에는 ISP (Internet Service Provider)에서 제공하는 network를 이용할 수 있다. 실시예에 따라 멀티캐스트 스트림은 복수의 ISP에서 관리하는 IP network를 통해 전달될 수 있으며, Multicast sender, receiver, controller 와 IP network의 관리 주체가 다를 수 있다. 이 경우 멀티캐스트 스트림의 전송은 각 ISP에 대응하는 접속 protocol을 따를 수 있다. 5 illustrates a wired multicast network according to an embodiment of the present invention. Multicast streams can be delivered over a wired IP network. A network provided by an ISP (Internet Service Provider) can be used between the multicast sender and the multicast receiver. According to an embodiment, 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. In this case, the transmission of the multicast stream may follow an access protocol corresponding to each ISP.
멀티캐스트 네트워크에 포함된 멀티캐스트 센더 (Multicast sender)는 각 멀티캐스트 리시버 (multicast receiver)에 컨텐트 데이터 (contents data)를 전송할 수 있다. 멀티캐스트 센더 (Multicast sender)는 컨텐트 네트워크 (Content Network)로 부터 패키징된 컨텐트 (packaged content)를 수신하고, 멀티캐스트 프로토콜 (multicast protocol)을 이용하여 복수의 multicast receiver로 전송할 수 있다. 멀티캐스트 네트워크에 포함된 멀티캐스트 리시버 (Multicast receiver)는 멀티캐스트 센더에서 전송한 컨텐트 데이터를 수신하고, 이를 재생할 수 있는 디코딩 디바이스 (decoding device)에 컨텐트 데이터를 전달할 수 있다. 디코딩 디바이스가 컨텐트 데이터를 효율적으로 재생할 수 있도록, 멀티캐스트 리시버는 컨텐트 데이터를 캐쉬(cache)할 수 있다. 실시예에 따라, 멀티캐스트 리시버는 디코딩 디바이스와 동일한 장치 내에서 구성될 수 있다. 또한 실시예에 따라서는, 멀티캐스트 스트림을 유저 네트워크의 게이트웨이 (Gateway)를 통해 수신할 수도 있다. 이러한 실시예에서는 멀티캐스트 리시버가 유저 네트워크의 구성 요소가 될 수 있다.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. According to an embodiment, the multicast receiver may be configured in the same apparatus as the decoding device. In some embodiments, 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.
멀티캐스트 네트워크에 포함된 멀티캐스트 네트워크 컨트롤러 (Multicast network controller)는 멀티캐스트 센더의 컨텐트 전송 및 관련 세션 (session) 정보를 제어할 수 있다. 또한 멀티캐스트 네트워크 컨트롤러는 각각의 멀티캐스트 센더 및 멀티캐스트 리시버에 대한 배치(configuration)을 위한 시그널링 정보를 관리 및 전달할 수 있다. 이러한 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 컨텐트와는 별도의 프로토콜을 이용하여 각각의 멀티캐스트 센더 및 멀티캐스트 리시버와 연결될 수 있다. 또한 실시예에 따라 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 센더에만 연결되고, 멀티캐스트 리시버로 전송되는 시그널링 정보는 멀티캐스트 컨텐트와 동일한 프로토콜을 따를 수 있다. The multicast network controller included in the multicast network may control content transmission and related session information of the multicast sender. In addition, 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. Also, according to an embodiment, 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.
멀티캐스트 네트워크에 포함된 네트워크 캐쉬 (Network Cache)는 멀티캐스트 센더와 멀티캐스트 리시버 사이에 캐쉬 기능을 하는 노드 또는 장치를 포함할 수 있다. 네트워크 캐쉬는 멀티캐스트 전송시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐트를 저장하고, 멀티캐스트 리시버에 멀티캐스트 스트림을 전달할 수 있다. 실시예에 따라, 네트워크 캐쉬는 멀티캐스트 센더와 캐쉬된 컨텐트에 대한 갱신 절차를 수행할 수 있다.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. In a multicast transmission, 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. According to an embodiment, the network cache may perform an update procedure for the multicast sender and the cached content.
도 6은 본 발명의 일 실시예에 따른 모바일 멀티캐스트 네트워크를 나타낸 도면이다. 멀티캐스트 스트림은 유선 IP network를 통해 전달될 수 있지만, 모바일 수신기에 대해서는 모바일 억세스 네트워크 (mobile access network)를 통해 전달될 수 있다. IP multicast를 위해 모바일 억세스 네트워크는 IP 전송을 지원하는 네트워크를 이용할 수 있다. 또한 모바일 억세스 네트워크는 복수의 모바일 수신기에 멀티캐스트 스트림을 서비스 하기 멀티캐스트를 지원 할 수 있다.6 illustrates a mobile multicast network according to an embodiment of the present invention. 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. For IP multicast, mobile access networks can use networks that support IP transport. In addition, the mobile access network may support multicast to serve a multicast stream to a plurality of mobile receivers.
멀티캐스트 네트워크에 포함된 멀티캐스트 센더 (Multicast sender)는 각 멀티캐스트 리시버 (multicast receiver)에 컨텐트 데이터 (contents data)를 전송할 수 있다. 멀티캐스트 센더 (Multicast sender)는 컨텐트 네트워크 (Content Network)로 부터 패키징된 컨텐트 (packaged content)를 수신하고, 멀티캐스트 프로토콜 (multicast protocol)을 이용하여 복수의 멀티캐스트 리시버로 전송할 수 있다. 멀티캐스트 네트워크에 포함된 멀티캐스트 리시버 (Multicast receiver)는 멀티캐스트 센더에서 전송한 컨텐트 데이터를 수신하고, 이를 재생할 수 있는 디코딩 디바이스 (decoding device)에 컨텐트 데이터를 전달할 수 있다. 모바일 억세스 네트워크에 접속되어 있는 멀티캐스트 리시버는 해당 모바일 억세스 네트워크에 대한 무선 신호를 수신할 수 있다. 실시예에 따라, 모바일 억세스 네트워크에 접속되어 있는 멀티캐스트 리시버는 별도의 무선 접속 규격을 통해 디코딩 디바이스와 연결 될 수 있다. 디코딩 디바이스가 컨텐트 데이터를 효율적으로 재생할 수 있도록, 멀티캐스트 리시버는 컨텐트 데이터를 캐쉬(cache)할 수 있다. 실시예에 따라, 멀티캐스트 리시버는 디코딩 디바이스와 동일한 장치 내에서 구성될 수 있다. 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. According to an embodiment, 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. According to an embodiment, the multicast receiver may be configured in the same apparatus as the decoding device.
멀티캐스트 네트워크에 포함된 멀티캐스트 네트워크 컨트롤러 (Multicast network controller)는 멀티캐스트 센더의 컨텐트 전송 및 관련 세션 (session) 정보를 제어할 수 있다. 또한 멀티캐스트 네트워크 컨트롤러는 각각의 멀티캐스트 센더 및 멀티캐스트 리시버에 대한 배치(configuration)을 위한 시그널링 정보를 관리 및 전달할 수 있다. 이러한 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 컨텐트와는 별도의 프로토콜을 이용하여 각각의 멀티캐스트 센더 및 멀티캐스트 리시버와 연결될 수 있다. 또한 실시예에 따라 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 센더에만 연결되고, 멀티캐스트 리시버로 전송되는 시그널링 정보는 멀티캐스트 컨텐트와 동일한 프로토콜을 따를 수 있다. 또한, IP 네트워크와 모바일 억세스 네트워크는 각각 멀티캐스트 네트워크 컨트롤러를 포함할 수 있다. 이 경우 멀티캐스트 네트워크 컨트롤러는 해당하는 네트워크에 대한 제어 및 시그널링 정보의 송수신이 가능하다. 각각의 멀티캐스트 네트워크 컨트롤러는 별도의 프로토콜을 이용해 멀티캐스트 네트워크 컨트롤러 간 통신 (communication)을 수행할 수 있다.The multicast network controller included in the multicast network may control content transmission and related session information of the multicast sender. In addition, 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. Also, according to an embodiment, 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. In addition, 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.
멀티캐스트 네트워크에 포함된 네트워크 캐쉬 (Network Cache)는 멀티캐스트 센더와 멀티캐스트 리시버 사이에 캐쉬 기능을 하는 노드 또는 장치를 포함할 수 있다. 네트워크 캐쉬는 멀티캐스트 네트워크를 구성하는 복수의 네트워크 각각에 포함될 수 있으며, 복수의 네트워크 캐쉬가 각 네트워크에 포함될 수도 있다. 또한, 각각의 네트워크의 일부 노드가 캐쉬 역할을 동시에 수행할 수도 있다. 네트워크 캐쉬는 멀티캐스트 전송시, 효율적인 네트워크 자원의 사용을 위해 적절한 범위의 컨텐트를 저장하고, 멀티캐스트 리시버에 멀티캐스트 스트림을 전달할 수 있다. 실시예에 따라, 네트워크 캐쉬는 멀티캐스트 센더와 캐쉬된 컨텐트에 대한 갱신 절차를 수행할 수 있다.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. In addition, some nodes of each network may simultaneously perform a cache role. In a multicast transmission, 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. According to an embodiment, the network cache may perform an update procedure for the multicast sender and the cached content.
유저 네트워크는 멀티캐스트 네트워크로부터 데이터를 수신하고, 해당 데이터에 포함된 컨텐트를 소비(consume)하는 디바이스로 전달하는 네트워크라 할 수 있다. 유저 네트워크의 구성 및 멀티캐스트를 통한 서비스의 종류에 따라 유저 네트워크는 다양하게 구성될 수 있다. 위에서 설명한 멀티캐스트 리시버는 실시예에 따라 유저 네트워크에 포함될 수 있다. 멀티캐스트 리시버가 유저 네트워크 내에 포함된 경우, 멀티캐스트 리시버는 유저 네트워크에 포함된 게이트웨이 (gateway) 또는 프록시 (proxy) 역할을 하는 장치를 통해 멀티캐스트 컨텐트를 수신 할 수 있다. 이러한 경우, 해당 게이트웨이 또는 프록시는 ABR 멀티캐스트 네트워크의 구성요소로써 간주될 수 있다. The user network may be referred to as a network that receives data from a multicast network and delivers the content included in the data to a device that consumes the content. The user network may be variously configured according to the configuration of the user network and the type of service through multicast. The multicast receiver described above may be included in a user network according to an embodiment. When the multicast receiver is included in the user network, the multicast receiver may receive the multicast content through a device serving as a gateway or proxy included in the user network. In this case, the gateway or proxy may be considered as a component of the ABR multicast network.
멀티캐스트 리시버는 유저 네트워크 내에서 서버 또는 멀티캐스트 센더의 역할을 수행할 수 있다. 이로 인해, 유저 네트워크에 포함된 디코딩 디바이스는 멀티캐스트 컨텐트를 소비할 수 있으며, 디코딩 디바이스가 멀티캐스트 컨텐트의 직접 수신이 불가한 경우에도 멀티캐스트 스트리밍이 가능하게 할 수 있다.The multicast receiver may serve as a server or a multicast sender in the user network. As a result, 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.
도 7은 본 발명의 일 실시예에 따른 유저 네트워크를 나타낸 도면이다. 유저 네트워크의 실시예로써 홈 네트워크가 고려될 수 있다. 멀티캐스트로 전송되는 데이터는 멀티캐스트 리시버가 직접 수신 할 수도 있지만, 홈 네트워크에 속해있는 홈 게이트웨이(Home Gateway)가 데이터를 수신하고, 이를 멀티캐스트 리시버에 전달할 수 있다. 7 illustrates a user network according to an embodiment of the present invention. As an embodiment of the user network, 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.
홈 게이트웨이는 홈 네트워크에 복수의 디바이스들이 포함되어 있는 경우, ABR 멀티캐스트 네트워크로부터 데이터를 수신 받을 수 있다. 홈 게이트웨이는 외부 네트워크와의 데이터 송수신을 수행할 수 있고, 또한 프록시의 역할을 동시에 수행할 수 있다. 홈 게이트웨이가 프록시의 역할을 하는 경우, 홈 게이트웨이는 멀티캐스트 리시버에게 전달할 데이터를 캐쉬(cache) 할 수 있다.The home gateway may receive data from the ABR multicast network when the home network includes a plurality of devices. The home gateway can perform data transmission and reception with an external network and can also simultaneously act as a proxy. If the home gateway acts as a proxy, the home gateway can cache data for delivery to the multicast receiver.
멀티캐스트 리시버는 앞서 기술한 ABR 멀티캐스트 네트워크에 포함될 수도 있으나, 네트워크의 구성상 홈 네트워크의 내부에 위치할 수 있다. 홈 네트워크의 구성에 따라 멀티캐스트 리시버가 프록시의 역할을 겸할 수 있다. 멀티캐스트 리시버가 멀티캐스트 스트림을 직접 재생(play)할 수 없는 경우, 멀티캐스트 리시버에는 멀티캐스트 스트림을 재생할 수 있는 디코딩 디바이스가 추가적으로 연결될 수 있다. 또한, 멀티캐스트 리시버는 복수의 디코딩 디바이스들과 연결되어 멀티캐스트 스트림을 전송할 수 있다. The multicast receiver may be included in the ABR multicast network described above, but may be located inside the home network due to the configuration of the network. Depending on the configuration of the home network, the multicast receiver can act as a proxy. If the multicast receiver cannot directly play the multicast stream, a decoding device capable of playing the multicast stream may be additionally connected to the multicast receiver. In addition, the multicast receiver may be connected with a plurality of decoding devices to transmit a multicast stream.
디코딩 디바이스(Decoding device)는 멀티캐스트 스트림을 재생하여 사용자에게 제공하는 디바이스로 정의할 수 있다. 복수의 디코딩 디바이스들이 멀티캐스트 리시버에 접속할 수 있으며, 디코딩 디바이스는 유니캐스트 또는 멀티캐스트를 통해 데이터를 송수신 할 수 있다. 디코딩 디바이스는 멀티캐스트 스트림을 수신하는 멀티캐스트 네트워크 외에도 유니캐스트 네트워크에 접속할 수 있다. 디코딩 디바이스는 컨텐트 네트워크 또는 ABR 멀티캐스트 네트워크에 리퀘스트(request) 또는 리포트(report) 등을 전송할 수 있다. 실시예에 따라서는 디코딩 디바이스 외에 디코딩 모듈과 디스플레이 스크린 등이 별도의 장치로써 홈 네트워크에 포함될 수 있다. 또한 디코딩 디바이스는 멀티캐스트 리시버와 함께 단일 장치로써 구성될 수 있다.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. In some embodiments, 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.
도 8은 본 발명의 일 실시예에 따른 ABR 멀티캐스트를 위한 네트워크 구조를 나타낸 도면이다. 도면은 어댑티브 미디어 스트리밍 (Adaptive Media Streaming)을 위한 전체 네트워크 구조 (network architecture)의 예를 나타낸다. 어댑티브 미디어 스트리밍을 위한 네트워크 구조는 컨텐트 네트워크, ABR 멀티캐스트 네트워크, 유저 네트워크를 포함할 수 있다. 각 네트워크에 대한 자세한 설명은 이전 도면들에서 설명한 바와 같다. 본 발명에서 정의 하고 있는 노드 (node) 또는 엔터티 (entity)는 논리적인 구성이 될 수 있으며, 각각의 노드는 별도의 장치로 구성될 수 있으나, 실시예에 따라서 인접 노드와 같은 장치에서 동작할 수 있다. 도시된 바와 같이 복수 개의 network들이 서로 연결될 수 있으며 효율적인 멀티캐스트 스트리밍을 위해 시그널링 및 매니지먼트 정보를 교환할 수 있다.8 is a diagram illustrating a network structure for ABR multicast according to an embodiment of the present invention. The figure shows an example of an overall network architecture for Adaptive Media Streaming. 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.
아래에서는 어댑티브 미디어 스트리밍을 위한 네트워크 인터페이스 및 프로토콜에 대해 설명한다. 프로토콜은 실제 미디어 데이터가 전송되는 미디어 프로토콜과, 미디어 데이터를 전송하기 위해 각각의 노드 또는 엔터티를 제어하거나, 수신기를 포함하는 여러 노드 및 엔터티에 미디어 데이터에 대한 구성 정보를 전송하기 위한 시그널링 프로토콜로 구분할 수 있다. 시그널링 및 컨트롤 정보는 시그널링 프로토콜을 이용하여 전달 되지만, 수신기가 단일 연결에 의해 미디어 컨텐트를 수신하는 경우에는 별도의 시그널링 패스(path)가 구성되지 않을 수 있다. 이러한 경우에는 시그널링 및 컨트롤 정보는 미디어 프로토콜을 통해 전달 될 수 있다.The following describes network interfaces and protocols for adaptive media streaming. The protocol can be classified into a media protocol through which actual media data is transmitted, and a signaling protocol for controlling configuration of each node or entity for transmitting media data or for transmitting configuration information about media data to various nodes and entities including a receiver. Can be. Signaling and control information is transmitted using a signaling protocol, but when a receiver receives media content through a single connection, a separate signaling path may not be configured. In this case, signaling and control information can be delivered through the media protocol.
도 9는 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 도시된 바와 같이, 멀티캐스트 리시버가 디코더 (media player)와 동일한 장치 및 모듈로 구성될 수 있다. 컨텐트 네트워크에서 생성되거나 서버에 저장되어 있는 미디어 컨텐트는 사용자의 디코딩 디바이스에 전달될 수 있으며, 복수의 사용자에게 전달하기 위해 멀티캐스트로 전송될 수 있다.9 is a diagram illustrating a protocol for adaptive multicast streaming according to an embodiment of the present invention. As shown, 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.
어댑티브 멀티캐스트 스트리밍 (Adaptive multicast streaming) 환경에서, 컨텐트의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 멀티캐스트 전송을 수행하는 노드 (node) 및 엔터티 (entity)에게로 생성된 컨텐트를 전달 하기 위한 프로토콜과, 해당 컨텐트를 어댑티브 스트리밍 형식으로 멀티캐스트 송수신하는 프로토콜이 각각 정의될 수 있다. 도면에서는 노드 (node) 및 엔터티 (entity)가 멀티캐스트 센더로 도시되었다. 또한, 컨텐트 데이터는 복수의 노드 또는 엔터티를 거치게 되며 각각의 노드 및 엔터티 사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔터티 상의 프로토콜은 데이터를 효율적이면서 실시간으로 다음 노드로 전달하는 프로토콜을 사용할 수 있으며, 이러한 프로토콜을 터널링 (tunneling) 프로토콜이라 명명할 수 있다. 따라서 도시된 바와 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의될 수 있다. 이때, 터널링 프로토콜의 페이로드로써 미디어 컨텐트가 전달 되지만, 터널링 프로토콜은 해당 미디어 컨텐트가 어떠한 형식인지에 관계없이 동작할 수 있다. In the adaptive multicast streaming environment, content generation and multicast transmission / reception processes may be performed separately. Therefore, 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. In the figure, nodes and entities are shown as multicast senders. In addition, content data passes through a plurality of nodes or entities, and an appropriate protocol is required between each node and entity. In this case, 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. Thus, as shown, 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.
멀티캐스트 센더에서는 멀티캐스트 리시버에 어댑티브 스트리밍을 지원 하는 프로토콜이 정의될 수 있고, 해당 어댑티브 스트리밍은 복수의 멀티캐스트 리시버들로 전달되기 위해 IP multicast 방식이 적용될 수 있다. 어댑티브 스트리밍의 프로토콜에 따라, IP multicast 방식은 TCP/IP 와 UDP/IP 의 조합으로 정의될 수 있다.In the multicast sender, 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. Depending on the protocol of adaptive streaming, IP multicast can be defined as a combination of TCP / IP and UDP / IP.
멀티캐스트 리시버가 디코더 및 플레이어을 수행할 수 있는 경우, 멀티캐스트 리시버는 IP multicast 패킷을 수신하여 어댑티브 스트리밍 데이터를 획득하고 해당 데이터에서 미디어 컨텐트 포맷에 해당하는 데이터를 디코딩 및 재생 (play)할 수 있다.When the multicast receiver can perform a decoder and a player, 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.
도 10은 본 발명의 일 실시예에 따른 어댑티브 멀티캐스트 스트리밍을 위한 프로토콜을 나타낸 도면이다. 도시된 바와 같이, 멀티캐스트 리시버가 디코더 (media player)와는 별도의 장치 또는 모듈로 구성될 수 있다. 컨텐트 네트워크에서 생성되거나 서버에 저장되어 있는 미디어 컨텐트는 사용자의 디코딩 디바이스에 전달될 수 있으며, 복수의 사용자에게 전달하기 위해 멀티캐스트로 전송될 수 있다.10 illustrates a protocol for adaptive multicast streaming according to an embodiment of the present invention. As shown, 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.
어댑티브 멀티캐스트 스트리밍 (Adaptive multicast streaming) 환경에서, 컨텐트의 생성과 멀티캐스트 송수신 과정은 분리되어 수행될 수 있다. 따라서, 멀티캐스트 전송을 수행하는 노드 (node) 및 엔터티 (entity)에게로 생성된 컨텐트를 전달 하기 위한 프로토콜과, 해당 컨텐트를 어댑티브 스트리밍 형식으로 멀티캐스트 송수신하는 프로토콜이 각각 정의될 수 있다. 도면에서는 노드 (node) 및 엔터티 (entity)가 멀티캐스트 센더로 도시되었다. 또한, 컨텐트 데이터는 복수의 노드 또는 엔터티를 거치게 되며 각각의 노드 및 엔터티 사이에도 적절한 프로토콜이 필요하다. 이때, 노드 또는 엔터티 상의 프로토콜은 데이터를 효율적이면서 실시간으로 다음 노드로 전달하는 프로토콜을 사용할 수 있으며, 이러한 프로토콜을 터널링 (tunneling) 프로토콜이라 명명할 수 있다. 따라서 도시된 바와 같이 서버와 멀티캐스트 센더 사이에 터널링 프로토콜이 정의될 수 있다. 이때, 터널링 프로토콜의 페이로드로써 미디어 컨텐트가 전달 되지만, 터널링 프로토콜은 해당 미디어 컨텐트가 어떠한 형식인지에 관계없이 동작할 수 있다. In the adaptive multicast streaming environment, content generation and multicast transmission / reception processes may be performed separately. Therefore, 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. In the figure, nodes and entities are shown as multicast senders. In addition, content data passes through a plurality of nodes or entities, and an appropriate protocol is required between each node and entity. In this case, 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. Thus, as shown, 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.
멀티캐스트 센더에서는 멀티캐스트 리시버에 어댑티브 스트리밍을 지원 하는 프로토콜이 정의될 수 있고, 해당 어댑티브 스트리밍은 복수의 멀티캐스트 리시버들로 전달되기 위해 IP multicast 방식이 적용될 수 있다. 어댑티브 스트리밍의 프로토콜에 따라, IP multicast 방식은 TCP/IP 와 UDP/IP 의 조합으로 정의될 수 있다.In the multicast sender, 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. Depending on the protocol of adaptive streaming, IP multicast can be defined as a combination of TCP / IP and UDP / IP.
멀티캐스트 리시버와 디코더 (player)가 별도의 장치 또는 module로 구성되어 있는 경우에는, 멀티캐스트 리시버가 IP multicast 패킷을 수신하여 어댑티브 스트리밍 데이터를 획득하고 이를 다시 디코더에게 전달 할 수 있다. 여기서, 멀티캐스트 리시버와 디코더 사이에는 IP unicast 프로토콜이 사용될 수 있다. 멀티캐스트 리시버가 수신한 컨텐트 데이터는 다시 IP unicast를 통해 디코더로 전달 되고, 디코더는 수신된 미디어 컨텐트 포맷에 해당하는 데이터를 디코딩 및 재생(play)할 수 있다.When the multicast receiver and the decoder (player) are configured as separate devices or modules, the multicast receiver may receive IP multicast packets to obtain adaptive streaming data and deliver them back to the decoder. Here, the IP unicast protocol may be used between the multicast receiver and the decoder. The content data received by the multicast receiver is delivered to the decoder again through IP unicast, and the decoder can decode and play data corresponding to the received media content format.
아래에서는 시그널링 및 컨트롤 메시지를 위한 프로토콜에 대해 설명한다. 시그널링 및 컨트롤 메시지의 전송은 각 노드 및 엔터티가 어댑티브 스트리밍을 수행하는데 있어서, 전송 제어(control), 스케줄링 (scheduling), configuration 정보 등을 제공하기 위해, 미디어 컨텐트 전송과는 구별되는 프로토콜로 정의 될 수 있다. 각각의 노드 및 엔터티가 접속 되어 있는 경우에 따라 별도의 프로토콜로 정의 될 수 있다. 앞서 기술한 네트워크 구조에서 미디어 컨텐트의 전송을 위한 프로토콜에 시그널링 및 컨트롤 메시지가 포함되어 전송될 수 있으나 그러한 시그널링 및 컨트롤 메시지는 미디어 컨텐트 딜리버리를 위한 프로토콜을 따른다.The following describes the protocol for signaling and control messages. Transmission of signaling and control messages may be defined as a protocol distinct from media content transmission in order to provide transmission control, scheduling, configuration information, etc. in each node and entity performing adaptive streaming. have. Depending on the case where each node and entity is connected, it can be defined as a separate protocol. In the above-described network structure, signaling and control messages may be included and transmitted in a protocol for transmitting media content, but such signaling and control messages follow a protocol for media content delivery.
도 11은 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다. 앞서 기술한 네트워크 구조에서 컨텐트 네트워크에 포함되는 오퍼레이터 컨트롤러(operator controller)와 멀티캐스트 네트워크에 포함되는 네트워크 컨트롤러 (network controller) 사이에 컨트롤 프로토콜이 정의될 수 있다. 또한 오퍼레이터 컨트롤러가 컨트롤 및 매니지먼트 메시지를 생성하기 위해 네트워크 컨트롤러는 컨트롤 메시지에 대한 응답(response) 또는 리포트 (report) 메시지를 오퍼레이터 컨트롤러로 보낼 수 있다. 따라서, 컨트롤 메시지를 보내기 위한 터널링 프로토콜 (tunneling protocol)은 양방향으로 구성 될 수 있다. 단일 오퍼레이터 컨트롤러는 복수의 멀티캐스트 네트워크 컨트롤러들과 컨트롤 메시지를 송수신할 수 있다. 또한 각각의 멀티캐스트 네트워크 컨트롤러는 별도의 운영주체에서 관리 될 수 있다.11 illustrates a protocol for signaling and control messages according to an embodiment of the present invention. In the above-described network structure, a control protocol may be defined between an operator controller included in a content network and a network controller included in a multicast network. The network controller can also send a response or report message to the operator controller in order for the operator controller to generate control and management messages. Thus, the tunneling protocol (tunneling protocol) for sending a control message can be configured in both directions. A single operator controller can send and receive control messages with multiple multicast network controllers. In addition, each multicast network controller can be managed by a separate operator.
네트워크 컨트롤러에서 네트워크의 configuration 관련 정보는 멀티캐스트 센더 (sender) 및 멀티캐스트 리시버로 전달될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 configuration 정보 및 네트워크의 노드 사이의 mapping 정보, routing 정보 등을 전달할 수 있다. 또한 오퍼레이터 컨트롤러로부터 수신된 configuration 정보 등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달할 수 있다. 이 과정에서, 멀티캐스트 네트워크 컨트롤러에서 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송되는 프로토콜은 구별될 수 있다. 도면 상단은 네트워크 컨트롤러에서 멀티캐스트 센더로 전송되는 프로토콜을 나타내며, 도면 하단은 네트워크 컨트롤러에서 멀티캐스트 리시버로 전송되는 프로토콜을 나타낸다. In the network controller, the configuration related information of the network may be transmitted to the multicast sender and the multicast receiver. The network controller may transmit configuration information about network resources, mapping information between nodes of the network, routing information, and the like. In addition, the configuration information received from the operator controller may be transmitted to the multicast sender or the multicast receiver. In this process, the protocol transmitted from the multicast network controller to the multicast sender and the protocol transmitted to the multicast receiver may be distinguished. The upper part of the figure shows the protocol transmitted from the network controller to the multicast sender, and the lower part of the figure shows the protocol transmitted from the network controller to the multicast receiver.
또한, 하나의 네트워크 컨트롤러에서 복수의 멀티캐스트 센더 및 멀티캐스트 리시버로 configuration 메시지를 전달 하기 위해 IP multicast가 사용될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등은 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행할 수 있기 때문에 unicast 방식의 프로토콜이 이용될 수 있다. 이러한 일련의 컨트롤 정보, configuration 정보 등은 동적으로 업데이트 될 수 있고, 즉시 또는 스케쥴링을 통해 전송될 수 있다.In addition, IP multicast may be used to deliver configuration messages from a single network controller to a plurality of multicast senders and multicast receivers. Connections, statistical information, etc. collected by the multicast sender and the multicast receiver may be reported to the multicast network controller. Since this process can be performed independently by each multicast sender and multicast receiver, a unicast protocol can be used. This set of control information, configuration information, etc. can be dynamically updated and transmitted immediately or through scheduling.
멀티캐스트 리시버는 수신된 어댑티브 스트리밍 데이터를 다시 디코딩 디바이스에 전송하기 위한 시그널링 프로토콜을 사용할 수 있다. 여기서, 개별 디코딩 디바이스에 별도의 정보를 제공하기 위해 IP unicast 방식의 프로토콜이 정의될 수 있다. 또한 디코딩 디바이스는 IP unicast 방식의 프로토콜을 이용하여 디코딩 디바이스가 요청하는 사항에 대한 시그널링을 멀티캐스트 리시버에게로 전달할 수 있다. 따라서 멀티캐스트 리시버와 디코딩 디바이스 사이에 양방향 프로토콜로써 정의 될 수 있다.The multicast receiver may use a signaling protocol for sending the received adaptive streaming data back to the decoding device. Here, an IP unicast protocol may be defined to provide separate information to individual decoding devices. In addition, the decoding device may transmit signaling of the request of the decoding device to the multicast receiver using an IP unicast protocol. Therefore, it can be defined as a bidirectional protocol between the multicast receiver and the decoding device.
도 12는 본 발명의 일 실시예에 따른 시그널링 및 컨트롤 메시지를 위한 프로토콜을 나타낸다. 도시된 바와 같이, 멀티캐스트 네트워크 컨트롤러는 멀티캐스트 리시버에 직접 접속되지 않고, 멀티캐스트 센더를 통해 멀티캐스트 리시버에 접속될 수 있다. 12 illustrates a protocol for signaling and control messages according to an embodiment of the present invention. As shown, the multicast network controller may be connected to the multicast receiver via a multicast sender rather than directly to the multicast receiver.
네트워크 컨트롤러에서 네트워크의 configuration 관련 정보는 멀티캐스트 센더 (sender) 및 멀티캐스트 리시버로 전달될 수 있다. 네트워크 컨트롤러는 네트워크 자원에 대한 configuration 정보 및 네트워크의 노드 사이의 mapping 정보, routing 정보 등을 전달할 수 있다. 또한 오퍼레이터 컨트롤러로부터 수신된 configuration 정보 등을 멀티캐스트 센더 또는 멀티캐스트 리시버 등으로 전달할 수 있다. 그런데 여기서 멀티캐스트 컨트롤러는 멀티캐스트 센더에만 연결되어 있고, 멀티캐스트 리시버와는 연결되어 있지 않으므로, 멀티캐스트 센더가 네트워크 컨트롤러에서 멀티캐스트 리시버로 전달되는 configuration 메시지를 포워딩(forwarding) 해 줄 수 있다. 멀티캐스트 네트워크 컨트롤러에서 configuration 관련한 프로토콜 또는 message set은 멀티캐스트 센더로 전송되는 프로토콜과 멀티캐스트 리시버로 전송되는 프로토콜이 구별될 수 있다.In the network controller, the configuration related information of the network may be transmitted to the multicast sender and the multicast receiver. The network controller may transmit configuration information about network resources, mapping information between nodes of the network, routing information, and the like. In addition, the configuration information received from the operator controller may be transmitted to the multicast sender or the multicast receiver. However, since the multicast controller is connected only to the multicast sender and not to the multicast receiver, the multicast sender can forward the configuration message transmitted from the network controller to the multicast receiver. In a multicast network controller, a protocol or message set related to configuration may be distinguished from a protocol transmitted to a multicast sender and a protocol transmitted to a multicast receiver.
또한, 하나의 네트워크 컨트롤러에서 복수의 멀티캐스트 센더 및 멀티캐스트 리시버로 configuration 메시지를 전달 하기 위해 IP multicast가 사용될 수 있다. 멀티캐스트 센더 및 멀티캐스트 리시버 등에서 수집되는 접속, 통계 정보 등은 멀티캐스트 네트워크 컨트롤러로 리포트될 수 있다. 이러한 과정은 각각의 멀티캐스트 센더 및 멀티캐스트 리시버가 독립적으로 수행할 수 있기 때문에 unicast 방식의 프로토콜이 이용될 수 있다. 이러한 일련의 컨트롤 정보, configuration 정보 등은 동적으로 업데이트 될 수 있고, 즉시 또는 스케쥴링을 통해 전송될 수 있다.In addition, IP multicast may be used to deliver configuration messages from a single network controller to a plurality of multicast senders and multicast receivers. Connections, statistical information, etc. collected by the multicast sender and the multicast receiver may be reported to the multicast network controller. Since this process can be performed independently by each multicast sender and multicast receiver, a unicast protocol can be used. This set of control information, configuration information, etc. can be dynamically updated and transmitted immediately or through scheduling.
멀티캐스트 리시버에서 멀티캐스트 네트워크 컨트롤러로 전송되는 리포트 등의 정보는 멀티캐스트 센더를 통해 멀티캐스트 네트워크 컨트롤러로 전달 될 수 있다. 즉, 멀티캐스트 리시버로부터 멀티캐스트 네트워크 컨트롤러로 전달되는 리포트 메시지 등을 멀티캐스트 센더가 포워딩 해 줄 수 있다. 그 외의 프로토콜의 동작은 앞서 기술한 도면의 설명과 동일하게 적용될 수 있다.Information such as reports sent from the multicast receiver to the multicast network controller can be delivered to the multicast network controller through the multicast sender. 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.
도 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등이 이용될 수 있다. 13 illustrates a protocol for transmitting media data through an IP network according to an embodiment of the present invention. A protocol and a packet format corresponding to each layer may be determined. Each protocol may be configured independently or specific protocols may be combined for interoperability. The operation of compressing the video and audio data collected by the encoder, converting it into an appropriate codec, and delivering it to a packager may be performed as data processing inside the transmission system. For multicast of video and audio, efficient codec can be used, codec such as HEVC (High Efficiency Video Coding), AVC (Advanced Video Coding) can be used for video data, and AAC (Advanced) for audio data. Audio Coding), AC4 (audio compression 4), Moving Picture Experts Group-H (MPEG-H) audio codec and the like can be used.
각각의 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값은 별도의 링크 또는 채널을 통해 전달될 수 있다.Each codec can be packaged in a form suitable for transmission or storage. For this purpose, ISO base media file format (ISOBMFF), Common Media Application Format (CMAF), MPEG-2 TS (Transport Stream) format, etc. may be used. In the process of packaging the codec-encoded content data, DRM (Digital Rights Management) can be added to play the contents only in a specific receiver, and the authentication key value used in the DRM is transmitted through a separate link or channel. Can be.
파일 형태로 구성된 미디어 데이터는 전송 방식에 따라 FLUTE (File Delivery over Unidirectional Transport)과 같이 파일을 직접 전송 할 수 있는 프로토콜이 적용될 수 있다. 또한, DASH (Dynamic Adaptive Streaming over HTTP)와 같은 어댑티브 스트리밍을 지원 하는 프로토콜이 이용될 수 있다. FLUTE 또는 DASH의 구성에 따라 하위 레이어의 프로토콜이 적용될 수 있다. 예를 들어 DASH 가 적용되어 있는 경우 하위 레이어 프로토콜로써 HTTP가 적용되거나, DASH 세그먼트를 파일로 간주하고 FLUTE가 하위 레이어 프로토콜로 사용될 수 있다. 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. In addition, 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.
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) 프로토콜로 정의될 수 있다.For IP multicast, Transmission Control Protocol / Internet Protocol (TCP / IP) or User Datagram Protocol / Internet Protocol (UDP / IP) may be used depending on the configuration of the upper protocol. In addition, IGMP (Internet Group Management Protocol), which can manage the subscription of the IP multicast group and the like in the multicast receiver, may be parallel. Layer 2 and Layer 1 protocols may be defined for each transport link. That is, an optimized protocol may be configured according to a link between nodes and entities configured on a network. For example, in a LAN (Local Area Network) environment, Layer 2 may be defined as Ethernet, and Layer 1 may be defined as CSMA / CD (Carrier sense multiple access with collision detection) protocol.
도 14는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. 미디어 딜리버리 프로토콜은 미디어 컨텐트가 전송되는 경로에 따른 프로토콜의 구체적인 실시 예를 나타낸 것이다. 여기에서, 멀티캐스트 리시버는 디코더 (media player)와 동일한 장치 및 모듈로 구성되어 있는 경우를 나타낸다.14 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention. The media delivery protocol illustrates a specific embodiment of the protocol according to a path through which media content is transmitted. Here, the multicast receiver is composed of the same devices and modules as the decoder (media player).
컨텐트를 위해 서버에서 사용되는 프로토콜은 미디어 코덱 (media codec)과 파일 포맷 (file format)이다. 미디어 코덱은 비디오, 오디오 또는 그 외의 인코딩 포맷을 포함할 수 있다. 비디오에 대해서는 HEVC, AVC 등의 코덱을 포함할 수 있고, 오디오에 대해서는 AAC, AC4, MPEG-H audio codec 등의 코덱을 포함할 수 있다. 파일 포맷에 대한 프로토콜은, 코덱 포맷을 파일 형태로 전송 또는 저장하기 위한 포맷으로써 정의될 수 있다. 이를 위해 ISOBMFF, CMAF 등의 파일 포맷이 사용될 수 있고, 기존 방송 네트워크가 연결되는 경우에는 MPEG-2 TS의 포맷을 이용하여 전송될 수 있다. 파일 포맷을 전송의 효율화를 위해 복수개의 포맷이 사용될 수 있다. The protocols used on the server for content are the media codec and file format. The media codec may include video, audio or other encoding formats. The video may include a codec such as HEVC and AVC, and the audio may include a codec such as AAC, AC4, and MPEG-H audio codec. The protocol for the file format may be defined as a format for transmitting or storing the codec format in the form of a file. For this purpose, file formats such as ISOBMFF and CMAF may be used, and may be transmitted using the format of MPEG-2 TS when the existing broadcast network is connected. A plurality of formats may be used for streamlining the file format.
서버와 멀티캐스트 센더 사이의 프로토콜은 주로 파일 포맷의 효율적인 전달을 위한 프로토콜을 정의 할 수 있다. 따라서, 서버에서 생성된 컨텐트의 데이터를 터널링 프로토콜 (tunneling protocol)을 이용하여 전달 할 수 있다. 터널링 프로토콜은 주로 RTP 와 같은 실시간 전송 프로토콜을 이용할 수 있고, 그 외 해당 네트워크에서 사용할 수 있는 IP 기반의 다른 터널링 프로토콜을 이용할 수 있다. 이때 기존의 프로토콜을 그대로 이용 하거나, 해당 네트워크에 적합하도록 필드 (field)의 정의를 변경할 수 있다. 멀티캐스트 센더에서는 서버로부터 터널링 프로토콜을 이용하여 전달되는 파일을 수신하기 위해 입력단에 터널링 프로토콜이 정의 될 수 있다. 이때 터널링 프로토콜을 이용하여 전송되는 파일 포맷은 멀티캐스트 센더로부터 멀티캐스트 리시버로 전달해야 하는 데이터이므로, 해당 데이터의 포맷에 무관하게 터널링 프로토콜이 동작할 수 있다. The protocol between the server and the multicast sender can mainly define a protocol for efficient delivery of file formats. Therefore, the data of the content generated in the server can be delivered using a tunneling protocol. The tunneling protocol may mainly use a real-time transmission protocol such as RTP, and other IP-based tunneling protocols that may be used in the corresponding network. At this time, the existing protocol may be used as it is or the definition of the field may be changed to suit the network. In the multicast sender, a tunneling protocol may be defined at an input terminal to receive a file transferred from the server using the tunneling protocol. In this case, since the file format transmitted using the tunneling protocol is data to be transmitted from the multicast sender to the multicast receiver, the tunneling protocol may operate regardless of the format of the corresponding data.
멀티캐스트 센더와 멀티캐스트 리시버 사이의 프로토콜은 주로 어댑티브 스트리밍(adaptive streaming)을 위한 프로토콜로 정의될 수 있다. 이러한 프로토콜은 DASH 기반의 프로토콜로 구성될 수 있으며, 이를 위해 하위 레이어 프로토콜은 IP multicast를 기반으로 한다. DASH가 동작하기 위해 HTTP 등의 프로토콜이 함께 사용될 수 있으며, DASH 세그먼트가 파일 형태로 이용되는 경우에는 FLUTE 등의 파일 전송 프로토콜이 구성 될 수 있다. 추가로, DASH/HTTP 프로토콜의 효과적인 네트워크 상의 컨넥션 및 멀티캐스트 전송을 위해 TCP/IP가 사용될 수 있다.The protocol between the multicast sender and the multicast receiver can be defined primarily as a protocol for adaptive streaming. These protocols can be composed of DASH-based protocols. For this purpose, the lower layer protocol is based on IP multicast. A protocol such as HTTP may be used together for DASH to operate, and when a DASH segment is used as a file, a file transfer protocol such as FLUTE may be configured. In addition, TCP / IP can be used for the connection and multicast transmissions on an effective network of the DASH / HTTP protocol.
멀티캐스트 리시버는 멀티캐스트로 전송된 패킷 스트림 (packet stream)을 수신하기 위해 TCP/IP를 이용할 수 있다. 또한, 멀티캐스트 리시버는 패킷 스트림에 대한 요청 (request), 수신된 데이터에 대한 응답 (response) 등을 위해 HTTP를 사용할 수 있다. 멀티캐스트 센더에서 DASH를 사용하여 어댑티브 스트리밍하는 경우, 멀티캐스트 리시버는 DASH client를 포함할 수 있다. DASH를 이용하여 어댑티브 스트리밍되는 데이터는 서버에서 송신한 파일 포맷으로 구성되어 있다. 따라서, 멀티캐스트 리시버는 해당 파일 포맷을 식별할 수 있는 파일 포맷 관련 프로토콜과, 식별된 미디어 포맷을 디코딩할 수 있는 미디어 코덱을 사용할 수 있다.Multicast receivers can use TCP / IP to receive packet streams sent in multicast. In addition, the multicast receiver may use HTTP for a request for a packet stream, a response for received data, and the like. In the case of adaptive streaming using DASH in the multicast sender, the multicast receiver may include a DASH client. Data streamed adaptively using DASH consists of a file format sent by the server. Accordingly, the multicast receiver may use a file format related protocol capable of identifying the corresponding file format and a media codec capable of decoding the identified media format.
도 15는 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. 미디어 딜리버리 프로토콜은 미디어 컨텐트가 전송되는 경로에 따른 프로토콜의 구체적인 실시 예를 나타낸 것이다. 본 실시예는, 멀티캐스트 리시버가 디코더 (media player)와는 별도의 장치 또는 모듈로 구성되어 있는 경우를 나타낸다. 따라서, 멀티캐스트 리시버는 수신된 멀티캐스트 스트림을 디코딩 디바이스 (디코더)에 전송하는 과정이 필요하다.15 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention. The media delivery protocol illustrates a specific embodiment of the protocol according to a path through which media content is transmitted. This embodiment shows a case in which the multicast receiver is composed of a device or module separate from the decoder (media player). Therefore, the multicast receiver needs to transmit the received multicast stream to the decoding device (decoder).
멀티캐스트 리시버는 멀티캐스트로 전송된 패킷 스트림 (packet stream)을 수신하기 위해 TCP/IP를 이용할 수 있다. 또한, 멀티캐스트 리시버는 패킷 스트림에 대한 요청 (request), 수신된 데이터에 대한 응답 (response) 등을 위해 HTTP를 사용할 수 있다. 멀티캐스트 센더에서 DASH를 사용하여 어댑티브 스트리밍하는 경우, 멀티캐스트 리시버는 DASH client를 포함할 수 있다. DASH를 이용하여 어댑티브 스트리밍되는 데이터에 대해 멀티캐스트 리시버는 프록시(proxy) 역할을 수행할 수 있다. 멀티캐스트 리시버는 데이터를 디코딩 디바이스로 전달할 수 있다. 멀티캐스트 리시버에 접속되어 있는 디코딩 디바이스의 수는 한정될 수 있으므로 해당 연결은 유니캐스트 전송을 기반으로 할 수 있다. 따라서, 멀티캐스트 리시버는 유니캐스트 연결을 위한 HTTP와 TCP/IP protocol를 이용할 수 있다.Multicast receivers can use TCP / IP to receive packet streams sent in multicast. In addition, the multicast receiver may use HTTP for a request for a packet stream, a response for received data, and the like. In the case of adaptive streaming using DASH in the multicast sender, the multicast receiver may include a DASH client. The multicast receiver may act as a proxy for data adaptively streamed using DASH. The multicast receiver can deliver data to the decoding device. Since the number of decoding devices connected to the multicast receiver can be limited, the connection can be based on unicast transmissions. Thus, multicast receivers can use the HTTP and TCP / IP protocols for unicast connections.
디코딩 디바이스는 멀티캐스트 리시버로부터 전송되는 데이터를 수신하기 위해 유니캐스트 프로토콜을 이용할 수 있다. HTTP 유니캐스트를 통해 전달된 데이터는 서버에서 송신한 파일 포맷을 가질 수 있다. 따라서 디코딩 디바이스는 해당 파일 포맷을 식별할 수 있는 파일 포맷 관련 프로토콜과 식별된 미디어 포맷을 디코딩할 수 있는 미디어 코덱을 사용할 수 있다. 그 외의 프로토콜에 대한 동작은 이전 도면에서 기술한 실시 예와 동일 하다.The decoding device may use a unicast protocol to receive data sent from the multicast receiver. Data delivered via HTTP unicast may have a file format sent by the server. Accordingly, the decoding device may use a file format related protocol capable of identifying the corresponding file format and a media codec capable of decoding the identified media format. Operation for other protocols is the same as the embodiment described in the previous drawings.
도 16은 본 발명의 일 실시예에 따른 IP 멀티캐스팅을 위한 미디어 딜리버리 프로토콜을 나타낸 도면이다. DASH 세그먼트를 전송하는 방식은 QUIC (Quick UDP Internet Connections) 프로토콜을 이용할 수 있다. TCP/IP를 사용한 멀티캐스트 방식은 컨넥션 (connection)을 형성하는데 딜레이(delay)가 발생 될 수 있고, 스트리밍 데이터를 즉시 전송하는데 부적합할 수 있다. QUIC 기반의 프로토콜은 컨넥션 및 플로우 (flow) 제어에 대한 과정을 QUIC에서 담당한다. 또한 QUIC는 HTTP/2를 사용할 수 있으며, 이로 인해 기존의 HTTP에서 발생하는 전송 지연을 개선할 수 있으며, UDP/IP를 이용하여 스트리밍 데이터를 즉시 전송 할 수도 있다. 그 외의 protocol에 대한 동작은 앞서 기술한 실시 예와 동일 하다.16 illustrates a media delivery protocol for IP multicasting according to an embodiment of the present invention. The method of transmitting the DASH segment may use the Quick UDP Internet Connections (QUIC) protocol. Multicast schemes using TCP / IP may incur delays in establishing connections and may not be suitable for immediate delivery of streaming data. The QUIC-based protocol takes care of the connection and flow control at QUIC. In addition, QUIC can use HTTP / 2, which can improve the transmission delay incurred by the existing HTTP, and can also immediately transmit streaming data using UDP / IP. Operation for other protocols is the same as the above-described embodiment.
도 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 서버에 저장되어 있는 컨텐트에 대한 세그먼트 파일을 요청할 수 있다.17 shows a DASH transmission scheme according to an embodiment of the present invention. The DASH system may be implemented by transmitting and receiving data between the HTTP server and the DASH client. The DASH client may include a DASH access engine and a media engine. In DASH, an HTTP server can divide content of varying quality into segments on a regular basis and store them on the server. The HTTP server may transmit the divided data unit by using the HTTP protocol when a media request of the DASH client which is a user device is performed. Here, in consideration of the flexible HTTP network state, it is possible to selectively transmit the media content stored in the HTTP server in various qualities. This allows the user to receive a seamless adaptive streaming service. A separate file including information on a timeline order and a quality order of the divided files described above is a media presentation description (MPD). The MPD may provide the DASH client with information about the media data stored on the HTTP server. The MPD is an XML document and may include attributes such as URL, start time, content type, and the like assigned to the divided segment. The DASH client may request the MPD file from the server prior to receiving the media file and receive the MPD file. When the MPD file is received, the DASH client may request a segment file for the content stored in the HTTP server by using the information about the media file included in the MPD.
도 18은 본 발명의 일 실시예에 따른 DASH 세그먼트의 구조를 나타낸 도면이다. DASH 세그먼트는 전송할 콘텐츠를 미디어 세그먼트로 분할하여 일정 기간(duration) 동안 재생될 수 있는 전송 오브젝트의 데이터 단위이다. DASH 미디어 세그먼트는 세그먼트 유형(type)을 나타내는 'styp'박스를 포함하고, 세그먼트 인덱스 정보를 포함하는 'sidx'박스를 포함한다. 또한 DASH 미디어 세그먼트는 fragment단위로 잘려진 미디어 스트림을 포함하고 있는 'mdat'박스와 이에 대한 메타데이터를 담고 있는 'moof'박스를 포함할 수 있다. DASH 클라이언트는 서비스를 요청하기 위해 매니페스트(manifest) 파일인 MPD 파일의 전송을 요청하고, 각 segment URL (Uniform Resource Locator)을 통해 미디어 세그먼트를 요청할 수 있다. 미디어 세그먼트를 디코딩하기 위해서, DASH 클라이언트는 초기화 정보를 담고 있는 초기화 세그먼트 (Initialization segment, IS) 파일을 수신하고 파싱하여 디코더 초기화를 수행한 후, 요청한 미디어 세그먼트 파일을 수신하여 미디어 파싱과 디코딩을 수행할 수 있다. 18 illustrates a structure of a DASH segment according to an embodiment of the present invention. The DASH segment is a data unit of a transport object that can be reproduced for a predetermined period by dividing the content to be transmitted into media segments. The DASH media segment includes a 'styp' box indicating a segment type and a 'sidx' box containing segment index information. In addition, the DASH media segment may include a 'mdat' box containing a media stream cut in fragment units and a 'moof' box containing metadata thereof. The DASH client may request transmission of an MPD file, a manifest file, to request a service, and may request a media segment through each segment Uniform Resource Locator (URL). To decode the media segment, the DASH client receives and parses an initialization segment (IS) file containing the initialization information, performs decoder initialization, and then receives the requested media segment file to perform media parsing and decoding. Can be.
DASH 클라이언트가 수신하는 파일들은 미디어 재생을 위한 구성요소에 따라 구분될 수 있다. DASH 클라이언트는 Manifest 파일인 MPD, 초기화 세그먼트 파일 및 미디어 세그먼트 파일을 수신한 후 미디어를 재생할 수 있다. 따라서 송신단의 미디어 인코더는 전체 재생 블록 (MPD+IS+sidx+moof+mdat) 을 위해 미디어 데이터를 포함하는 mdat을 인코딩하고, 인코딩 정보를 포함한 메타데이터 헤더(styp+sidx+moof)를 생성할 수 있다. 이후 송신단은 디코더 초기화 정보인 IS.mp4 파일을 생성하고, 세그먼트의 URL 정보를 포함하는 MPD에 작성하여 DASH 클라이언트에게로 전송할 수 있다. 수신단의 파싱 오더(parsing order)는 다음과 같다. 수신단은 MPD 파일을 수신하여 파싱하고, 디코더를 초기화하고, 네트워크 상황에 따른 미디어 세그먼트를 요청할 수 있다. Files received by the DASH client may be classified according to components for media playback. The DASH client can play the media after receiving the manifest file, the MPD, the initialization segment file, and the media segment file. Therefore, the transmitting media encoder can encode mdat including media data for the entire play block (MPD + IS + sidx + moof + mdat) and generate a metadata header (styp + sidx + moof) containing the encoding information. have. Thereafter, the transmitting end may generate an IS.mp4 file, which is decoder initialization information, write the MPD including the URL information of the segment and transmit the same to the DASH client. The parsing order of the receiving end is as follows. The receiving end may receive and parse the MPD file, initialize the decoder, and request a media segment according to network conditions.
다양한 품질로 저장된 DASH 세그먼트가 라이브(live) 타입의 서비스를 제공하거나, 라이브 방송 콘텐츠를 인코딩하여 데이터를 전송하는 서비스의 경우는 미디어 서비스 프레임워크(framework) 전체의 실시간성(real-time)이 적용되어야 한다. 따라서, seamless한 서비스의 구현을 위해 딜레이 발생을 최소화해야 한다. DASH 프로토콜을 적용한 라이브 방송시 실시간 컨텐트를 인코딩 및 패킷화하는 과정과 실시간 콘텐츠를 파싱하고 디코딩하는 과정에서 딜레이가 발생하는 경우, 서비스 시작 시점의 딜레이가 발생할 수 있다. 다시 말해, 각 미디어 파일을 생성하고 패킷화하여 송신하면, 패킷의 reception time, 파싱(parsing)을 위해서 전체 패킷이 만들어 질 때까지 기다려야 하는 지연시간이 발생할 수 있다. 이로 인해, 클라이언트 측에서는 버퍼링의 시간이 길어진다. 이와 같은 문제점을 해결하기 위해 아래와 같은 방법을 제안한다.In the case of a service in which DASH segments stored in various qualities provide a live type service or data is transmitted by encoding live broadcast content, the real-time of the entire media service framework is applied. Should be. Therefore, delay should be minimized to realize seamless service. When a delay occurs in encoding and packetizing real-time content and parsing and decoding real-time content during live broadcasting using the DASH protocol, a delay at the start of a service may occur. In other words, when each media file is generated, packetized, and transmitted, a delay time for waiting for the entire packet is generated for reception time and parsing of the packet may occur. As a result, the buffering time becomes longer on the client side. To solve this problem, the following method is proposed.
도 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 내에도 패스트 스타트업을 위한 세그먼트 정보를 포함시켜 미디어 데이터의 재생까지의 딜레이를 최소화 할 수 있다.19 illustrates a structure, a generation, and a parsing sequence of a DASH segment according to an embodiment of the present invention. MPD, IS, sidx, moof, and I frames described in the previous drawings may be made into a single building block and transmitted in advance in order to reduce transmission / reception delay of media data and fast media playback at a receiving end. This may be referred to as a fast startup building block. Using the transmitted MPD, the DASH client can perform playback via MPD transmission and segment request according to the conventional model in unicast. While operating the DASH framework, the DASH client can be included in a single building block to execute fast startup using the I frame received with the MPD. In other words, the transmitting end server may reduce the reception delay by selectively transmitting the I frame without transmitting the entire mdat frame covered by the moof header. In addition, the DASH client may perform a fast audio and video (AV) startup by starting playback from an I frame which is a random access point (RAP). Also, in case of live broadcasting, instead of making all segments of the full quality, the transmitter server considers the network situation or selectively creates the representation / segment that enables fast start-up considering the network operator, and creates the light MPD for this. Can transmit The DASH client can receive the light MPD and configure the fast startup building block to quickly start playing. Thereafter, the DASH client may receive a different quality segment from the proxy to perform bitstream switching according to the quality of the segments. In summary, the transmitting end server may transmit only considering segments for fast start-up, and may include delay information for fast start-up in the MPD to minimize delays until media data is played.
도 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 간의 비트스트림 스위칭을 수행할 수 있다.20 illustrates a user network and an MPD according to an embodiment of the present invention. When 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.
도 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 클라이언트에게 시그널링할 수 있다. 21 is a diagram illustrating details of an MPD according to an embodiment of the present invention. The representation in the aforementioned MPD may include a descriptor that can indicate a common attribute, and may include a common attribute descriptor as shown in the upper part of the figure. The common attribute may include supplemental property descriptors, and through this, an element necessary for the framework of the representation may be defined. Such a descriptor type element may define an attribute of what operation should be performed through the schemeIdUri attribute as shown in the middle of the drawing, and a specific code point for a specific operation may be defined through the value attribute. Can be defined The information for fast startup described above can be defined in the MPD through the extension of a new supplemental property descriptor, thereby signaling the fast startable representation among the representation entries. That is, as shown at the bottom of the figure, the schemeIdUri attribute may be defined as fast startup, and the existing segment mode and the fast mode for the fast startup may be defined for the value attributes. The fastmode may signal to the DASH client that fast startup is possible using the fast startup building block described in the previous figure.
도 22는 본 발명의 일 실시예에 따른 패스트 스타트업을 위한 MPD를 나타낸 도면이다. 도시된 바와 같이, MPD는 XML로 표현될 수 있으며, 패스트 스타트업을 지원하는 Representation에 대해 supplemental property element의 schemeIdUri 속성을 패스트 스타트업(Faststartup)으로 정의하고, value 속성을 패스트모드(Fastmode) 로 설정할 수 있다. 이를 통해 MPD는 해당 representation이 전술한 패스트 스타트업을 지원하는 representation임을 DASH 클라이언트에게 시그널링할 수 있다.22 illustrates an MPD for fast startup according to an embodiment of the present invention. As shown, MPD can be expressed in XML, define the schemeIdUri attribute of the supplemental property element to Faststartup, and set the value attribute to Fastmode for Representation that supports fast startup Can be. Through this, the MPD may signal to the DASH client that the representation is a representation that supports the aforementioned fast startup.
도 23은 본 발명의 일 실시예에 따른 ABR 멀티캐스트 서비스를 위한 시스템 아키텍쳐(architecture)를 보이고 있다. FIG. 23 illustrates a system architecture for ABR multicast service according to an embodiment of the present invention.
도 23은 컨텐트 프로바이더 메트릭스 리포팅 캡쳐부(content provider metrics reporting capture unit) (1010), 컨텐트 프로바이더 콘트롤러(content provider controller) (1020), 컨텐트 준비부(content preparation unit) (1030), 컨텐트 호스팅부(content hosting unit) (1040), 멀티캐스트 서버(multicast server) (1050), 프로비져닝부(provisioning unit) (1060), 멀티캐스트 게이트웨이(multicast gateway) (1070), 및 컨텐트 재생부(content playback unit) (1080)를 포함한다. 또한 도 23은 서비스 디스커버리부(service discovery unit)(1091), DRM 라이센스 매니지먼트부((Digital Rights Management licence management unit)(1093), 및 유니캐스트 리페어부(unicast repair unit) (1095)를 더 포함할 수 있다.23 shows a content provider metrics reporting capture unit 1010, a content provider controller 1020, a content preparation unit 1030, and a content hosting unit. (content hosting unit) 1040, multicast server 1050, provisioning unit 1060, multicast gateway 1070, and content playback unit (1080). 23 further includes a service discovery unit 1091, a DRM license management unit 1093, and a unicast repair unit 1095. Can be.
상기 컨텐트 준비부(1030)는 컨텐트 인코딩부(1031), 컨텐트 인크립션 (encryption)부(1033), 및 컨텐트 패키징부(1035)를 포함할 수 있다. 상기 멀티캐스트 서버(1050)는 컨텐트 인제스트(content ingest)부(1051)와 멀티캐스트 전송부(1053)를 포함할 수 있다. 상기 프로비져닝부(1060)는 서비스 리포팅 캡쳐(service reporting capture)부(1061)와 네트워크 콘트롤러(1063)를 포함할 수 있다. 상기 멀티캐스트 게이트웨이(1070)는 서비스 리포팅(service reporting)부(1071), 서비스 매니지먼트부(1072), 멀티캐스트 수신부(1073), 애셋 저장(asset storage)부(1074), 및 유니캐스트 리페어 클라이언트(1075)를 포함할 수 있다. 상기 컨텐트 재생부(1080)는 재생 메트릭 리포팅(playback metric reporting)부(1081), 컨텐트 언패키징(content unpackaging)부(1083), 컨텐트 디코딩부(1085), 및 컨텐트 디크립션(content decryption)부 (1087)를 포함할 수 있다.The content preparation unit 1030 may include a content encoding unit 1031, a content encryption unit 1033, and a content packaging unit 1035. The multicast server 1050 may include a content ingest unit 1051 and a multicast transmitter 1053. The provisioning unit 1060 may include a service reporting capture unit 1061 and a network controller 1063. The multicast gateway 1070 may include a service reporting unit 1071, a service management unit 1072, a multicast receiving unit 1073, an asset storage unit 1074, and a unicast repair client ( 1075). The content playback unit 1080 includes a playback metric reporting unit 1081, a content unpackaging unit 1083, a content decoding unit 1085, and a content decryption unit. (1087).
도 23의 다음 참조 포인트들(reference points)은 주로 컨텐트를 전송하기 위해 사용된다. The next reference points in FIG. 23 are mainly used for transmitting content.
L은 멀티캐스트 게이트웨이(1070)와 컨텐트 재생부(1080) 사이의 유니캐스트 HTTP interaction 인터페이스이며, 이 인터페이스 L은 콘텐트의 모든 specified 타입들의 페칭(fetching)을 포함한다(This interface L includes the fetching of all specified types of content). 만일 상기 멀티캐스트 게이트웨이(1070)와 컨텐트 재생부(1080)가 셋톱 박스와 같은 싱글 엔드 디바이스에 함께 위치(co-locate)한다면, 인터페이스 L은 로컬 API (Application Programming Interface)가 될 수 있다(interface L may be realised as a local API).L is a unicast HTTP interaction interface between the multicast gateway 1070 and the content playback unit 1080, which includes fetching of all specified types of content (This interface L includes the fetching of all). specified types of content). If the multicast gateway 1070 and the content player 1080 co-locate together in a single end device such as a set-top box, the interface L may be a local application programming interface (API). may be realised as a local API).
B는 컨텐트 호스팅부(1040)와 컨텐트 재생부(1080) 사이의 부트스트랩 유니캐스트 HTTP(s) interaction (Bootstrap unicast HTTP(S) interaction) 인터페이스이다. 이 인터페이스 B는 매니페스트들(manifests)을 페치(fetch)하고 unmediated case에서 컨텐트를 복구(retrieve)하기 위해 사용된다.B is a bootstrap unicast HTTP (S) interaction between the content hosting unit 1040 and the content reproducing unit 1080. This interface B is used to fetch manifests and retrieve content in an unmediated case.
A는 인터페이스 M을 통해 제공하지 않는 컨텐트의 HTTP(S) acquisition 인터페이스이다. 이것은 또한 인터페이스 U가 컨텐트 리페어를 수행하지 못할 때 멀티캐스트 게이트웨이(1070)가 컨텐트 호스팅부(1040)로부터 유니캐스트를 통해 직접적으로 컨텐트를 제공받아 복구(retrieving)하기 위해 사용된다.A is an HTTP (S) acquisition interface for content that is not provided through interface M. It is also used by the multicast gateway 1070 to receive and retrieve content directly from the content hosting unit 1040 via unicast when the interface U cannot perform content repair.
M은 멀티캐스트 서버(1050)에서 멀티캐스트 게이트웨이(1080)로 멀티캐스트 IP 컨텐트를 전송하기 위한 인터페이스이다. 또한 상기 인터페이스 M은 상기 멀티캐스트 서버(1050)에서 유니캐스트 리페어부(1095)로 멀티캐스트 IP 컨텐트를 전송할 때도 사용될 수 있다.M is an interface for transmitting multicast IP content from the multicast server 1050 to the multicast gateway 1080. The interface M may also be used to transmit multicast IP content from the multicast server 1050 to the unicast repair unit 1095.
U는 유니캐스트 리페어부(1095)와 멀티캐스트 게이트웨이(1070)의 유니캐스트 리페어 클라이언트(1075) 사이의 유니캐스트 interaction 인터페이스이다. U is a unicast interaction interface between the unicast repair unit 1095 and the unicast repair client 1075 of the multicast gateway 1070.
U′는 유니캐스트 리페어부(1095)와 멀티캐스트 서버(1050) 사이의 유니캐스트 interaction 인터페이스이다.U 'is a unicast interaction interface between the unicast repair unit 1095 and the multicast server 1050.
Pin은 컨텐트 준비부(1030)의 컨텐트 패키징부(1035)에서 컨텐트 호스팅부(1040)로 제공되는 컨텐트의 publication이다. 이것은 push 인터페이스로 실행되거나, 컨텐트가 주문형(on demand)으로 pull될 수 있다.P in is a publication of content provided from the content packaging unit 1035 of the content preparation unit 1030 to the content hosting unit 1040. This can be done with the push interface, or the content can be pulled on demand.
Oin은 컨텐트 호스팅부(1040)와 멀티캐스트 서버(1050) 사이에서 주고 받는 컨텐트의 ingest이다. 이것은 통상 pull 인터페이스로 실행된다.O in is an ingest of content exchanged between the content hosting unit 1040 and the multicast server 1050. This is usually done with the pull interface.
Pin′은 컨텐트 준비부(1030)의 컨텐트 패키징부(1035)에서 멀티캐스트 서버(1050)로 제공되는 컨텐트의 ingest이다. 이것은 통상 push 인터페이스로 실행된다.P in ′ is an ingest of content provided from the content packaging unit 1035 of the content preparation unit 1030 to the multicast server 1050. This is usually done with the push interface.
도 23의 다음 참조 포인트들(reference points)은 시그널링과 operational reporting을 콘트롤하기 위해 사용된다. The following reference points in FIG. 23 are used to control signaling and operational reporting.
CMS: Control interface for configuration of multicast server (1050).C MS : Control interface for configuration of multicast server (1050).
CMR: Control interface for configuration of multicast gateway (1070).C MR : Control interface for configuration of multicast gateway (1070).
CCP: Control interface for configuration of provisioning unit (1060).C CP : Control interface for configuration of provisioning unit (1060).
RS: Service reporting by service reporting unit (1071) to service reporting capture unit (1061).R S : Service reporting by service reporting unit (1071) to service reporting capture unit (1061).
RCP: Service reporting by service reporting capture unit (1061) to content provider metrics reporting capture unit (1010).R CP : Service reporting by service reporting capture unit (1061) to content provider metrics reporting capture unit (1010).
RPM: Reporting of playback metrics by content playback unit (1080) to content provider metrics reporting capture unit (1010).R PM : Reporting of playback metrics by content playback unit (1080) to content provider metrics reporting capture unit (1010).
그리고, 설명의 편의를 위해 도 23에서 멀티캐스트 서버(1050)는 멀티캐스트 센더라 하기도 하며, 멀티캐스트 게이트웨이(1070)는 멀티캐스트 프록시라고 하기도 한다. 또한 컨텐트 재생부(1080)는 클라이언트 또는 DASH 클라이언트라 하기도 한다. 본 발명은 매니페스트가 MPD인 경우를 일 실시예로 설명한다.For convenience of description, in FIG. 23, the multicast server 1050 may be referred to as a multicast sender, and the multicast gateway 1070 may be referred to as a multicast proxy. The content playback unit 1080 may also be referred to as a client or a DASH client. The present invention describes a case where the manifest is an MPD according to an embodiment.
상기 컨텐트 준비부(1030)의 컨텐트 인코딩부(1031)는 상기 컨텐트 프로바이더 콘트롤러(1020)로부터 컨텐트를 제공받아 인코딩을 수행한다. 즉, 상기 컨텐트 인코딩부(1031)는 비트 레이트를 줄이기 위해 소스 미디어 스트림들을 인코드된 미디어로 변환한다. 이때 싱글 소스 미디어 스트림은 많은 다른 인코드된 representations으로 변환될 수 있다. 상기 컨텐트 인크립션부(1033)는 DRM 라이센스 management부(1093)의 제어에 따라 상기 컨텐트 인코딩부(1031)에서 인코드된 컨텐트에 대해 인크립션을 수행한다. 상기 컨텐트 인크립션부(1033)의 인크립션은 옵셔널이다. 상기 컨텐트 인크립션부(1033)에서 인크립션이 수행되면, 컨텐트 재생부(1080)의 컨텐트 디크립션부(1087)에서도 마찬가지로, DRM 라이센스 management부(1093)의 제어에 따라 인크립션된 컨텐트에 대해 디크립션을 수행한다. 상기 DRM 라이센스 매니지먼트부(1093)는 인크립션 키들을 컨텐트 인크립션부(1033)와 컨텐트 디크립션부(1087)로 제공하는 것을 일 실시예로 한다. 상기 컨텐트 인크립션부(1033)를 바이패스 또는 인크립션되어 출력되는 컨텐트는 컨텐트 패키징부(1035)에서 멀티캐스트 전송에 적합한 포맷으로 패키징되어 멀티캐스트 서버(1050)로 전송 및/또는 컨텐트 호스팅부(1040)로 전송된다. 멀티캐스트 전송에 적합한 포맷은 예를 들어, 하나의 컨텐트를 분할하여 생성된 미디어 세그먼트일 수 있다. 또한 컨텐트 패키징부(1035)는 매니페스트를 생성하여 멀티캐스트 서버(1050)로 전송할 수도 있다. 상기 매니페스트는 상기 컨텐트 호스팅부(1040)에서 생성되어 멀티캐스트 서버(1050)로 제공될 수도 있다.The content encoding unit 1031 of the content preparation unit 1030 receives the content from the content provider controller 1020 and performs encoding. That is, the content encoding unit 1031 converts the source media streams into encoded media to reduce the bit rate. The single source media stream can then be converted into many different encoded representations. The content encryption unit 1033 performs encryption on the content encoded by the content encoding unit 1031 under the control of the DRM license management unit 1093. The encryption of the content encryption unit 1033 is optional. When the encryption is performed in the content encryption unit 1033, the content decryption unit 1087 of the content playback unit 1080 may also decrypt the encrypted content under the control of the DRM license management unit 1093. Perform. According to an embodiment of the present invention, the DRM license management unit 1093 provides the encryption keys to the content encryption unit 1033 and the content decryption unit 1087. The content that is output by bypassing or encrypting the content encryption unit 1033 is packaged in a format suitable for multicast transmission in the content packaging unit 1035 and transmitted to the multicast server 1050 and / or the content hosting unit 1040. Is sent to. A format suitable for multicast transmission may be, for example, a media segment created by dividing one content. In addition, the content packaging unit 1035 may generate a manifest and transmit the manifest to the multicast server 1050. The manifest may be generated by the content hosting unit 1040 and provided to the multicast server 1050.
또 다른 예로, 매니페스트는 컨텐트 프로바이더 콘트롤러(1020)에서 생성되어 컨텐트 준비부(1030)로 제공될 수도 있다. 또 다른 예로, 멀티캐스트 서버(1050)에서 매니페스트를 생성할 수도 있다.As another example, the manifest may be generated by the content provider controller 1020 and provided to the content preparation unit 1030. As another example, the manifest may be generated in the multicast server 1050.
상기 컨텐트 준비부(1030)에서 준비된 컨텐트는 유니캐스트 딜리버리를 위해 상기 컨텐트 호스팅부(1040)에 의해 사용 가능할 수 있게 된다. 이때 상기 컨텐트 호스팅부(1040)는 단순 웹 서버들, 오리진 클러스터의 일부로서 실현할 수 있으며, 또한 분산된 CNS (Content Delivery Network) 시스템으로 동작될 수도 있다. 그러므로, 로드 발란싱(load balancing)과 요청 분산 기술들(예, DNS round-robin, HTTP 302 redirect)이 클라이언트들을 가장 적절한 컨텐트 서버로 지시(direct)하기 위해 사용될 수 있다. The content prepared by the content preparation unit 1030 may be available by the content hosting unit 1040 for unicast delivery. In this case, the content hosting unit 1040 may be implemented as a part of simple web servers, an origin cluster, or may be operated as a distributed content delivery network (CNS) system. Therefore, load balancing and request balancing techniques (eg DNS round-robin, HTTP 302 redirect) can be used to direct clients to the most appropriate content server.
상기 멀티캐스트 서버(1050)는 상기 컨텐트 준비부(1030)에서 출력되는 미디어 컨텐트 (예를 들어, 미디어 세그먼트들)를 멀티캐스트 전송에 맞는 패킷 포맷으로 인캡슐레이션한 후 특정 전송 프로토콜 스택을 이용하여 멀티캐스트 게이트웨이(1070)로 전송한다. 상기 전송 프로토콜 스택으로 ROUTE (Real-Time Object Delivery over Unidirectional Transport), HTTP QUIC, FLUTE, 케이블 IPTV의 NORM (NACK-Oriented Reliable Multicast) 중 하나가 이용될 수 있다. 즉, 상기 멀티캐스트 서버(1050)에서, the ingested 미디어 스트림의 페이로드는 멀티캐스트 전송 프로토콜의 딜리버리 유닛으로 인캡슐레이션된 후 인터페이스 M를 통해 IP 멀티캐스트들을 사용하여 가입된(subscribed) 멀티캐스트 게이트웨이(1070) 클라이언트들에게 네트워크를 통해 전송된다. 푸쉬(push)와 풀(pull) 컨텐트 인제스트(ingest) 방법 모두 멀티캐스트 서버(1050)에서 가능하다.The multicast server 1050 encapsulates media content (eg, media segments) output from the content preparation unit 1030 into a packet format suitable for multicast transmission, and then uses a specific transport protocol stack. Transmit to multicast gateway 1070. As the transport protocol stack, one of Real-Time Object Delivery over Unidirectional Transport (ROUTE), HTTP QUIC, FLUTE, and NORM (NACK-Oriented Reliable Multicast) of cable IPTV may be used. That is, in the multicast server 1050, the payload of the ingested media stream is encapsulated into a delivery unit of a multicast transport protocol and then subscribed to using multicast gateways over IP interface M. 1070 is sent over the network to the clients. Both push and pull content ingest methods are possible in the multicast server 1050.
상기 유니캐스트 리페어부(1095)는 레퍼런스 포인트 M을 통해 멀티캐스트 컨텐트 전송에 귀 기울이고(listen to), 유니캐스트 리페어 클라이언트(1075)로부터 수신된 리페어 요청을 만족하기 위해 사용하는 패킷 스트림의 복사본을 로컬리 캐쉬(locally cache)한다. The unicast repair unit 1095 listens to multicast content transmission through the reference point M, and copies a copy of the packet stream used to satisfy the repair request received from the unicast repair client 1075. Cache locally.
상기 멀티캐스트 게이트웨이(1070)는 패킷화된 컨텐트 세그먼트들을 상기 컨텐트 재생부(1080)로 제공한다. The multicast gateway 1070 provides the packetized content segments to the content playback unit 1080.
상기 멀티캐스트 게이트웨이(1070)는 멀티캐스트 서버(1050)로부터 멀티캐스트로 미디어 세그먼트들을 수신할 수 있다. 또한 상기 멀티캐스트 게이트웨이(1070)는 컨텐트 호스팅부(1040), 멀티캐스트 서버(1050), 유니캐스트 리페어부(1095) 중 적어도 하나를 통해 유니캐스트로 미디어 세그먼트들을 수신할 수도 있다. 특히 상기 멀티캐스트 게이트웨이(1070)는 유니캐스트 리페어부(1095)에서 컨텐트 리페어를 수행하지 못할 때 컨텐트 호스팅부(1040)로부터 인터페이스 A를 통해 유니캐스트로 직접 컨텐트를 제공받을 수 있다.The multicast gateway 1070 may receive media segments multicast from the multicast server 1050. In addition, the multicast gateway 1070 may receive media segments in unicast through at least one of the content hosting unit 1040, the multicast server 1050, and the unicast repair unit 1095. In particular, when the multicast gateway 1070 fails to perform content repair in the unicast repair unit 1095, the multicast gateway 1070 may receive content directly from the content hosting unit 1040 through unicast through the interface A.
본 발명은 멀티캐스트 게이트웨이(1070)를 컨텐트 재생부(1080)와 가장 가까운 곳에 위치시키고 상기 멀티캐스트 서버(1050)에서 특정 전송 프로토콜 스택으로 제공되는 미디어 세그먼트들 (즉, 컨텐트 세그먼트들)을 저장한 후 분산시키는 것을 일 실시예로 한다. 즉, 상기 컨텐트 재생부(1080)에 가장 가깝게 위치시킨 멀티캐스트 게이트웨이(1070)는 상기 멀티캐스트 서버(1050)에서 전송 포맷에 맞게 패킷화되어 특정 프로토콜 스택으로 제공되는 미디어 세그먼트들을 저장한 후, 컨텐트 재생부(1080)의 요청 (예를 들어, 특정 어플리케이션의 실행이나 채널 전환 등)에 따라 상기 저장된 미디어 세그먼트들 중 해당 미디어 세그먼트를 상기 컨텐트 재생부(1080)로 제공하는 것을 일 실시예로 한다. 다시 말해, 상기 컨텐트 재생부(1080)에서 요청하는 미디어 세그먼트는 멀티캐스트 서버(1050)까지 가지 않고, 상기 멀티캐스트 게이트웨이(1070)에서 바로 컨텐트 재생부(1080)로 제공된다.The present invention locates the multicast gateway 1070 closest to the content player 1080 and stores media segments (ie, content segments) provided from the multicast server 1050 to a specific transport protocol stack. After the dispersion is an embodiment. That is, the multicast gateway 1070 located closest to the content playback unit 1080 stores the media segments packetized according to the transmission format in the multicast server 1050 and provided to a specific protocol stack, and then the content. According to an embodiment of the present disclosure, a corresponding media segment among the stored media segments is provided to the content playback unit 1080 according to a request of the playback unit 1080 (for example, execution of a specific application or channel switching). In other words, the media segment requested by the content player 1080 does not go to the multicast server 1050, but is provided directly to the content player 1080 from the multicast gateway 1070.
상기와 같은 기능을 갖는 멀티캐스트 게이트웨이(1070)는 홈 게이트웨이나 IP-connected 셋톱 박스와 같은 고객 댁내 장치(customer premises equipment)에 위치시키는 것을 일 실시예로 한다. 상기 멀티캐스트 게이트웨이(1070)는 프록시 서버로서 동작할 수도 있다.In one embodiment, the multicast gateway 1070 having the above function is located in a customer premises equipment such as a home gateway or an IP-connected set-top box. The multicast gateway 1070 may operate as a proxy server.
그리고 컨텐트 요청들이 인터페이스 L을 통해 컨텐트 재생부(1080)로부터 수신되면, 이들은 애셋 스토리지(1073)에 캐시된(cached) 컨텐트로부터 직접적으로 또는 인터페이스 A를 통해 복구된 컨텐트로부터 간접적으로 서비스될 수 있다. 그리고 복구된 컨텐트는 상기 애셋 스토리지(1073)에 캐시될 수도 있다. And when content requests are received from content playback unit 1080 via interface L, they may be serviced directly from content cached in asset storage 1073 or indirectly from content recovered via interface A. The recovered content may be cached in the asset storage 1073.
상기 멀티캐스트 게이트웨이(1070)의 서비스 매니지먼트부(1072)는 서비스 리포팅 캡쳐부(1061)의 위치뿐만 아니라 인터페이스 M을 통해 이용 가능한 멀티캐스트 컨텐트 스트림에 관한 service configuration information을 수집 분석한다(collate). 상기 정보는 레퍼런스 포인트 CMR을 통해 네트워크 콘트롤러(1063)로부터 직접 수신할 수도 있고, 멀티캐스트 게이트웨이(1070)의 멀티캐스트 수신부(1073)로부터 간접적으로 수신할 수도 있다. The service management unit 1072 of the multicast gateway 1070 collects and analyzes service configuration information regarding the multicast content stream available through the interface M as well as the location of the service reporting capture unit 1061. The information may be directly received from the network controller 1063 through the reference point C MR or indirectly from the multicast receiver 1073 of the multicast gateway 1070.
상기 멀티캐스트 수신부(1073)는 인터페이스 M을 통해 컨텐트 스트림들을 인제스트(ingest)한다. 이때 수신된 컨텐트는 나중에 사용하기 위해 애셋 스토리지(1074)에 캐시될 수도 있다.The multicast receiver 1073 ingests the content streams through the interface M. The received content may then be cached in asset storage 1074 for later use.
상기 유니캐스트 리페어 클라이언트(1075)는 lossed 멀티캐스트 패킷을 복구한다.The unicast repair client 1075 recovers the losted multicast packet.
상기 애셋 스토리지(1074)는 인터페이스 L을 통해 제공되는 애셋(asset)들의 임시 스토리지(temporary storage)를 제공한다.The asset storage 1074 provides temporary storage of assets provided through interface L.
상기 서비스 리포팅부(1071)는 서비스 관련 메트릭스(service-related metrics) (예를 들어, telemetry and analytics 데이터)를 인터페이스 Rs를 통해 서비스 리포팅 캡쳐부(1061)로 리포팅한다.The service reporting unit 1071 reports service-related metrics (eg, telemetry and analytics data) to the service reporting capture unit 1061 through the interface Rs.
상기 네트워크 콘트롤러(1063)는 네트워크 리소스들을 콘트롤하고, 구성(configuration)하고, 프로비져닝(provisioning)한다. 이 네트워크 리소스들은 멀티캐스트 전송을 위한 리소스들과 유니캐스트 전송을 위한 리소스들을 포함한다. 상기 네트워크 콘트롤러(1063)는 이용가능한(available) 멀티캐스트 스트림들에 관한 configuration 정보를 네트워크 리소스들로 분배(distribute)한다. 또한 이 configuration 정보를 레퍼런스 포인트 CMS를 통해 멀티캐스트 서버(1050)로 분배하거나 및/또는 레퍼런스 포인트 CMR를 통해 멀티캐스트 게이트웨이(1070)로 분배할 수 있다. 상기 이용가능한(available) 멀티캐스트 스트림들에 관한 configuration 정보는 컨텐트 프로바이더 콘트롤러(1020) 및/또는 클라이언트 요청들의 수에 따라 업데이트될 수 있다.The network controller 1063 controls, configures, and provisions network resources. These network resources include resources for multicast transmission and resources for unicast transmission. The network controller 1063 distributes configuration information about available multicast streams to network resources. In addition, the configuration information may be distributed to the multicast server 1050 through the reference point C MS and / or to the multicast gateway 1070 through the reference point C MR . The configuration information about the available multicast streams may be updated according to the number of content provider controllers 1020 and / or client requests.
상기 컨텐트 재생부(1080)는 콘텐트를 요청, 수신, 디크립션, 프리젠테이션하는 entity managing이다. The content reproduction unit 1080 is an entity managing for requesting, receiving, decrypting, and presenting content.
상기 컨텐트 재생부(1080)는 스마트 폰과 같은 엔드 디바이스 상에서 상기 멀티캐스트 게이트웨이(1070)와 분리되어 위치될 수도 있다. 또한 셋톱 박스나 커넥티드(connected) TV 셋트에서 상기 컨텐트 재생부(1080)는 상기 멀티캐스트 게이트웨이(1070)와 결합될 수도 있다.The content playback unit 1080 may be located separately from the multicast gateway 1070 on an end device such as a smart phone. In addition, the content playback unit 1080 may be combined with the multicast gateway 1070 in a set-top box or a connected TV set.
상기 컨텐트 언패키징부(1083)는 retrieve된 전송 오브젝트(transport object)로부터 엘레멘터리 스트림 데이터(elementary stream data)를 추출하여 컨텐트 디코딩부(1085)나 컨텐트 디크립션부(1087)로 제공한다. 예를 들어, ISO Base Media File Format segments에 대해서는 media data box(es)를 추출하고, MPEG-2 Transport Streams에 대해서는, 재구성된 PES의 페이로드들을 추출한다.The content unpackaging unit 1083 extracts elementary stream data from the retrieved transport object and provides the extracted elementary stream data to the content decoding unit 1085 or the content decryption unit 1087. For example, media data box (es) is extracted for ISO Base Media File Format segments, and payloads of reconstructed PES are extracted for MPEG-2 Transport Streams.
상기 컨텐트 디코딩부(1085)는 엘레먼터리 미디어 스트림들의 컨텐트들을 파싱하고 해석(interpret)하며, 스크린이나 스피커 상에서 재생을 위해 렌더링되게 한다.The content decoding unit 1085 parses and interprets the contents of the elementary media streams and renders them for playback on a screen or speaker.
특히 상기 컨텐트 디코딩부(1085)는 복수개의 디코딩 디바이스(Decoding device)를 포함할 수 있으며, 복수의 디코딩 디바이스들은 멀티캐스트 게이트웨이(1070)에 동시에 접속할 수 있다. 각 디코딩 디바이스는 유니캐스트 또는 멀티캐스트를 통해 멀티캐스트 게이트웨이(1070)와 데이터를 송수신 할 수 있다. 즉, 디코딩 디바이스는 멀티캐스트 스트림을 수신하는 멀티캐스트 네트워크 외에도 유니캐스트 스트림을 수신하는 유니캐스트 네트워크에 접속할 수 있다. 상기 어플리케이션(1097)는 상기 컨텐트 재생부(1080)를 콘트롤한다. 상기 어플리케이션은 integrated 텔레비전 또는 셋톱 박스 상에서 임베디드된 콘트롤 어플리케이션(예를 들어, EPG 어플리케이션)이나 컨텐트 프로바이더에 의해 제공되는 제3 어플리케이션을 포함할 수 있다.In particular, the content decoding unit 1085 may include a plurality of decoding devices, and the plurality of decoding devices may simultaneously access the multicast gateway 1070. Each decoding device may transmit and receive data with the multicast gateway 1070 through unicast or multicast. That is, the decoding device may connect to a unicast network that receives a unicast stream in addition to the multicast network that receives the multicast stream. The application 1097 controls the content playback unit 1080. The application may include a control application (eg, an EPG application) embedded on an integrated television or set top box or a third application provided by a content provider.
상기 어플리케이션(1097)은 리니어 서비스들의 존재 여부를 디스커버리하고 멀티캐스트 게이트웨이(1070)에 의해 그들의 수신을 제어하기 위해 상기 멀티캐스트 게이트웨이(1070)의 서비스 매니지먼트부(1072)와 상호 작용한다.The application 1097 interacts with the service management portion 1072 of the multicast gateway 1070 to discover the existence of linear services and to control their reception by the multicast gateway 1070.
다음은 ABR 서비스 수신 과정의 일 실시예이다. 먼저, 컨텐트 재생부(1080)는 인터페이스 B인 부트스트랩을 통해 매니페스트를 수신한다. 상기 매니페스트를 수신한 컨텐트 재생부(1080)는 상기 멀티캐스트 게이트웨이(1070)의 정보(예를 들어, IP 주소, hostname)를 담고 있는 매니페스트 내 정보를 기반으로 멀티캐스트 게이트웨이(1070)에게 특정 미디어 세그먼트의 URL를 전송하여 그 URL에 대응하는 미디어 세그먼트를 요청한다. 상기 멀티캐스트 게이트웨이(1070)는 상기 멀티캐스트 서버(1050)로부터 제공받아 저장된 미디어 세그먼트들 중 상기 컨텐트 재생부(1080)에서 요청한 미디어 세그먼트를 찾아 상기 컨텐트 재생부(1080)로 제공한다.The following is an embodiment of a process of receiving an ABR service. First, the content playback unit 1080 receives a manifest through a bootstrap, which is an interface B. The content playback unit 1080 receiving the manifest sends a specific media segment to the multicast gateway 1070 based on the information in the manifest that contains the information (for example, IP address, hostname) of the multicast gateway 1070. Send a URL to request the media segment corresponding to that URL. The multicast gateway 1070 finds a media segment requested by the content playback unit 1080 among the stored media segments received from the multicast server 1050 and provides the media segment to the content playback unit 1080.
이와 같이, 상기 컨텐트 재생부(1080)는 매니페스트를 수신하면, DASH 모델에 따라 적절한 품질(Quality)의 representation을 선택한 후, 해당 미디어 세그먼트의 URL을 멀티캐스트 게이트웨이(1070)로 전송하고, 상기 멀티캐스트 게이트웨이(1070)로부터 상기 URL에 대응하는 미디어 세그먼트를 수신한다.As such, when the content playback unit 1080 receives the manifest, the content playback unit 1080 selects a representation of an appropriate quality according to the DASH model, and then transmits the URL of the media segment to the multicast gateway 1070. Receive a media segment corresponding to the URL from gateway 1070.
즉, 상기 컨텐트 재생부(1080)는 매니페스트 내 segment template에 따라 상기 멀티캐스트 게이트웨이(1070)로부터 해당 미디어 세그먼트를 포함하는 representation를 수신한다. 그런데, 특정 서비스 (예를 들어, 리니어 서비스)를 멀티캐스트로 전송할 때, 멀티캐스트는 상기 서비스를 1대 다의 형태로 전송하기 때문에 해당 representation의 수신이 용이하지 못한 경우가 발생할 수 있으며, 이때는 다른 representation의 선택이 필요하다. That is, the content playback unit 1080 receives a representation including the media segment from the multicast gateway 1070 according to the segment template in the manifest. However, when transmitting a specific service (for example, a linear service) by multicast, it may not be easy to receive the representation because the multicast transmits the service in one-to-many form. The choice of representation is necessary.
이를 위해, 본 발명은 서비스를 다른 딜리버리 패스 (delivery path) 예를 들어, 멀티캐스트로 전송함과 동시에 유니캐스트로 전송하는 것을 일 실시예로 한다. 예를 들어, 멀티캐스트로 전송되는 해당 representation의 수신이 용이하지 못하면, 상기 컨텐트 재생부(1080)는 유니캐스트로 전송되는 representation를 선택하여 서비스할 수 있다. 본 발명은 설명의 편의를 위해, 멀티캐스트를 제1 딜리버리 패스(또는 제1 딜리버리 방법)라 칭하고, 유니캐스트를 제2 딜리버리 패스 (또는 제2 딜리버리 방법)라 칭하며, 그 반대도 가능하다. 이에 더하여, 브로드캐스트를 제3 딜리버리 패스(또는 제3 딜리버리 방법)라 칭하기로 한다.To this end, according to an embodiment of the present invention, the service is transmitted in another delivery path, for example, in multicast and simultaneously in unicast. For example, if it is not easy to receive the corresponding representation transmitted in multicast, the content playback unit 1080 may select and service the representation transmitted in unicast. For convenience of description, the present invention refers to multicast as a first delivery pass (or first delivery method), unicast as a second delivery pass (or second delivery method), and vice versa. In addition, the broadcast will be referred to as a third delivery pass (or third delivery method).
그런데, 현재 매니페스트에서는 미디어 세그먼트에 접근 가능한 URL은 하나만 정의하고 있기 때문에, 상기 컨텐트 재생부(1080)에서는 선택된 representation에 포함된 미디어 세그먼트의 URL이 ABR을 지원하는 프로토콜이 인캡슐레이션되어 있는 멀티캐스트 게이트웨이(1070) 내 세그먼트의 URL인지 특정 서버의 유니캐스트를 위한 HTTP URL인지를 식별할 수 없다. However, in the current manifest, since only one URL accessible to the media segment is defined, in the content playback unit 1080, the multicast gateway in which the URL of the media segment included in the selected representation supports ABR is encapsulated. It is not possible to identify whether the URL is a segment of my segment or an HTTP URL for unicast of a particular server.
예를 들어, 멀티캐스트 서비스의 세그먼트 url의 경로가 만료되거나, available한 상태가 아닐 시에, 컨텐트 재생부(1080)에서는 round the side 의 형태로 요청하고 새로운 유니캐스트 서비스의 미디어 세그먼트 url을 받아와야 하는 과정이 필요하다. 이 과정은 live 시에는 서비스 black out 이슈가 발생할 수 있으며, latency의 증가를 유발할 수 있다. 또한 live 서비스시, 멀티캐스트 프로토콜과 유니캐스트 프로토콜이 다르기 때문에 다른 파싱 과정과 capacity에 고려한 다른 버퍼 관리를 수행하고, 이러한 이유로 딜리버리 경로의 구분은 중요하다. 또한 터널 안이나, 트래픽의 이슈로 미디어 세그먼트 손실이 발생 시, repair 를 할 수 있도록 인터페이스 M` 를 통해 멀티캐스트 형태로 데이터를 전달하고, 유니캐스트 리페어부(1095)에서는 데이터를 수신하여 멀티캐스트 게이트웨이(1070)와 유니캐스트 요청 형태로 손실된 미디어 세그먼트를 수신 받을 수 있다. 이때 상기 멀티캐스트 게이트웨이(1070)는 유니캐스트 경로를 통해 미디어 세그먼트를 수신 받아 처리해야 하는 동작이므로, 기존 멀티캐스트의 세그먼트 정보와는 구별 될 필요성이 있다.For example, when the path of the segment url of the multicast service expires or is not available, the content playback unit 1080 requests in the form of round the side and receives the media segment url of the new unicast service. The process is necessary. This process may cause a service black out issue during live, and may cause an increase in latency. In the live service, since the multicast protocol and the unicast protocol are different, different buffer management considering different parsing process and capacity is performed. For this reason, it is important to distinguish the delivery path. Also, in case of media segment loss caused by tunnel or traffic issue, data is delivered in multicast form through interface M`, and the unicast repair unit 1095 receives the data and receives the multicast gateway. 1070 and the lost media segment may be received in the form of a unicast request. In this case, since the multicast gateway 1070 needs to receive and process a media segment through a unicast path, the multicast gateway 1070 needs to be distinguished from segment information of the existing multicast.
따라서, 본 발명은 이를 해결하기 위해, 멀티캐스트로 전송되는 세그먼트의 URL과 유니캐스트로 전송되는 세그먼트의 URL을 식별하는 방법을 제안한다.Accordingly, to solve this problem, the present invention proposes a method of identifying the URL of a segment transmitted by multicast and the URL of a segment transmitted by unicast.
즉, 도 20의 MPD의 각 representation에는 세그먼트별로 baseurl을 두어, 세그먼트를 획득하는 기초가 되는 스트링을 정의한다. That is, each representation of the MPD of FIG. 20 has a baseurl for each segment to define a string that is the basis for obtaining the segment.
본 발명은 딜리버리 방법에 따라 baseurl을 manipulation함으로써, 해당 representation를 어느 딜리버리 패스로 요청해야 하는지를 알 수 있도록 한다. According to the present invention, the baseurl is manipulated according to a delivery method, so that the delivery path is known to which delivery path should be requested.
도 24는 본 발명에 따른 멀티캐스트 ABR delivery method에 따라 baseurl을 정의한 일 실시예이다. 도 24에서 정의된 delivery method별 baseurl은 프로비져닝부(1060)의 네트워크 콘트롤러(1063)에서 제공되는 콘트롤 메시지에 포함되어 멀티캐스트 게이트웨이(1070)의 서비스 매니지먼트부(1072)로 제공되는 것을 일 실시예로 한다. 상기 멀티캐스트 게이트웨이(1070)의 서비스 매니지먼트부(1072)는 상기 네트워크 콘트롤러(1063)의 콘트롤 메시지에 포함되어 제공되는 baseurl로 미리 저장된 MPD의 baseurl을 업데이트한다.24 illustrates an embodiment of defining a baseurl according to the multicast ABR delivery method according to the present invention. In one embodiment, the baseurl for each delivery method defined in FIG. 24 is included in a control message provided from the network controller 1063 of the provisioning unit 1060 and provided to the service management unit 1072 of the multicast gateway 1070. do. The service management unit 1072 of the multicast gateway 1070 updates the baseurl of the MPD stored in advance with the baseurl provided in the control message of the network controller 1063.
이때, IP 기반 미디어 서비스는 멀티캐스트와 유니캐스트 중 어느 하나로 제공될 수도 있지만, 멀티캐스트와 유니캐스트로 동시에 제공될 수도 있다. 미디어 서비스가 멀티캐스트와 유니캐스트 중 어느 하나로 제공되는 경우에는 해당 delivery method에 따른 baseurl만 네트워크 콘트롤러(1063)에서 제공되고, 미디어 서비스가 멀티캐스트와 유니캐스트로 동시에 제공될 경우에는 멀티캐스트에 따른 baseurl과 유니캐스트에 따른 baseurl이 네트워크 콘트롤러(1063)에서 함께 제공될 수 있다.In this case, the IP-based media service may be provided in one of multicast and unicast, but may be simultaneously provided in multicast and unicast. When the media service is provided in one of multicast and unicast, only the baseurl according to the corresponding delivery method is provided by the network controller 1063. When the media service is simultaneously provided in both multicast and unicast, the baseurl according to multicast is provided. And a baseurl according to unicast may be provided together in the network controller 1063.
만일, 네트워크 콘트롤러(1063)로부터 멀티캐스트로 전송되는 미디어 세그먼트의 baseurl과 유니캐스트로 전송되는 미디어 세그먼트의 baseurl이 동시에 제공된다면, MPD는 멀티캐스트로 전송되는 미디어 세그먼트의 baseurl를 포함하는 representation과 유니캐스트로 전송되는 미디어 세그먼트의 baseurl를 포함하는 representation을 각각 포함할 수 있다.If the baseurl of the media segment transmitted in multicast from the network controller 1063 and the baseurl of the media segment transmitted in unicast are provided at the same time, the MPD is a representation and unicast including the baseurl of the media segment transmitted in multicast Each may include a representation including the baseurl of the media segment transmitted to.
상기 멀티캐스트 게이트웨이(1070)는 도 24의 구성을 기반으로 base string pattern을 만들고, base URL 과 segment template를 통해 미디어 세그먼트를 접근할 수 있는 주소를 만들어 낸다.The multicast gateway 1070 creates a base string pattern based on the configuration of FIG. 24 and generates an address for accessing a media segment through a base URL and a segment template.
도 25는 본 발명에 따른 MPD에 포함되는 baseurl의 실시예들을 보인 것으로서, 컨텐트 재생부(1080)에서 선택된 representation에 포함된 미디어 세그먼트의 baseurl이 도 25의 a와 같으면, 멀티캐스트로 전송되는 representation이라고 판단하고, 멀티캐스트로 전송되는 미디어 세그먼트를 요청한다. 다른 예로, 컨텐트 재생부(1080)에서 선택된 representation에 포함된 미디어 세그먼트의 baseurl이 도 25의 b와 같으면, 유니캐스트로 전송되는 representation이라고 판단하고, 유니캐스트로 전송되는 미디어 세그먼트를 요청한다.FIG. 25 illustrates embodiments of a baseurl included in an MPD according to the present invention. If the baseurl of a media segment included in the representation selected by the content playback unit 1080 is the same as a in FIG. 25, the representation is transmitted by multicast. Determine and request a media segment to be transmitted in multicast. As another example, if the baseurl of the media segment included in the representation selected by the content playback unit 1080 is the same as that of b of FIG. 25, it is determined that the representation is transmitted in unicast, and the media segment transmitted in unicast is requested.
이와 같이 base pattern을 통해 매니페스트를 manipulation 하고, delivery path에 따라 구별 가능한 base string을 기반으로 미디어 세그먼트를 요청한다. In this way, the manifest is manipulated through the base pattern, and the media segment is requested based on the base string that can be distinguished according to the delivery path.
지금까지 설명한 것처럼, 본 발명은 IP 기반 미디어 서비스 제공 시, 유니캐스트 기반 서비스와 패킷 트래픽을 분산 시킬 수 있는 멀티캐스트 기반 서비스를 동시에 제공할 수 있다. 이렇게 함으로써, 데이터 대역폭을 더 넓게 사용할 수 있는 장점이 있다.As described so far, the present invention can simultaneously provide a unicast-based service and a multicast-based service capable of distributing packet traffic when providing an IP-based media service. This has the advantage of allowing greater use of data bandwidth.
이때 ABR 스트리밍 서비스를 제공하기 위한 매니페스트 파일 (즉, MPD 파일) 내 delivery method를 구분할 수 있는 방법을 설명하였다. 즉, 본 발명은 기존의 매니페스트의 구조는 변경하지 않고, baseURL을 통한 delivery method를 정의하여 기존 ABR 서비스에 호환 가능한 방법을 제공한다. In this case, a method of distinguishing a delivery method in a manifest file (ie, an MPD file) for providing an ABR streaming service has been described. That is, the present invention provides a method compatible with the existing ABR service by defining a delivery method through baseURL without changing the structure of the existing manifest.
도 26은 본 발명에 따른 네트워크 콘트롤러(1063)에서 인터페이스 CMR를 이용하여 멀티캐스트 게이트웨이(1070)로 제공하는 콘트롤 메시지 (또는 멀티캐스트 네트워크 콘트롤 메시지)의 시맨틱스(semantics)의 일 실시예를 보이고 있다. 상기 콘트롤 메시지는 XML (eXtensible Markup Language) 포맷이거나 및/또는 HTTP restful API message 포맷일 수 있다. 본 발명에서 ABR 멀티캐스트 서비스를 제공하기 위한 콘트롤 메시지는 HTTP restful API message 형태인 것을 일 실시예로 한다. 상기 콘트롤 메시지는 CMS와 CMR 등 콘트롤 메시지 전달이 가능한 인터페이스를 통해 전달이 가능하다. 그리고 상기 콘트롤 메시지는 서비스 프로바이더/인터넷 서비스 프로바이더의 정보처리상호운영(interoperability)과 리니어 네트워크 환경을 고려하여 서비스 초기화를 위한 메니페스트 정보(예를 들면, MPD)를 발생시킬 수 있다.FIG. 26 shows an embodiment of the semantics of a control message (or multicast network control message) provided by the network controller 1063 to the multicast gateway 1070 using the interface C MR in accordance with the present invention. have. The control message may be in XML (eXtensible Markup Language) format and / or HTTP restful API message format. According to an embodiment of the present invention, a control message for providing an ABR multicast service is in the form of an HTTP restful API message. The control message is C MS and C MR It can be delivered through an interface that can transmit control messages. The control message may generate manifest information (eg, MPD) for service initialization in consideration of information processing interoperability of the service provider / Internet service provider and a linear network environment.
도 26을 보면, 딜리버리 콘트롤은 하위 엘레먼트로 @sIPaddr 엘레먼트, @dIPaddr 엘레먼트, @dport 엘레먼트, @serviceId 엘레먼트, deliverymethod 엘레먼트를 포함할 수 있다.Referring to FIG. 26, the delivery control may include an @sIPaddr element, an @dIPaddr element, an @dport element, an @serviceId element, and a deliverymethod element as lower elements.
상기 @sIPaddr 엘레먼트는 미디어 서비스를 전송하는 멀티캐스트 세션(예를 들어, ROUTE 세션)의 소스 IP 어드레스를 지시한다. The @sIPaddr element indicates a source IP address of a multicast session (eg, a ROUTE session) carrying a media service.
상기 @dIPaddr 엘레먼트는 미디어 서비스를 전송하는 멀티캐스트 세션의 destination IP 어드레스를 지시한다. The @dIPaddr element indicates a destination IP address of a multicast session for transmitting a media service.
상기 @dport 엘레먼트는 미디어 서비스를 전송하는 멀티캐스트 세션의 destination port number를 지시한다. The @dport element indicates a destination port number of a multicast session for transmitting a media service.
상기 @serviceId 엘레먼트는 미디어 서비스를 식별하기 위한 것으로서, service entry, adaptation-set@id, MPD@id 중 하나가 될 수 있다.The @serviceId element is used to identify a media service and may be one of a service entry, adaptation-set @ id, and MPD @ id.
상기 deliverymethod 엘레먼트는 액세스의 멀티캐스트 또는 유니캐스트 모드 상에서 미디어 서비스의 컨텐트에 속하는 전송 관련된 정보의 컨테이너일 수 있다. 상기 deliverymethod 엘레멘트는 multicast_service 엘레멘트 및/또는 unicast_service 엘레멘트를 포함할 수 있다. 이 엘레멘트들은 각각 basepattern 엘레멘트와 priority 엘레먼트를 하위 엘레멘트로 가질 수 있다. The deliverymethod element may be a container of delivery related information belonging to the content of the media service on the multicast or unicast mode of access. The deliverymethod element may include a multicast_service element and / or a unicast_service element. Each of these elements may have a basepattern element and a priority element as subelements.
상기 multicast_service 엘레멘트는 멀티캐스트 서비스에 속하는 해당 미디어 컴포넌트(들)를 포함하는 멀티캐스트 상에서 딜리버리되는 DASH representation일 수 있다. 즉, 각각의 본 필드들은 멀티캐스트를 통해 전달되는 DASH representation들을 의미할 수 있다.The multicast_service element may be a DASH representation delivered on a multicast including corresponding media component (s) belonging to a multicast service. That is, each of the present fields may refer to DASH representations delivered through multicast.
상기 multicast_service 엘레멘트의 하위 엘레먼트인 basepattern 엘레멘트는 멀티캐스트 ABR 수신기가 DASH 클라이언트에 의해 사용된 세그먼트 URL 과 매칭하는데 사용되는 캐릭터 패턴을 나타낼 수 있다. 이는 DASH 클라이언트가 parent DASH representation의 DASH 미디어 세그먼트들을 요청하는데 사용될 수 있다. 매칭된다는 것은 해당 DASH 미디어 세그먼트가 멀티캐스트를 통해 전달된다는 것을 암시할 수 있다. The basepattern element, which is a sub-element of the multicast_service element, may indicate a character pattern used by the multicast ABR receiver to match the segment URL used by the DASH client. This can be used by the DASH client to request DASH media segments of the parent DASH representation. Matching may imply that the corresponding DASH media segment is delivered via multicast.
상기 multicast_service 엘레멘트의 하위 엘레먼트인 priority 엘레멘트는 멀티캐스트 서비스를 제공하기 위해 네트워크와 캐패시터를 고려한 DASH representation delivery의 우선 순위를 나타낸다.The priority element, which is a lower element of the multicast_service element, indicates the priority of the DASH representation delivery considering the network and the capacitor in order to provide a multicast service.
상기 unicast_service 엘레멘트는 유니캐스트 서비스에 속하는 해당 미디어 컴포넌트(들)를 포함하는 유니캐스트 상에서 딜리버리되는 DASH representation일 수 있다. 즉, 각각의 본 필드들은 유니캐스트를 통해 전달되는 DASH representation들을 의미할 수 있다.The unicast_service element may be a DASH representation delivered on unicast including corresponding media component (s) belonging to a unicast service. That is, each of the present fields may mean DASH representations transmitted through unicast.
상기 unicast_service 엘레멘트의 하위 엘레먼트인 basepattern 엘레멘트는 멀티캐스트 ABR 수신기가 DASH 클라이언트에 의해 사용된 세그먼트 URL 과 매칭하는데 사용되는 캐릭터 패턴을 나타낼 수 있다. 이는 DASH 클라이언트가 parent DASH representation의 DASH 미디어 세그먼트들을 요청하는데 사용될 수 있다. 매칭된다는 것은 해당 DASH 미디어 세그먼트가 유니캐스트를 통해 전달된다는 것을 암시할 수 있다. The basepattern element, which is a sub-element of the unicast_service element, may indicate a character pattern used by the multicast ABR receiver to match the segment URL used by the DASH client. This can be used by the DASH client to request DASH media segments of the parent DASH representation. Matching may imply that the corresponding DASH media segment is delivered via unicast.
상기 unicast_service 엘레멘트의 하위 엘레먼트인 priority 엘레멘트는 유니캐스트 서비스를 제공하기 위해 네트워크와 캐패시터를 고려한 DASH representation delivery의 우선 순위를 나타낸다.The priority element, which is a lower element of the unicast_service element, indicates the priority of the DASH representation delivery considering the network and the capacitor to provide the unicast service.
도 27은 deliverymethod 엘레멘트에 broadcast_service 엘레먼트가 하위 엘레먼트로 포함되고, broadcast_service 엘레먼트에 basepattern 엘레먼트와 priority 엘레먼트가 하위 엘레먼트로 포함되는 것을 제외하고 도 26과 동일하다. 그러므로, 각 엘레먼트의 설명은 도 26을 참조하기로 하고, 여기서는 생략하기로 한다.FIG. 27 is the same as FIG. 26 except that the broadcast_service element is included as a lower element in the deliverymethod element and the basepattern element and the priority element are included as the lower element in the broadcast_service element. Therefore, description of each element will be referred to FIG. 26 and will be omitted here.
도 26 또는 도 27과 같은 콘트롤 메시지는 주기적으로 또는 시맨틱스 내 데이터가 업데이트될 때마다 멀티캐스트 게이트웨이(1070)로 제공될 수 있다. 또는 상기 콘트롤 메시지를 미리 멀티캐스트 게이트웨이(1070)로 전달하여, 멀티캐스트 게이트웨이(1070)의 operation을 적응적으로 대응할 수 있다. 즉, 상기 콘트롤 메시지에 포함된 멀티캐스트 경로의 스트링과 유니캐스트 경로의 스트링을 미리 멀티캐스트 게이트웨이(1070)로 전달하여, 서비스 시작 시 MPD가 전달 되면 상기 string 들의 경로를 통해 멀티캐스트 게이트웨이(1070)의 operation을 적응적으로 대응할 수 있다. 26 or 27 may be provided to the multicast gateway 1070 periodically or whenever data in the semantics is updated. Alternatively, the control message may be transmitted to the multicast gateway 1070 in advance to adaptively correspond to the operation of the multicast gateway 1070. That is, the string of the multicast path and the string of the unicast path included in the control message are delivered to the multicast gateway 1070 in advance. When the MPD is delivered at the start of the service, the multicast gateway 1070 is transmitted through the path of the strings. It can adaptively cope with the operation of.
본 발명은 스트링에 따른 delivery method 를 구분하기 위해, 즉, 매니페스트 파일에 정의되는 스트링을 인식하기 위해 네트워크 콘트롤러(1063)는 도 26 또는 도 27과 같은 콘트롤 메시지를 미디어 세그먼트가 멀티캐스트 게이트웨이(1070)로 전송되기 전에 상기 멀티캐스트 게이트웨이(1070)로 전송하는 것을 일 실시예로 한다. 상기 미디어 세그먼트는 멀티캐스트 서버(1050)에서 멀티캐스트 게이트웨이(1070)로 전송된다. According to the present invention, in order to distinguish delivery methods according to strings, that is, to recognize strings defined in a manifest file, the network controller 1063 may transmit a control message as shown in FIG. 26 or FIG. 27 to the multicast gateway 1070. According to an embodiment of the present invention, the multicast gateway 1070 transmits the data to the multicast gateway 1070 before being transmitted. The media segment is sent from the multicast server 1050 to the multicast gateway 1070.
도 26 또는 도 27에 포함된 스트링은 다른 실시예로, 3GPP에서 사용하는 SDP, DVB IPTV의 STP, 또는 3rd party의 주기적인 configuration 정보에 포함되어 상기 멀티캐스트 게이트웨이(1070)로 전달될 수도 있다.26 or a string included in Fig. 27 in another embodiment, is included in the periodic configuration information of the SDP, DVB IPTV used by the 3GPP STP, or a 3 rd party may be transmitted to the multicast gateway 1070 .
본 발명은 네트워크 콘트롤러(1063)에서 콘트롤 메시지에 포함하여 상기 멀티캐스트 게이트웨이(1070)로 전달하는 것을 일 실시예로 설명한다.The present invention will be described in one embodiment by the network controller 1063 to be included in the control message to the multicast gateway 1070.
상기 네트워크 콘트롤러(1063)는 상기 멀티캐스트 게이트웨이(1070)를 통해 서비스의 대한 획득(acquisition), 초기화(initialization)등의 서비스 쿼리 또는 콘트롤 메시지를 전송하여 상기 멀티캐스트 게이트웨이(1070)의 동작을 제어할 수 있다.The network controller 1063 may control the operation of the multicast gateway 1070 by transmitting a service query or control message such as acquisition, initialization, etc. of a service through the multicast gateway 1070. Can be.
즉, 상기 네트워크 콘트롤러(1063)는 인터페이스 CMR를 이용하여 멀티캐스트 서버(1050)에서 전송하는 미디어 서비스를 콘트롤하는 콘트롤 메시지를 전송할 수 있다. 멀티캐스트 미디어를 전송하는 인터페이스 M의 특정 멀티캐스트 세션에 콘트롤 메시지가 포함되지 않고, 외부 ISP 관리 망이나, 네트워크 사업자가 지정한 멀티캐스트 서비스 콘트롤러에서 멀티캐스트 플로우를 콘트롤 하기 위해서는 도 26 또는 도 27과 같은 접근 정보가 필요하다. 해당 멀티캐스트 세션의 IP와 port로서 접근이 가능하고, 전송되는 매니페스트 내 컴포넌트/어댑테이션 (component/adaptation) 식별 정보, MPD 식별 정보, 서비스 엔트리 식별 정보 중 적어도 하나를 통해, 미디어 representation 에 정의된 segment URL 의 스트링에 접근이 가능하다. 접근 후 멀티캐스트/유니캐스트 서비스를 구별하는 base pattern과 매니페스트 파일 내 base URL을 매칭하여 미디어 세그먼트가 어떤 경로로 서비스가 가능한지 여부를 알 수 있다. 다시 말해, ABR을 지원하는 프로토콜이 인캡슐레이션되어 있는 멀티캐스트 게이트웨이(1070) 내 세그먼트의 URL인지 특정 서버의 유니캐스트를 위한 HTTP URL인지를 식별할 수 있게 된다. That is, the network controller 1063 may transmit a control message for controlling a media service transmitted from the multicast server 1050 using the interface C MR . In order to control a multicast flow in a specific multicast session of interface M that transmits multicast media and does not include a control message and is controlled by an external ISP management network or a multicast service controller designated by a network operator, as shown in FIG. 26 or 27. Access information is required. The segment URL defined in the media representation is accessible as an IP and a port of the corresponding multicast session, and can be accessed through at least one of component / adaptation identification information, MPD identification information, and service entry identification information in a transmitted manifest. Access to strings is possible. After access, the base pattern distinguishing the multicast / unicast service and the base URL in the manifest file can be matched to find out which path the media segment can serve. In other words, it is possible to identify whether the protocol supporting ABR is the URL of a segment in the encapsulated multicast gateway 1070 or an HTTP URL for unicast of a specific server.
또한 delivery method를 정의하여 적절한 수신기 동작을 구현하고, round the site 를 하지 않고 바로 서비스 전환이 가능하도록 할 수 있다. 또한 priority 정보로 현재 인터페이스 M과 멀티캐스트 게이트웨이(1070)에서 미디어 세그먼트 캐패시터를 고려한 멀티캐스트/유니캐스트 경로의 우선 순위(priority)를 정의하여 끊김없는(seamless) 서비스를 구현할 수 있다. 또한 손실된 패킷을 유니캐스트로 수신해야 할 때 멀티캐스트 미디어 세그먼트와 aligned 되어 현재 플레이아웃 타임(playout time)에 맞는 손실된 패킷을 요청할 수 있다. 다시 말해, 네트워크 콘트롤러(1063)에서는 콘트롤 메시지에 멀티캐스트 경로 정보와 유니캐스트 경로 정보를 모두 포함시켜 멀티캐스트 게이트웨이(1070)로 전달하여 MPD의 멀티캐스트 서비스 정보와 유니캐스트 서비스 정보를 주기적으로 업데이트해줌으로써, 멀티캐스트 서비스에서 유니캐스트 서비스로 전환시 또는 그 반대의 경우에 서비스 전환 시간을 줄일 수 있다. 또한 멀티캐스트 서비스와 유니캐스트 서비스가 동시에 존재할 때, priority 엘레먼트에 의해 우선 순위를 설정할 수 있다.In addition, the delivery method can be defined to implement proper receiver operation and to be able to switch services immediately without rounding the site. In addition, the priority information may define a priority of the multicast / unicast path considering the media segment capacitor in the current interface M and the multicast gateway 1070 to implement a seamless service. When a lost packet must be received unicast, it can be aligned with the multicast media segment to request a lost packet that matches the current playout time. In other words, the network controller 1063 includes both the multicast route information and the unicast route information in the control message and delivers the multicast gateway information to the multicast gateway 1070 to periodically update the multicast service information and the unicast service information of the MPD. In this case, the service switching time can be reduced when switching from a multicast service to a unicast service or vice versa. In addition, when a multicast service and a unicast service exist at the same time, priority can be set by the priority element.
한편, 상기 멀티캐스트 게이트웨이(1070)가 프록시 서버로 동작할 때, 상기 프록시 서버의 모드는 다양한 동작 모드를 구성할 수 있다.On the other hand, when the multicast gateway 1070 operates as a proxy server, the mode of the proxy server may configure various operation modes.
본 발명에서 상기 멀티캐스트 게이트웨이(1070)는 인-게이트웨이 트랜스페어런트 프록시 (In-gateway transparent proxy) 모드, 인-게이트웨이 포워드 프록시 (In-gateway forward proxy) 모드, reverse proxy를 갖는 인-게이트웨이 DNS redirection (In-gateway DNS redirection with reverse proxy) 모드, 스티키 HTTP redirection + reverse proxy (Sticky HTTP redirection plus reverse proxy) 모드, Manipulation of URLs in manifest plus reverse proxy 모드 중 어느 하나로 구성될 수 있다. 이때 상기 멀티캐스트 게이트웨이(1070)는 프록시 모드에 따라 홈 게이트웨이(home gateway) 나 IP 셋톱박스(STB)로 구성 될 수도 있고, 네트워크 게이트웨이에 위치하여, 컨텐트 재생부(1080, 즉 클라이언트)의 premises들과 연결이 가능하다. In the present invention, the multicast gateway 1070 may include an in-gateway transparent proxy mode, an in-gateway forward proxy mode, and an in-gateway DNS redirection (reverse proxy). In-gateway DNS redirection with reverse proxy mode, sticky HTTP redirection + reverse proxy (Sticky HTTP redirection plus reverse proxy) mode, Manipulation of URLs in manifest plus reverse proxy mode. In this case, the multicast gateway 1070 may be configured as a home gateway or an IP set-top box (STB) according to proxy mode, and located in a network gateway, premises of the content playback unit 1080 (that is, a client). It is possible to connect with.
도 28은 본 발명에 따른 멀티캐스트 게이트웨이(1070)가 프록시 서버로 동작할 때, 도 23의 시스템 아키텍쳐의 해당 부분을 간략히 도시한 것이다.28 is a simplified illustration of the corresponding portion of the system architecture of FIG. 23 when the multicast gateway 1070 according to the present invention operates as a proxy server.
도 28에서 유저 네트워크는 멀티캐스트 게이트웨이(1070)와 컨텐트 재생부(1080, 즉 클라이언트)를 포함할 수 있다. 상기 멀티캐스트 게이트웨이(1070)가 프록시 서버로 동작하고, 상기 프록시 모드가 In-gateway transparent proxy 모드이거나 In-gateway forward proxy 모드이면, 상기 멀티캐스트 게이트웨이(1070)는 홈 게이트웨이와 멀티캐스트 리시버로 구성될 수 있다. 상기 프록시 모드가 In-gateway DNS redirection with reverse proxy 모드이면, 상기 멀티캐스트 게이트웨이(1070)는 멀티캐스트 서버(1050)와 직접적으로 데이터를 주고받는 멀티캐스트 리시버를 포함하고, 상기 멀티캐스트 리시버는 로컬 DNS와 미디어 캐싱부로 구성될 수 있다. 즉, 상기 멀티캐스트 리시버가 유저 네트워크 내에 포함된 경우, 멀티캐스트 리시버는 유저 네트워크에 포함된 게이트웨이 (gateway) 또는 프록시 (proxy) 역할을 하는 장치를 통해 멀티캐스트 컨텐트를 수신 할 수 있다. 이러한 경우, 해당 게이트웨이 또는 프록시는 ABR 멀티캐스트 네트워크의 구성요소로써 간주될 수 있다. 상기 멀티캐스트 리시버는 유저 네트워크 내에서 서버 또는 멀티캐스트 센더의 역할을 수행할 수 있다. 이로 인해, 유저 네트워크에 포함된 디코딩 디바이스는 멀티캐스트 컨텐트를 소비할 수 있으며, 디코딩 디바이스가 멀티캐스트 컨텐트의 직접 수신이 불가한 경우에도 멀티캐스트 스트리밍이 가능하게 할 수 있다.In FIG. 28, the user network may include a multicast gateway 1070 and a content player 1080 (ie, a client). If the multicast gateway 1070 operates as a proxy server, and the proxy mode is an in-gateway transparent proxy mode or an in-gateway forward proxy mode, the multicast gateway 1070 may include a home gateway and a multicast receiver. Can be. If the proxy mode is In-gateway DNS redirection with reverse proxy mode, the multicast gateway 1070 includes a multicast receiver that directly exchanges data with the multicast server 1050, and the multicast receiver is a local DNS. And a media caching unit. That is, when the multicast receiver is included in the user network, the multicast receiver may receive multicast content through a device serving as a gateway or proxy included in the user network. In this case, the gateway or proxy may be considered as a component of the ABR multicast network. The multicast receiver may serve as a server or a multicast sender in a user network. As a result, 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.
본 발명에 따른 인-게이트웨이 트랜스페어런트 프록시 (In-gateway transparent proxy) 모드는 도 29에서와 같이 클라이언트(1080)가 타겟 서버(즉, 멀티캐스트 서버, 1050) 또는 컨텐트 호스팅부(1040)의 IP 정보를 기반으로 접속하는 방식으로, 멀티캐스트 서버(1050)의 접속 정보를 미리 알고 있는 모드이다. 즉, 멀티캐스트 서버 (1050) 또는 컨텐트 호스팅부(1040)의 IP 정보를 기반으로 접속하기 때문에 DNS 설정과 호스트 네임(host name)이 필요 없다. 이때 네트워크 콘트롤러(1063)는 인터페이스 CMR를 통해 서버 IP 정보를 미리 멀티캐스트 게이트웨이(1070)로 전달하는 것을 일 실시예로 한다. 또한 Multicast availability는 유니캐스트 응답(unicast response)으로 전달 된다. 상기 인-게이트웨이 트랜스페어런트 프록시 모드는 end to end 가 HTTP 커널로서 컨텐트 호스팅부(1040) 또는 멀티캐스트 서버(1050)와 연결되고, 통상적으로 셋톱박스(STB)나 TV 내 transparent mode 서버의 형태이다. 즉, 바이패스(By pass)의 형태로 단말과 컨텐트 호스팅부(1040, 즉 origin server)는 중간의 캐싱(caching)이 있는지 인식하지 못하고 작동하는 모드이다. In the in-gateway transparent proxy mode according to the present invention, as shown in FIG. 29, the client 1080 may include the IP information of the target server (ie, the multicast server 1050) or the content hosting unit 1040. In this manner, the access information of the multicast server 1050 is known in advance. That is, since the connection is based on the IP information of the multicast server 1050 or the content hosting unit 1040, DNS setting and a host name are not necessary. At this time, the network controller 1063 may transfer the server IP information to the multicast gateway 1070 in advance through the interface C MR . Multicast availability is also delivered in a unicast response. The in-gate transparent proxy mode is end to end connected to the content hosting unit 1040 or the multicast server 1050 as an HTTP kernel, and is typically in the form of a transparent mode server in a set-top box (STB) or TV. In other words, the terminal and the content hosting unit 1040 (that is, the origin server) in a bypass form do not recognize whether there is an intermediate caching.
다음은 본 발명에 따른 인-게이트웨이 트랜스페어런트 프록시 모드의 동작 예이다.The following is an example of operation of the in-gate transparent proxy mode according to the present invention.
1. Transparent HTTP proxy is (probably) co-located with multicast gateway (1070) in the home gateway or router device.1.Transparent HTTP proxy is (probably) co-located with multicast gateway (1070) in the home gateway or router device.
2. Client (1080) makes a GET request for manifest or media.2.Client (1080) makes a GET request for manifest or media.
3. Request intercepted by multicast gateway (1070) and compared with a list of URLs that are known to be available alternatively via multicast.3.Request intercepted by multicast gateway (1070) and compared with a list of URLs that are known to be available alternatively via multicast.
4. Multicast gateway (1070) lazily initiates a multicast session to start storing a local cache.4.Multicast gateway (1070) lazily initiates a multicast session to start storing a local cache.
5. In the meantime, any cache misses are proxied through multicast gateway (1070) to the upstream unicast origin via interface U.5.In the meantime, any cache misses are proxied through multicast gateway (1070) to the upstream unicast origin via interface U.
6. Doesn't really work when HTTPS comes into the picture because the unicast TLS session bypasses the transparent proxy since it is an end-to-end session.6.Doesn't really work when HTTPS comes into the picture because the unicast TLS session bypasses the transparent proxy since it is an end-to-end session.
본 발명에 따른 인-게이트웨이 포워드 프록시 (In-gateway forward proxy) 모드는 도 23의 멀티캐스트 게이트웨이(1070)가 포워드 동작을 한다. 상기 인-게이트웨이 포워드 프록시 모드도 마찬가지로 최종 타겟 서버인 멀티캐스트 서버(1050) 또는 컨텐트 호스팅부(1040)의 접속 IP정보를 모두 알고 접속하기 때문에 DNS의 설정이 필요 없다. 이때, 상기 인-게이트웨이 Transparent 프록시 모드와 동일하게 데이터 요청 시 접속하고자 하는 서버의 정체를 알지만, 상기 인-게이트웨이 포워드 프록시 모드는 도 30에서와 같이 해당 서버 즉, 멀티캐스트 게이트웨이(1070)로 요청을 중개한다. 예를 들어 클라이언트 설정은 proxy.com 이지만, 주소 창에는 target.com 이다. 즉, 모든 요청은 프록시 즉, 멀티캐스트 게이트웨이(1070)를 거쳐 최종 목적지에 전달된다. 따라서 상기 인-게이트웨이 포워드 프록시 모드는 오리진(origin)과의 사적 터널 커넥트(private tunnel CONNECT)의 연결이 미리 이루어 짐으로, 클라이언트(1080)와 멀티캐스트 게이트웨이(1070)는 HTTP 가 communication을 동작하지 않는다. 그리고 상기 인-게이트웨이 트랜스페어런트 프록시 모드와 동일하게 Multicast availability는 unicast response 로 전달 된다. In the in-gateway forward proxy mode according to the present invention, the multicast gateway 1070 of FIG. 23 performs a forward operation. Likewise, the in-gateway forward proxy mode knows and accesses all the access IP information of the multicast server 1050 or the content hosting unit 1040, which is the final target server, and thus does not require DNS setting. At this time, the same as the in-gateway transparent proxy mode, but knows the identity of the server to connect to the data request, the in-gateway forward proxy mode, as shown in Figure 30 to the server, that is, the multicast gateway 1070 Mediate. For example, the client setting is proxy.com, but target.com in the address bar. That is, all requests are forwarded to the final destination via a proxy, i.e., multicast gateway 1070. Accordingly, in the in-gateway forward proxy mode, since a private tunnel CONNECT connection with an origin is made in advance, the client 1080 and the multicast gateway 1070 do not operate HTTP communication. . The multicast availability is delivered in a unicast response as in the in-gate transparent proxy mode.
다음은 본 발명에 따른 인-게이트웨이 포워드 프록시 모드의 동작 예이다.The following is an example of operation of the in-gateway forward proxy mode according to the present invention.
1. Client (1080) is explicitly configured to use multicast gateway (1070) as a proxy for all (or some) of its HTTP(S) interactions.1.Client (1080) is explicitly configured to use multicast gateway (1070) as a proxy for all (or some) of its HTTP (S) interactions.
2. Client (1080) requests the manifest via multicast gateway (1070).2.Client (1080) requests the manifest via multicast gateway (1070).
3. Client (1080) requests media via multicast gateway (1070).Client (1080) requests media via multicast gateway (1070).
4. Request intercepted by multicast gateway (1070) and compared with a list of URLs that are known to be available alternatively via multicast.4.Request intercepted by multicast gateway (1070) and compared with a list of URLs that are known to be available alternatively via multicast.
5. Multicast gateway (1070) lazily initiates a multicast session to start storing a local cache.5.Multicast gateway (1070) lazily initiates a multicast session to start storing a local cache.
6. In the meantime, any cache misses are proxied through multicast gateway (1070) to the upstream unicast origin via interface U.6.In the meantime, any cache misses are proxied through multicast gateway (1070) to the upstream unicast origin via interface U.
7. In the HTTPS case, the client (1080) would use CONNECT to create a secure tunnel to the unicast source, and multicast gateway (1070) would be unable to see and intercept these requests/responses.7.In the HTTPS case, the client (1080) would use CONNECT to create a secure tunnel to the unicast source, and multicast gateway (1070) would be unable to see and intercept these requests / responses.
8. Doesn't work because the forward proxy is bypassed through the use of CONNECT to set up a private tunnel to the origin.8. Doesn't work because the forward proxy is bypassed through the use of CONNECT to set up a private tunnel to the origin.
본 발명에 따른 In-gateway DNS redirection with reverse proxy 모드에서 reverse proxy는 load balancing 또는 서비스 등의 목적을 가지고 물리/논리적으로 나뉜 서버들에게 요청을 중개한다. 외부에서 서비스를 위해 접속 시 reverse proxy 의 정보만을 가지고 있다. 즉, 도 31에서와 같이 클라이언트 (1080)는 proxy를 일반 서버로 인식한다. 따라서 클라이언트 (1080)는 proxy IP를 보고 들어오는 방식 이므로, proxy (1070)를 거쳐야 하고 DNS을 proxy IP로 설정해야 한다. 예를 들어 target 서버로의 요청 시, target server의 접근을 모두 reverse proxy에 맵핑된 주소로 target 서버에 요청하여, 데이터를 수신한다. Youtube로 특정 사이트를 접근 시 proxy를 통해 전달하지 못하도록 필터링을 할 수 있다. In the in-gateway DNS redirection with reverse proxy mode according to the present invention, the reverse proxy relays requests to physically and logically divided servers for the purpose of load balancing or service. When connecting for service from outside, it has only reverse proxy information. That is, as shown in FIG. 31, the client 1080 recognizes the proxy as a general server. Therefore, since the client 1080 sees the proxy IP, the client 1080 needs to go through the proxy 1070 and set the DNS as the proxy IP. For example, when a request is made to a target server, all accesses of the target server are requested to the target server at an address mapped to the reverse proxy and data is received. When you access a specific site with Youtube, you can filter it so that it cannot be delivered through a proxy.
상기 In gateway DNS redirection with proxy 모드는 클라이언트(1080)의 origin target server 즉, 컨텐트 호스팅부(1040)로의 요청을 multicast gateway (1070)의 DNS redirection/interception을 통해 IP/host name으로 할당하여 접속하도록 만드는 reverse proxy이다. 컨텐트 호스팅부(1040, 즉 Origin) 입장에서는 중간에 reverse proxy의 host name을 통하여 request와 data response를 전달해주는 역할을 한다. 따라서, 상기 인-게이트웨이 포워드 프록시 모드에서는 DNS가 필요 없는데 반해, In gateway DNS redirection with proxy 모드에서는 DNS서버가 필요하다.The In gateway DNS redirection with proxy mode assigns a request to the origin target server of the client 1080, that is, the content hosting unit 1040, to an IP / host name through DNS redirection / interception of the multicast gateway 1070 to connect. reverse proxy. In the context of the content hosting unit 1040, that is, Origin, it transmits a request and a data response through the host name of the reverse proxy. Therefore, DNS is not required in the in-gateway forward proxy mode, whereas a DNS server is required in the in gateway DNS redirection with proxy mode.
다음은 본 발명에 따른 In gateway DNS redirection with proxy 모드의 동작 예이다.The following is an example of operation of the In gateway DNS redirection with proxy mode according to the present invention.
1. Local DNS service co-located with multicast gateway (1070) in a home gateway router device. 1.Local DNS service co-located with multicast gateway (1070) in a home gateway router device.
2. DHCP lease issued to client device by home gateway device specifies that all clients should use the local DNS service to resolve host names.2. DHCP lease issued to client device by home gateway device specifies that all clients should use the local DNS service to resolve host names.
3. Client (1080) requests manifest and this is returned unmodified.3.Client (1080) requests manifest and this is returned unmodified.
4. Client (1080) looks inside the manifest and attempts to resolve unicast host name.4.Client (1080) looks inside the manifest and attempts to resolve unicast host name.
5. Local DNS resolves unicast host name to the IP address of multicast gateway (1070).5.Local DNS resolves unicast host name to the IP address of multicast gateway (1070).
6. Client (1080) makes a request for media to the IP address of multicast gateway (1070), believing it to be the unicast source.6.Client (1080) makes a request for media to the IP address of multicast gateway (1070), believing it to be the unicast source.
7. Multicast gateway (1070) can then respond with media received via multicast.7.Multicast gateway (1070) can then respond with media received via multicast.
8. HTTPS works fine because the client (1080) is connecting to the reverse proxy in the (mistaken) belief that it is the true origin.8.HTTP works fine because the client (1080) is connecting to the reverse proxy in the (mistaken) belief that it is the true origin.
본 발명에 따른 Sticky HTTP redirection plus reverse proxy 모드는 HTTP 302 redirection 모드를 추가 한 것이다. 즉, HTTP는 웹 서버의 대한 응답으로 HTTP Response Status Code를 응답하게 된다. HTTP Response Status Code 중 302 코드는 사용자를 새로운 URL로 이동시키는 코드이다. 302 리다이렉트의 의미는 요청한 리소스가 임시적으로 새로운 URL로 이동되었다는 것을 나타낸다. 기존 URL을 그대로 유지한 상태로 새로운 URL에서 접속 가능하도록 하는 방법이다. Sticky HTTP redirection plus reverse proxy mode according to the present invention is to add the HTTP 302 redirection mode. In other words, HTTP responds with HTTP Response Status Code in response to the web server. The 302 code in the HTTP Response Status Code is a code for moving a user to a new URL. The meaning of 302 redirect indicates that the requested resource has been temporarily moved to a new URL. This is how to make the new URL accessible while maintaining the existing URL.
따라서, 클라이언트(1080)는 도 32에서와 같이 컨텐트 호스팅부(1040, 즉 origin server)와 인터페이스 B를 통해 bootstrapping 과정을 거쳐 MPD를 수신하게 된다. 상기 컨텐트 호스팅부(1040)는 HTTP 302를 통해 multicast gateway (1070)의 IP 나 hostname으로 redirection 하여, multicast gateway (1070)가 origin 같이 데이터를 다운로드 받을 수 있게 처리 할 수 있다. Accordingly, the client 1080 receives the MPD through the bootstrapping process through the content hosting unit 1040 (that is, the origin server) and the interface B as shown in FIG. 32. The content hosting unit 1040 may redirection to the IP or hostname of the multicast gateway 1070 through the HTTP 302, so that the multicast gateway 1070 may download data as the origin.
다음은 본 발명에 따른 Sticky HTTP redirection plus reverse proxy 모드 의 동작 예이다.The following is an example of the operation of Sticky HTTP redirection plus reverse proxy mode according to the present invention.
1. Client (1080) requests manifest from unicast origin via unicast bootstrap interface B.1.Client (1080) requests manifest from unicast origin via unicast bootstrap interface B.
2. Content hosting unit (1040) issues a HTTP 302 redirect pointing the client (1080) at the hostname or IP address of multicast gateway (1070).2.Content hosting unit (1040) issues a HTTP 302 redirect pointing the client (1080) at the hostname or IP address of multicast gateway (1070).
3. Client (1080) requests media from multicast gateway (1070), believing it to be the origin.3.Client (1080) requests media from multicast gateway (1070), believing it to be the origin.
4. HTTPS works fine because the client (1080) is connecting to the reverse proxy in the (mistaken) belief that it is the true origin.4.HTTPS works fine because the client (1080) is connecting to the reverse proxy in the (mistaken) belief that it is the true origin.
본 발명에 따른 manipulation of URLs in manifest plus reverse proxy 모드는 앞서 설명한 reverse proxy 와 같이 multicast gateway (1070)를 origin 과 같은 서버 역할을 하게 끔 multicast gateway (1070)의 host name/IP를 전달 한다 (도 33 참조). 다만, 인터페이스 B를 통해 받은 bootstrapping 정보 중 manifest 내에 URLs 을 멀티캐스트 상황에 따른 서버를 선택할 수 있는 hostname 을 선택 제공한다. 여기서 매니페스트에 포함된 콘텐츠 URLs를 삭제하거나 컴포넌트를 줄이는 게 아닌, 컨텐트 호스팅부(1040, 즉, Origin 서버)가 멀티캐스트를 인식하고, 매니페스트 내 hostname을 컨트를 하는 proxy 모드이다. The manipulation of URLs in manifest plus reverse proxy mode according to the present invention delivers the host name / IP of the multicast gateway 1070 to act as a server such as the origin of the multicast gateway 1070 as the reverse proxy described above (FIG. 33). Reference). However, among the bootstrapping information received through interface B, URLs are selected in the manifest and hostname can be selected to select a server according to the multicast situation. In this case, the content hosting unit 1040 (that is, the origin server) recognizes the multicast and controls the hostname in the manifest, instead of deleting the content URLs included in the manifest or reducing components.
다음은 본 발명에 따른 manipulation of URLs in manifest plus reverse proxy 모드의 동작 예이다.The following is an example of operation of the manipulation of URLs in manifest plus reverse proxy mode according to the present invention.
1. Client (1080) requests manifest from unicast origin via unicast bootstrap interface B.1.Client (1080) requests manifest from unicast origin via unicast bootstrap interface B.
2. Content hosting unit (1040) serves a personalised manifest containing hostname the resolves to multicast gateway (1070), or the IP address of multicast gateway (1070).2.Content hosting unit (1040) serves a personalized manifest containing hostname the resolves to multicast gateway (1070), or the IP address of multicast gateway (1070).
3. Client (1080) requests media from multicast gateway (1070), believing it to be the origin.3.Client (1080) requests media from multicast gateway (1070), believing it to be the origin.
한편, MPEG-DASH는 세그먼트 모드(Segment mode)에서 청크/파일 (chunk/file) 딜리버리를 통해 세그먼트의 시작 시간과 기간(duration)으로 타임라인(timeline)을 정의한다. 또한 MPD 내 세그먼트 타임라인을 정의하는 엘레먼트는 인코딩 시 제공하는 타임스케일(timescale)을 기준으로 하여 세그먼트 가능 타이밍(Segment availability timing)과 세그먼트 프리젠테이션 타이밍(Segment presentation timing)의 송수신 동기화 정보를 계산 할 수 있다. Meanwhile, MPEG-DASH defines a timeline as a start time and duration of a segment through chunk / file delivery in segment mode. In addition, the element defining the segment timeline in the MPD can calculate the transmission and reception synchronization information of segment availability timing and segment presentation timing based on the timescale provided during encoding. have.
도 34는 MPEG DASH에서 상기 Segment availability timing과 Segment presentation timing의 segment timeline을 만들기 위한 segmenttimeline 엘레먼트의 시맨틱스의 일 예를 보이고 있다. 즉, 도 34는 segmenttimeline 엘레먼트의 MPEG DASH MPD semantics이다.34 shows an example of semantics of a segmenttimeline element for creating a segment timeline of the segment availability timing and segment presentation timing in MPEG DASH. That is, FIG. 34 shows MPEG DASH MPD semantics of the segmenttimeline element.
도 34의 segmenttimeline 엘레먼트의 하위 엘레먼트들인 @t 엘레먼트는 세그먼트의 earliest presentation time 을 나타내고, @d 엘레먼트는 segment duration을 나타낸다. The @t elements, which are sub-elements of the segmenttimeline element of FIG. 34, represent the earliest presentation time of the segment, and the @d element represents the segment duration.
도 34의 @t 엘레먼트와 @d 엘레먼트에 해당하는 정보는 세그먼트 내에서도 정의가 가능하다. 일 실시예로, 도 35에서와 같이 인덱스 세그먼트 내 세그먼트 인덱스 정보를 포함하는 'sidx'박스에 정의할 수 있다. 이 경우, 세그먼트의 미디어 샘플의 첫번째 오프셋 정보와 earliest presentation time 을 32비트 또는 64비트로 정의 할 수 있다. Information corresponding to the @t element and the @d element of FIG. 34 may be defined even within a segment. According to an embodiment, as shown in FIG. 35, the 'sidx' box including segment index information in the index segment may be defined. In this case, the first offset information and the earliest presentation time of the media sample of the segment may be defined as 32 bits or 64 bits.
한편, 인덱스 세그먼트의 인코딩이 없을 경우에는 moof 박스의 'tfdt' 내 baseMediaDecodeTime 의 값이 earliest presentation time 을 대신 할 수 있다. 이렇게 만들어진 segment timeline은 MPD 전체 속성을 고려하고 아래와 같은 수학식 1을 적용하여 segment presentation time 을 정의 할 수 있다. On the other hand, if there is no encoding of the index segment, the value of baseMediaDecodeTime in 'tfdt' of the moof box may replace the earliest presentation time. The segment timeline thus created can define the segment presentation time by considering the overall MPD properties and applying Equation 1 below.
Figure PCTKR2018006479-appb-M000001
Figure PCTKR2018006479-appb-M000001
위의 수학식 1에서 MPD@availabilityStartTime 엘레먼트, Period@start 엘레먼트, MPD@suggestedPresentationDelay 엘레먼트는 도 36에서와 같이 MPD에 포함되는 엘레먼트들이다. 상기 MPD@availabilityStartTime 엘레먼트는 DASH 클라이언트가 DASH 서버로 접근하여 MPD가 확보 가능한 시점을 나타낸 것이고, 상기 period@start 엘레먼트는 MPD 내 서비스 관점에서 하나 또는 다수의 타임 슬롯으로 나눈 period 가 시작되는 시점이다. 상기 SegmentBase@presentationTimeoffset 엘레먼트와 timescale은 period 의 시작 시간과 실제 미디어 A/V (Audio/Video)가 터지는 타임라인과의 상대적인 시간을 계산한 것이다. 상기 MPD@SuggestedPresentationDelay 엘레먼트는 DASH 클라이언트들의 기기간 동기화와 지터(jitter), 전송 딜레이 (transmission delay 또는 xmit delay) 등을 고려하여 정해지는 값이다. In Equation 1 above, the MPD @ availabilityStartTime element, the Period @ start element, and the MPD @ suggestedPresentationDelay element are elements included in the MPD as shown in FIG. 36. The MPD @ availabilityStartTime element represents a point in time when the DASH client accesses the DASH server to secure the MPD, and the period @ start element is a point in time at which a period divided into one or more time slots starts from a service point of view within the MPD. The SegmentBase @ presentationTimeoffset element and timescale calculate a relative time between the start time of a period and the timeline at which the actual media A / V (Audio / Video) pops. The MPD @ SuggestedPresentationDelay element is a value determined in consideration of device-to-device synchronization, jitter, and transmission delay (transmission delay or xmit delay) of DASH clients.
도 37은 MPEG DASH 동기화 타임라인의 일 실시예를 보인 도면이다.37 is a diagram illustrating an embodiment of an MPEG DASH synchronization timeline.
도 37의 (a)는 미디어 세그먼트를 인코딩하는 인코더 타임라인이고, 도 37의 (b)는 세그먼트 duration을 반영한 availability 타임라인(즉, DASH 서버에 세그먼트가 준비된 상태의 타임라인)이며, 도 37의 (c)는 DASH 서버에서 전송되는 전송 프레임들의 타임라인이다. 도 37의 (d)는 DASH 클라이언트가 수신하는 수신 프레임들의 타임라인이고, 도 37의 (e)는 지연 요소들을 모두 고려하여 계산된 segment presentation 타임라인이다. 즉, 도 37의 (e)는 상기 수학식 1을 적용하여 계산된 segment presentation timeline의 일 예이다. FIG. 37A is an encoder timeline for encoding a media segment, and FIG. 37B is an availability timeline reflecting the segment duration (that is, a timeline in which a segment is prepared in a DASH server). (c) is a timeline of transmission frames transmitted from the DASH server. FIG. 37D is a timeline of received frames received by the DASH client, and FIG. 37E is a segment presentation timeline calculated by considering all delay factors. That is, FIG. 37E illustrates an example of a segment presentation timeline calculated by applying Equation 1 above.
이때, MPEG DASH에서는 세그먼트가 DASH 서버에서 available되는 시점을 도 37의 (b)의 availability timeline과 같이, segment duration 동안 데이터가 누적되어 완벽한 파일이 구성되면 전송 가능하다는 관점으로 타임라인을 구성하였다. 하지만, 파일 청크가 available 되고 전송을 하는 Latency 관점에서 단점이 발생할 수 있다. At this time, in MPEG DASH, the timeline is configured from the viewpoint that the time when the segment is available in the DASH server can be transmitted when data is accumulated during the segment duration and a complete file is formed as shown in the availability timeline of FIG. 37 (b). However, there may be disadvantages in terms of latency in which file chunks are available and transmitted.
이를 해결하기 위해, 본 발명은 리니어 서비스 전송시에 세그먼트가 완벽하게 available 하지 않아도, 미리 전송할 수 있는 실시예를 제안한다.In order to solve this problem, the present invention proposes an embodiment which can be transmitted in advance even if a segment is not completely available at the time of linear service transmission.
즉, segment availability start time에서 MPD 내 SegmentBase@availabilityTimeOffset 엘레먼트의 값만큼을 줄여주어, 세그먼트가 완벽하게 available 하지 않아도 미리 세그먼트를 요청할 수 있도록 한다. 일 실시예로, 이 값은 segment availability start time 에서 availabilityTimeOffset 값만큼을 빼줌에 의해 얻어지며, 이 값만큼 세그먼트의 미리 요청이 가능해진다. 그리고 이 정보는 도 38에서와 같이 SegmentBase@availabilityTimeOffset 엘레먼트나, BaseURL@availabilityTimeOffset 엘레먼트에 정의되는 것을 일 실시예로 한다. 이 availabilityTimeOffset 정보의 상세 내용은 도 38의 설명을 참조하기로 한다.That is, the segment availability start time is reduced by the value of the SegmentBase @ availabilityTimeOffset element in the MPD so that the segment can be requested in advance even if the segment is not completely available. In one embodiment, this value is obtained by subtracting the availabilityTimeOffset value from the segment availability start time, and the segment can be requested in advance by this value. In this embodiment, the information is defined in the SegmentBase @ availabilityTimeOffset element or the BaseURL @ availabilityTimeOffset element as shown in FIG. 38. Details of the availabilityTimeOffset information will be described with reference to FIG. 38.
다음은 위의 설명을 수학식 2로 나타낸 것이다. Next, the above description is represented by Equation 2.
Figure PCTKR2018006479-appb-M000002
Figure PCTKR2018006479-appb-M000002
특히 빠른 미디어 재생을 위해 fast startup할 때 Segment availability start time에서 상기 SegmentBase@availabilityTimeOffset 값을 빼거나 더해줌으로써, 미디어 재생을 빠르게 수행할 수 있을 뿐만 아니라, 딜리버리 경로의 전환 시간을 기존보다 단축시킬 수 있게 된다.In particular, when fast startup for fast media playback, by adding or subtracting the SegmentBase @ availabilityTimeOffset value from the Segment availability start time, media playback can be performed quickly and delivery path switching time can be shortened. .
한편, 멀티캐스트 ABR 의 시스템 아키텍쳐가 도 23과 같다면, 컨텐트 인코딩부(1031)에서 인코딩된 미디어 컨텐트가 컨텐트 호스팅부(1040) 및/또는 멀티캐스트 서버(1050)를 거치면서 딜레이가 발생한다. 또한 멀티캐스트 게이트웨이(1070)가 프록시 서버로 동작할 때 프록시 모드에 따라 connection 부터 data flow의 발생까지의 딜레이(즉, 레이턴시)가 생길 수 있다. On the other hand, if the system architecture of the multicast ABR is shown in FIG. 23, a delay occurs while the media content encoded by the content encoding unit 1031 passes through the content hosting unit 1040 and / or the multicast server 1050. In addition, when the multicast gateway 1070 operates as a proxy server, a delay (that is, latency) from connection to generation of data flow may occur depending on the proxy mode.
따라서 본 발명은 이러한 딜레이를 MPEG DASH 기술 내에서 보상하기 위한 실시예를 제안한다.Therefore, the present invention proposes an embodiment for compensating for such delay in MPEG DASH technology.
즉, 상기 컨텐트 인코딩부(1031)의 출력은 멀티캐스트 서버(1050)에서 딜리버리 포맷으로 인캡슐레이션된 후, 특정 프로토콜 스택 (예, ROUTE 프로토콜)으로 전송된다. 이때, MPD@SuggestedPresentationDelay 엘레먼트를 이용하여 전송 딜레이를 반영시켜 segment presentation time을 정의한다. 하지만, 컨텐트 인코딩부(1031)에서 출력되는 데이터가 멀티캐스트 서버(1050)에서 딜리버리 포맷으로 인캡슐레이션된 후 인터페이스 M을 통해 푸쉬되고 멀티캐스트 게이트웨이(1070)에 쌓이는 절차를 거치게 되면 초기에 정의한 MPD@SuggestedPresentationDelay 엘레먼트의 값은 의미가 없거나, 실제로 적용하기 어렵게 된다. 또한 채널 별 segment mode가 모두 다르기 때문에 Segment availability start time이 달라 질 수 있다. 다시 말해, 인코딩 한 매니페스트의 타이밍 정보와 실제 멀티캐스트 ABR 이라는 전송 인터페이스를 타고 데이터를 획득하게 되는 타이밍 정보는 달라질 수 있다. That is, the output of the content encoding unit 1031 is encapsulated in a delivery format by the multicast server 1050, and then transmitted to a specific protocol stack (eg, a ROUTE protocol). At this time, the segment presentation time is defined by reflecting the transmission delay using the MPD @ SuggestedPresentationDelay element. However, if the data output from the content encoding unit 1031 is encapsulated in the delivery format in the multicast server 1050, pushed through the interface M, and accumulated in the multicast gateway 1070, the MPD previously defined The value of the @SuggestedPresentationDelay element is meaningless or difficult to apply in practice. In addition, the segment availability start time may be different because the segment modes for each channel are different. In other words, timing information of an encoded manifest and timing information obtained through data transmission interface called multicast ABR may be different.
본 발명은 상기 네트워크 콘트롤러(1063)에서 DASH 타이밍 정보를 재구성 할 수 있는 타이밍 보상 정보를 생성하여 콘트롤 메시지에 시그널링한 후 멀티캐스트 게이트웨이(1070) 및/또는 멀티캐스트 서버(1050)로 전송하는 것을 일 실시예로 한다. 이때 상기 네트워크 콘트롤러(1063)는 상기 컨텐트 프로바이더 콘트롤러(1020)에서 제공되는 타이밍 정보를 기반으로 상기 타이밍 보상 정보를 생성하는 것을 일 실시예로 한다. 본 발명에서 상기 타이밍 보상 정보는 설명의 편의를 위해 타이밍 갱신 정보 또는 동기화 정보라 칭하기도 한다. According to the present invention, the network controller 1063 may generate timing compensation information capable of reconfiguring DASH timing information, signal the control message, and transmit the signal to a multicast gateway 1070 and / or a multicast server 1050. It is set as an Example. In this embodiment, the network controller 1063 generates the timing compensation information based on the timing information provided from the content provider controller 1020. In the present invention, the timing compensation information is also referred to as timing update information or synchronization information for convenience of description.
즉, 상기 컨텐트 프로바이더 콘트롤러(1020)에서 제공되는 타이밍 정보는 다른 블록들을 거치지 않고 바로 네트워크 콘트롤러(1063)로 제공되기 때문에 딜레이가 발생하지 않는다. 하지만 상기 컨텐트 프로바이더 콘트롤러(1020)에서 제공되는 타이밍 정보가 컨텐트 준비부(1030), 멀티플렉서 서버(1050) 등을 거치게 되면, 딜레이가 발생하게 되어 두 타이밍 정보 간에 차이가 생기게 된다.That is, since the timing information provided from the content provider controller 1020 is directly provided to the network controller 1063 without passing through other blocks, no delay occurs. However, when the timing information provided from the content provider controller 1020 passes through the content preparation unit 1030, the multiplexer server 1050, a delay occurs, and a difference occurs between the two timing information.
즉, 도 23과 같은 시스템 아키텍쳐에서, 컨텐트 프로바이더 콘트롤러(1020)는 현재 RF 에서 제공되는 리니어 서비스의 대표적 reference play time 이나, network condition에 따른 reference time line을 기준으로 현재 재생되고 있는 세그먼트의 정보 및 타이밍 정보를 상기 네트워크 콘트롤러(1063)로 전달한다. 상기 네트워크 콘트롤러(1063)는 상기 컨텐트 프로바이더 콘트롤러(1020)에서 제공되는 세그먼트의 정보 및 타이밍 정보를 기반으로 네트워크 환경(network condition)과 상기 멀티캐스트 게이트웨이(1070)가 프록시 서버로 동작할 때의 프록시 서버 모드를 고려하여 타이밍 보상 정보를 생성한다. 상기 타이밍 보상 정보는 @availabilityStartTime 엘레먼트, @suggestedPresentationDelay 엘레먼트, 및 @availabilityTimeOffset 엘레먼트를 포함하는 것을 일 실시예로 한다. 상기 엘레먼트들의 상세한 내용은 도 40과 도 41을 참조하기로 한다. 상기 타이밍 보상 정보는 인터페이스 CMS을 이용하여 멀티캐스트 서버(1050)로 전송되거나, 인터페이스 CMR을 이용하여 멀티캐스트 게이트웨이(1070)로 전송된다.That is, in the system architecture as shown in FIG. 23, the content provider controller 1020 may provide information on a segment currently being played based on a representative reference play time of a linear service currently provided by RF or a reference time line according to a network condition. The timing information is transmitted to the network controller 1063. The network controller 1063 is a proxy when a network condition and the multicast gateway 1070 operate as a proxy server based on segment information and timing information provided by the content provider controller 1020. The timing compensation information is generated in consideration of the server mode. The timing compensation information includes an @availabilityStartTime element, an @suggestedPresentationDelay element, and an @availabilityTimeOffset element. Details of the elements will be described with reference to FIGS. 40 and 41. The timing compensation information is transmitted to the multicast server 1050 using the interface C MS or to the multicast gateway 1070 using the interface C MR .
즉, 멀티캐스트 서버(1050)에서는 상기 타이밍 보상 정보를 기반으로, 역 호환성의 관점에서 delivery re-format 을 통해 전환 시나, re-encoding 발생하는 timing의 변화시에 동기화 정보를 재구성 할 수 있다. That is, the multicast server 1050 may reconfigure the synchronization information based on the timing compensation information when switching through delivery reformat from the viewpoint of backward compatibility or when timing change occurs during re-encoding.
이와 같이 방송의 리니어 서비스와 IP를 통한 MABR 서비스의 latency의 차이로 인해, 데이터 패킷의 요청 시간을 맞춰야 하는 요구사항이 있을 시, 현재 월 클럭(wall clock) 기준 세그먼트의 동기화가 필요하다. 이때 요청 되는 segment(k) 의 k 값과 새로운 timing 모델을 만들 때 Segment availability start time 과 Segment presentation timing 을 재구성해야 한다. Due to the difference in latency between the broadcast linear service and the MABR service over IP, synchronization of the current wall clock reference segment is required when there is a requirement to meet the request time of the data packet. You should reconfigure the Segment availability start time and Segment presentation timing when creating a new timing model with the k value of the requested segment (k).
이러한 경우 네트워크 콘트롤러(1063)는 상기 컨텐트 프로바이더 콘트롤러(1020)로부터 제공되는 타이밍 정보를 기반으로 타이밍 보상 정보를 생성한 후 콘트롤 메시지에 포함시켜, 인터페이스 Cms 및/또는 Cmr 을 통해 멀티캐스트 서버(1050) 및/또는 멀티캐스트 게이트웨이(1070)로 전송할 수 있다.In this case, the network controller 1063 generates timing compensation information based on the timing information provided from the content provider controller 1020 and then includes it in a control message, and then multicast server 1050 through the interface Cms and / or Cmr. And / or to the multicast gateway 1070.
여기서, SuggestedPresentationDelay 값은 도 39에서와 같이 세그먼트의 수신시간 (seg. Duration), 지터, 전송 딜레이(transmission delay, xmit delay이라 하기도 함), 피지컬 스택 딜레이(stack delay) 등을 모두 고려하여 정해진 값이다. 상기 멀티캐스트 게이트웨이(1070) 또는 클라이언트(1080)는 상기 SuggestedPresentationDelay 값을 이용하여 segment presentation time을 조정한다. 또한, 네트워크 콘트롤러(1063)에서 타이밍 보상 정보를 포함하는 콘트롤 메시지가 전송되면, 상기 멀티캐스트 게이트웨이(1070) 또는 클라이언트(1080)는 상기 멀티캐스트 서버(1050)로부터 받은 MPD 내 해당 엘레먼트 값들을 상기 콘트롤 메시지에 포함된 해당 엘레먼트 값들로 업데이트하고, 업데이트된 엘레먼트 값들을 이용하여 Segment availability start time와 segment presentation time을 조정한다. In this case, the SuggestedPresentationDelay value is determined in consideration of the segment duration, jitter, transmission delay (also referred to as transmission delay, xmit delay), physical stack delay, etc. as shown in FIG. . The multicast gateway 1070 or the client 1080 adjusts the segment presentation time using the SuggestedPresentationDelay value. In addition, when a control message including timing compensation information is transmitted from the network controller 1063, the multicast gateway 1070 or the client 1080 controls the corresponding element values in the MPD received from the multicast server 1050. Update the corresponding element values included in the message, and adjust the segment availability start time and the segment presentation time using the updated element values.
또한, 상기 멀티캐스트 서버(1050)에서는 인터페이스 CMS 및/또는 CMR로 전달된 콘트롤 메시지 내 타이밍 보상 정보를 이용하여 컨텐트 준비부(1030) 및/또는 컨텐트 호스팅부(1040)에서 제공되는 MPD의 해당 값을 수정하여, 재 인코딩도 가능하게 할 수 있다. In addition, the multicast server 1050 uses the timing compensation information in the control message transmitted to the interface C MS and / or C MR to determine the MPD provided by the content preparation unit 1030 and / or the content hosting unit 1040. You can also modify the value to enable re-encoding.
일 실시예로, 현재 리니어 서비스에서 튠 인(tune in)되고 있는 segment(k) 를 모니터링하여, k 번째의 세그먼트의 정보를 콘트롤 인터페이스(SP-MC-X or client)를 통해 전달하고 k 번째의 earliest presentation time 을 적용하여 기기간 동기화를 최대한 구현하는 것이 가능하다. In one embodiment, by monitoring the segment (k) currently being tuned in (linear) in the linear service, the information of the k-th segment is transmitted through the control interface (SP-MC-X or client), By applying earliest presentation time, it is possible to realize maximum synchronization between devices.
그리고, 위에서 설명한 바와 같이, Segment availability start time 에서 availabilityTimeOffset 값만큼을 더하거나 뺀 만큼의 타임라인을 만들어 줄 수 있다. 만약 멀티캐스트 서버(1050)의 delivery format 이 재 인코딩 되어 movie fragment 사이즈가 작아지고, 이로 인해 세그먼트 내의 moof 간격이 좁아지게 되면, availabilityTimeOffset 값을 통하여 Segment availability start time 을 재 구성해야 한다. 따라서 컨텐트 프로바이더(또는 서비스 프로바이더)의 요청 또는 리니어 서비스의 레이턴시를 줄이기 위해 delivery format 의 변화가 있다면, 상기 네트워크 콘트롤러(1063)에서 제공되는 타이밍 보상 정보를 이용하여 Segment availability start time을 재구성할 수 있다.As described above, a timeline can be created by adding or subtracting the availabilityTimeOffset value from the segment availability start time. If the delivery format of the multicast server 1050 is re-encoded to reduce the movie fragment size, and thus, the moof interval in the segment is narrowed, the segment availability start time must be reconfigured through the availabilityTimeOffset value. Therefore, if there is a change in delivery format in order to reduce the request of the content provider (or service provider) or the latency of the linear service, the segment availability start time may be reconfigured using the timing compensation information provided by the network controller 1063. have.
도 39의 (a) 내지 (f)는 본 발명의 일 실시예에 따른 타임라인의 도면을 보인 것이다. 도 39의 (a)는 미디어 세그먼트를 인코딩하는 인코더 타임라인이고, 도 39의 (b)는 세그먼트 duration을 반영한 reception timeline이다. 도 39의 (c)는 세그먼트 duration과 availability time offset을 모두 반영한 reception timeline이다. 즉, 도 39의 (c)에서 Reception time(ATO)는 Segment availability start time 의 시간에서 세그먼트의 슬라이스된 청크 모드(sliced chunk mode)나 MABR 의 네트워크 상황이 반영된 SegmentBase@availabilityTimeOffset 값만큼을 줄여서 세그먼트를 요청 할 수 있다. 도 39의 (d)는 멀티캐스트 서버(1050)에서 제공되는 MPD 내 정보를 이용하여 정의된 segment presentation timeline이고, 도 39의 (e)는 네트워크 콘트롤러(1063)에서 제공되는 타이밍 보상 정보를 기반으로 정의된 segment presentation timeline이다. 즉, 도 39의 (e)의 Presentation timeline-1은 네트워크 콘트롤러(1063)에서 제공되는 타이밍 보상 정보를 기반으로 업데이트된 MPD@suggestedPresentationDelay 값을 이용하여 다시 정의된 segment presentation timeline이다. 그리고 도 39의 (f)의 Presentation timeline-2 는 현재 기준이 되는 linear service AV start up을 기준으로 하여, 현재 segment 1 의 재생을 버퍼링하지 않고, segment (k)의 버퍼링을 시도한다. 이때 적용되어야 할 정보는 segment(k)에 해당하는 정보와 네트워크 콘트롤러(1063)를 통해 받은 새로운 MPD@availabilityStartTime, Period@starttime, MPD@suggestedPresentationDelay, SegmentBase@availabilityTimeOffset 등이며, 이 정보를 이용하여 새로운 조정된 segment presentation timeline이다. 39 (a) to (f) show a diagram of a timeline according to an embodiment of the present invention. FIG. 39A is an encoder timeline for encoding a media segment, and FIG. 39B is a reception timeline reflecting a segment duration. FIG. 39C illustrates a reception timeline reflecting both a segment duration and a availability time offset. That is, in FIG. 39 (c), the reception time (ATO) requests the segment by reducing the sliced chunk mode of the segment or the SegmentBase @ availabilityTimeOffset value reflecting the network status of the MABR at the time of the segment availability start time. can do. FIG. 39D illustrates a segment presentation timeline defined using information in the MPD provided by the multicast server 1050, and FIG. 39E illustrates based on timing compensation information provided by the network controller 1063. Defined segment presentation timeline. That is, the presentation timeline-1 of FIG. 39E is a segment presentation timeline defined using the updated MPD @ suggestedPresentationDelay value based on the timing compensation information provided from the network controller 1063. Presentation timeline-2 of FIG. 39 (f) attempts to buffer segment (k) without buffering playback of segment 1 on the basis of the linear service AV start up as the current criterion. Information to be applied at this time is information corresponding to segment (k) and new MPD @ availabilityStartTime, Period @ starttime, MPD @ suggestedPresentationDelay, SegmentBase @ availabilityTimeOffset received through network controller 1063, and the like. Segment presentation timeline.
도 40과 도 41은 본 발명에 따른 네트워크 콘트롤러(1063)에서 생성된 콘트롤 메시지의 다른 실시예로서, 도 26의 콘트롤 메시지에 위에서 설명한 타이밍 보상 정보를 추가한 시맨틱스이다. 도 40과 도 41의 콘트롤 메시지도 도 26의 콘트롤 메시지와 마찬가지로, XML (eXtensible Markup Language) 포맷이거나, HTTP restful API message 포맷일 수 있다.40 and 41 illustrate another embodiment of a control message generated by the network controller 1063 according to the present invention. FIG. 40 and FIG. 41 are semantics of adding the timing compensation information described above to the control message of FIG. 26. Like the control message of FIG. 26, the control message of FIGS. 40 and 41 may be in XML (eXtensible Markup Language) format or HTTP restful API message format.
상기 타이밍 보상 정보는 @id 엘레먼트, @availabilityStartTime 엘레먼트, @suggestedPresentationDelay 엘레먼트, 및 @availabilityTimeOffset 엘레먼트를 포함하는 것을 일 실시예로 한다. In an embodiment, the timing compensation information includes an @id element, an @availabilityStartTime element, an @suggestedPresentationDelay element, and an @availabilityTimeOffset element.
상기 @id 엘레먼트는 미디어 presentation에 대한 식별자를 지시한다.The @id element indicates an identifier for media presentation.
상기 @availabilityStartTime 엘레먼트는 @type 필드가 'dynamic'인 경우, 미디어 presentation에 포함된 임의의 세그먼트의 가장 빠른 availability time (in UTC)의 계산을 위한 앵커를 지시한다. @type 필드가 'static'인 경우, MPD에서 레퍼런스되는 모든 세그먼트들에 대한 sgement availability start time를 지시한다.The @availabilityStartTime element indicates an anchor for calculating the earliest availability time (in UTC) of any segment included in the media presentation when the @type field is 'dynamic'. If the @type field is 'static', it indicates sgement availability start time for all segments referenced in the MPD.
상기 @suggestedPresentationDelay 엘레먼트는 @type 필드가 'dynamic'인 경우, 각 액세스 유닛의 프리젠테이션을 위해 사용되기로 한 각 액세스 유닛의 프리젠테이션 타임으로부터 고정된 딜레이 옵셋을 지시한다. @type 필드가 'static'인 경우, 이 속성의 값은 무시한다. The @suggestedPresentationDelay element indicates a fixed delay offset from the presentation time of each access unit to be used for the presentation of each access unit when the @type field is 'dynamic'. If the @type field is 'static', the value of this attribute is ignored.
상기 @availabilityTimeOffset 엘레먼트는 조정된 segment availability time을 정의하기 위한 옵셋을 지시한다.The @availabilityTimeOffset element indicates an offset for defining the adjusted segment availability time.
여기에서 설명되지 않은 각 엘레먼트의 설명은 도 40과 도 41을 참조하기로 한다.Description of each element not described herein will be described with reference to FIGS. 40 and 41.
상기 콘트롤 메시지는 segment template 정보를 지시하는 segmenttemplate 엘레먼트를 더 포함할 수 있으며, 상기 segmenttemplate 엘레먼트의 하위 엘레먼트들로서 @media 엘레먼트와 @skip_number 엘레먼트가 포함된다.The control message may further include a segmenttemplate element indicating segment template information, and include @media element and @skip_number element as lower elements of the segmenttemplate element.
상기 @media 엘레먼트는 미디어 세그먼트 리스트를 생성하기 위한 template를 지시한다.The @media element indicates a template for generating a media segment list.
상기 @skip_number 엘레먼트는 동기화를 위해 스킵할 미디어 세그먼트의 개수를 지시한다.The @skip_number element indicates the number of media segments to skip for synchronization.
도 42는 본 발명의 일 실시예에 따른 수신기 구조를 나타낸 도면이다. 상기 수신기는 상기 컨텐트 재생부(1080)일 수도 있고, 상기 컨텐트 재생부(1080)의 일부일 수도 있다.42 illustrates a receiver structure according to an embodiment of the present invention. The receiver may be the content playback unit 1080 or may be part of the content playback unit 1080.
도 42의 수신기는 tuner를 이용하여 멀티캐스트 서비스 및/또는 유니캐스트 서비스를 포함하는 신호를 수신할 수 있다. 또는 상기 수신기는 상기 멀티캐스트 게이트웨이(1070)로부터 멀티캐스트 서비스 및/또는 유니캐스트 서비스를 포함하는 신호를 수신할 수 있다. 여기서 상기 멀티캐스트 서비스 및/또는 유니캐스트 서비스는 방송 서비스인 것을 일 실시예로 한다. 또한 상기 수신기는 튜너 및/또는 상기 멀티캐스트 게이트웨이(1070)로부터 MPD를 미리 수신할 수도 있다. 여기서, MPD는 상기 네트워크 콘트롤러(1063)에서 출력되는 도 41과 도 42와 같은 콘트롤 메시지에 포함된 정보를 기반으로 상기 멀티캐스트 게이트웨이(1070)에서 업데이트되어 상기 수신기로 전송되는 것을 일 실시예로 한다.The receiver of FIG. 42 may receive a signal including a multicast service and / or a unicast service using a tuner. Alternatively, the receiver may receive a signal including a multicast service and / or a unicast service from the multicast gateway 1070. In this embodiment, the multicast service and / or the unicast service are broadcast services. The receiver may also previously receive an MPD from a tuner and / or the multicast gateway 1070. In this embodiment, the MPD is updated by the multicast gateway 1070 based on the information included in the control messages shown in FIGS. 41 and 42 output from the network controller 1063 and transmitted to the receiver. .
수신기는 ADC (Analog Digital converter)를 이용하여 수신된 아날로그 신호를 디지털 신호로 변환하고, Demodulator를 이용하여 디지털화된 신호를 복조(demodulating)할 수 있다. 수신기는 channel sync. & EQ를 이용하여 복조된 신호에 대해 동기화 및 이퀄라이징을 수행하고, 채널 디코더를 이용하여 수신된 신호에 대한 채널 디코딩을 수행할 수 있다. L1 시그널링 파서는 상기 디코딩된 신호로부터 L1 시그널링 정보를 획득할 수 있다. L1 시그널링 정보는 수신기의 baseband controller에 전달되어 피지컬 레이어 데이터를 획득하는데 사용될 수 있다. 또한 L1 시그널링 정보는 수신기의 시그널링 컨트롤러에 입력될 수 있다. 또한 L2 시그널링 파서는 상기 디코딩된 신호로부터 L2 시그널링 정보를 획득할 수 있다. 상기 L2 시그널링 정보는 서비스 획득을 위한 서비스 레이어 시그널링 정보를 포함할 수 있으며, 상기 서비스 레이어 시그널링 정보는 또한 상기 L2 시그널링 정보는 User Service Bundle Description (USBD) 정보, Service-based Transport Session Instance Description (S-TSID) 정보, Associated Procedure Description (APD) 정보, DASH Media Presentation Description (MPD) 정보, HTML Entry pages Location Description (HELD) 정보, 및 Distribution Window Description (DWD)를 포함할 수 있다. The receiver converts the received analog signal into a digital signal using an analog digital converter (ADC), and demodulates the digitized signal using a demodulator. Receiver is channel sync. The & EQ may be used to perform synchronization and equalization on the demodulated signal, and the channel decoder may be used to perform channel decoding on the received signal. The L1 signaling parser may obtain L1 signaling information from the decoded signal. The L1 signaling information may be delivered to the baseband controller of the receiver and used to acquire physical layer data. In addition, the L1 signaling information may be input to the signaling controller of the receiver. In addition, the L2 signaling parser may obtain L2 signaling information from the decoded signal. The L2 signaling information may include service layer signaling information for service acquisition, and the service layer signaling information may further include user service bundle description (USBD) information and service-based transport session instance description (S−). TSID) information, Associated Procedure Description (APD) information, DASH Media Presentation Description (MPD) information, HTML Entry pages Location Description (HELD) information, and Distribution Window Description (DWD).
상기 획득된 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)를 이용하여 비디오 데이터를 출력할 수 있다. The obtained L2 signaling information may be input to a signaling controller. The signaling controller may communicate with a service layer signaling channel (or service signaling channel (ssc)) processing buffer and parser, thereby updating the service MAP DB (data base). In addition, 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. In addition, 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. The received IP packet is input to the A / V service controller via the common protocol stack. The demultiplexer of the receiver can demultiplex audio and video data. The receiver may output audio data using an audio decoder and an audio renderer, and output video data using a video decoder and a video renderer.
본 발명의 실시예에 따르면, 기존의 방송 네트워크 (network), 인터넷 (internet), 홈네트워크 (home network) 등에 속해있는 장치들(devices) 사이의 멀티캐스트 (multicast) 전송을 효과적으로 제공할 수 있다. According to an embodiment of the present invention, it is possible to effectively provide multicast transmission between devices belonging to an existing broadcast network, the Internet, a home network, or the like.
본 발명의 실시예에 따르면, 기존 unicast 전송을 multicast로 전환하여 network의 부하를 감소시킬 수 있다.According to an embodiment of the present invention, the load on the network can be reduced by switching the existing unicast transmission to multicast.
본 발명의 실시예에 따르면, 리니어 (Linear) 서비스 및 실시간 라이브 인코딩 시 네트워크 상황에 따라 발생되는 딜레이 문제를 극복하고, 신속한 컨텐츠의 재생 시작 (AV startup)을 지원할 수 있다.According to an embodiment of the present invention, it is possible to overcome delay problems caused by network conditions during linear service and real-time live encoding, and to support fast AV playback.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.For convenience of description, each drawing is divided and described, but it is also possible to design a new embodiment by merging the embodiments described in each drawing. And, according to the needs of those skilled in the art, it is also within the scope of the present invention to design a computer-readable recording medium having a program recorded thereon for executing the embodiments described above.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.
한편, 본 발명의 영상 처리 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.On the other hand, the image processing method of the present invention can be implemented as a processor-readable code on a processor-readable recording medium provided in the network device. The processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. . The processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.In addition, although the preferred embodiment of the present invention has been shown and described above, the present invention is not limited to the above-described specific embodiment, the technical field to which the invention belongs without departing from the spirit of the invention claimed in the claims. Of course, various modifications can be made by those skilled in the art, and these modifications should not be individually understood from the technical spirit or the prospect of the present invention.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양 발명의 설명은 보충적으로 적용될 수가 있다.In addition, in this specification, both the object invention and the method invention are described, and description of both invention can be supplementally applied as needed.
발명의 실시를 위한 형태는 위의 발명의 실시를 위한 최선의 형태에서 함께 기술되었다.Embodiments for carrying out the invention have been described together in the best mode for carrying out the above invention.
본원 발명은 방송 및 비디오 신호 처리 분야에서 사용 가능하고 반복 가능성이 있는 산업상 이용가능성이 있다.The present invention has industrial applicability that is usable and repeatable in the field of broadcast and video signal processing.

Claims (14)

  1. 미디어 세그먼트들에 대한 세그먼트 URL (Uniform Resource Locator) 정보와 상기 미디어 세그먼트들의 프리젠테이션을 위한 타이밍 정보를 포함하는 미디어 프리젠테이션 디스크립션 정보를 수신하여 저장하고, 멀티캐스트와 유니캐스트 중 적어도 하나를 통해 전송되는 미디어 세그먼트들을 수신하여 저장하며, 상기 저장된 미디어 세그먼트들 중 컨텐트 재생을 위해 요청되는 미디어 세그먼트를 출력하는 단계;Receives and stores media presentation description information including segment Uniform Resource Locator (URL) information for media segments and timing information for presentation of the media segments, and is transmitted through at least one of multicast and unicast. Receiving and storing media segments, and outputting a media segment of the stored media segments required for content playback;
    상기 멀티캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보와 상기 유니캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보를 포함하는 콘트롤 메시지를 수신하는 단계; 및A control message including at least one URL base pattern information for identifying at least one media segment transmitted in the multicast and at least one URL base pattern information for identifying at least one media segment transmitted in the unicast. Receiving; And
    상기 수신된 콘트롤 메시지에 포함된 각 URL 베이스패턴 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 세그먼트 URL 정보를 업데이트하는 단계를 포함하는 미디어 서비스 수신 방법.And updating segment URL information in the stored media presentation description information based on each URL base pattern information included in the received control message.
  2. 제 1 항에 있어서, The method of claim 1,
    상기 콘트롤 메시지는 상기 멀티캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 포함하는 리프리젠테이션의 우선 순위 정보와 상기 유니캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 포함하는 리프리젠테이션의 우선 순위 정보를 더 포함하는 것을 특징으로 하는 미디어 서비스 수신 방법.The control message further includes priority information of a representation including at least one media segment transmitted in the multicast and priority information of a representation including at least one media segment transmitted in the unicast. Media service receiving method, characterized in that.
  3. 제 1 항에 있어서, The method of claim 1,
    상기 콘트롤 메시지는 상기 멀티캐스트를 통해 적어도 하나의 미디어 세그먼트를 전송하는 전송 세션의 IP (Internet Protocol) 어드레스 정보와 포트 정보를 더 포함하는 것을 특징으로 하는 미디어 서비스 수신 방법.The control message may further include IP (Internet Protocol) address information and port information of a transport session for transmitting at least one media segment through the multicast.
  4. 제 1 항에 있어서, The method of claim 1,
    상기 콘트롤 메시지는 서비스 식별 정보를 더 포함하며, 상기 서비스 식별 정보는 서비스 엔트리, 컴포넌트 레벨의 어뎁테이션 셋 식별자 및 서비스 레벨의 미디어 프리젠테이션 디스크립션 식별자 중 어느 하나인 것을 특징으로 하는 미디어 서비스 수신 방법.The control message further includes service identification information, wherein the service identification information is any one of a service entry, an adaptation set identifier of a component level, and a media presentation description identifier of a service level.
  5. 제 1 항에 있어서, The method of claim 1,
    상기 콘트롤 메시지는 HTTP restful API 메시지 형태로 수신되는 것을 특징으로 하는 미디어 서비스 수신 방법.And the control message is received in the form of an HTTP restful API message.
  6. 제 1 항에 있어서, The method of claim 1,
    상기 콘트롤 메시지는 타이밍 보상 정보를 더 포함하며, 상기 타이밍 보상 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 타이밍 정보를 업데이트하여 세그먼트 프리젠테이션 타임을 조정하는 단계를 더 포함하는 것을 특징으로 하는 미디어 서비스 수신 방법.The control message further includes timing compensation information, and the method further comprises updating timing information in the stored media presentation description information based on the timing compensation information to adjust the segment presentation time. Receiving method.
  7. 미디어 세그먼트들에 대한 세그먼트 URL (Uniform Resource Locator) 정보와 상기 미디어 세그먼트들의 프리젠테이션을 위한 타이밍 정보를 포함하는 미디어 프리젠테이션 디스크립션 정보를 전송하고, 멀티캐스트와 유니캐스트 중 적어도 하나를 통해 전송되는 미디어 세그먼트들을 전송하는 전송 서버;Media segment description information including segment URL (Uniform Resource Locator) information for the media segments and the timing information for the presentation of the media segments, and transmitted through at least one of multicast and unicast A transmission server for transmitting the sound;
    상기 미디어 프리젠테이션 디스크립션 정보를 수신하여 저장하고, 상기 미디어 세그먼트들을 수신하여 저장하며, 상기 저장된 미디어 세그먼트들 중 컨텐트 재생을 위해 요청되는 미디어 세그먼트를 출력하는 멀티캐스트 게이트웨이; 및A multicast gateway that receives and stores the media presentation description information, receives and stores the media segments, and outputs a media segment requested for content playback among the stored media segments; And
    상기 멀티캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보와 상기 유니캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 식별하기 위한 적어도 하나의 URL 베이스패턴 정보를 포함하는 콘트롤 메시지를 생성하여 전송하는 네트워크 콘트롤러를 포함하며, A control message including at least one URL base pattern information for identifying at least one media segment transmitted in the multicast and at least one URL base pattern information for identifying at least one media segment transmitted in the unicast. It includes a network controller for generating and transmitting a,
    상기 멀티캐스트 게이트웨이는 상기 콘트롤 메시지를 수신하고, 상기 콘트롤 메시지에 포함된 각 URL 베이스패턴 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 세그먼트 URL 정보를 업데이트하는 것을 특징으로 하는 미디어 서비스 장치.The multicast gateway receives the control message and updates the segment URL information in the stored media presentation description information based on the URL base pattern information included in the control message.
  8. 제 7 항에 있어서, The method of claim 7, wherein
    상기 콘트롤 메시지는 상기 멀티캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 포함하는 리프리젠테이션의 우선 순위 정보와 상기 유니캐스트로 전송되는 적어도 하나의 미디어 세그먼트를 포함하는 리프리젠테이션의 우선 순위 정보를 더 포함하는 것을 특징으로 하는 미디어 서비스 장치.The control message further includes priority information of a representation including at least one media segment transmitted in the multicast and priority information of a representation including at least one media segment transmitted in the unicast. Media service apparatus, characterized in that.
  9. 제 7 항에 있어서, The method of claim 7, wherein
    상기 콘트롤 메시지는 상기 멀티캐스트를 통해 적어도 하나의 미디어 세그먼트를 전송하는 전송 세션의 IP (Internet Protocol) 어드레스 정보와 포트 정보를 더 포함하는 것을 특징으로 하는 미디어 서비스 장치.The control message may further include IP (Internet Protocol) address information and port information of a transport session for transmitting at least one media segment through the multicast.
  10. 제 7 항에 있어서, The method of claim 7, wherein
    상기 콘트롤 메시지는 서비스 식별 정보를 더 포함하며, 상기 서비스 식별 정보는 서비스 엔트리, 컴포넌트 레벨의 어뎁테이션 셋 식별자 및 서비스 레벨의 미디어 프리젠테이션 디스크립션 식별자 중 어느 하나인 것을 특징으로 하는 미디어 서비스 장치.The control message further includes service identification information, wherein the service identification information is one of a service entry, a component level adaptation set identifier and a service level media presentation description identifier.
  11. 제 7 항에 있어서, The method of claim 7, wherein
    상기 콘트롤 메시지는 HTTP restful API 메시지 형태로 전송되는 것을 특징으로 하는 미디어 서비스 장치.The control message is a media service device, characterized in that transmitted in the form of HTTP restful API message.
  12. 제 7 항에 있어서, The method of claim 7, wherein
    상기 콘트롤 메시지는 타이밍 보상 정보를 더 포함하며, The control message further includes timing compensation information,
    상기 멀티캐스트 게이트웨이는 상기 타이밍 보상 정보를 기반으로 상기 저장된 미디어 프리젠테이션 디스크립션 정보 내 타이밍 정보를 업데이트하여 세그먼트 프리젠테이션 타임을 조정하는 것을 특징으로 하는 미디어 서비스 장치.And the multicast gateway adjusts a segment presentation time by updating timing information in the stored media presentation description information based on the timing compensation information.
  13. 제 7 항에 있어서, The method of claim 7, wherein
    상기 멀티캐스트 게이트웨이는 홈 게이트웨이와 커넥티드 셋톱박스 중 적어도 하나에 위치되는 것을 특징으로 하는 미디어 서비스 장치.The multicast gateway is located in at least one of a home gateway and a connected set-top box.
  14. 제 7 항에 있어서, The method of claim 7, wherein
    상기 멀티캐스트 게이트웨이가 프록시 서버로 동작하면, 상기 프록시 서버는 인-게이트웨이 트랜스페어런트 프록시(transparent proxy) 모드로 동작하는 것을 특징으로 하는 미디어 서비스 장치.And when the multicast gateway operates as a proxy server, the proxy server operates in an in-gateway transparent proxy mode.
PCT/KR2018/006479 2017-06-07 2018-06-07 Method for transmitting and receiving broadcast signal and apparatus therefor WO2018226045A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE112018002893.3T DE112018002893T5 (en) 2017-06-07 2018-06-07 Method for transmitting and receiving a broadcast signal and an apparatus therefor

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201762516119P 2017-06-07 2017-06-07
US62/516,119 2017-06-07
US201762539555P 2017-08-01 2017-08-01
US62/539,555 2017-08-01

Publications (1)

Publication Number Publication Date
WO2018226045A1 true WO2018226045A1 (en) 2018-12-13

Family

ID=64567303

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/006479 WO2018226045A1 (en) 2017-06-07 2018-06-07 Method for transmitting and receiving broadcast signal and apparatus therefor

Country Status (2)

Country Link
DE (1) DE112018002893T5 (en)
WO (1) WO2018226045A1 (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100828066B1 (en) * 2006-12-07 2008-05-08 한국전자통신연구원 Method of multimedia broadcast and multicast service through the wireless and mobile communication network
KR20140114035A (en) * 2012-01-16 2014-09-25 퀄컴 인코포레이티드 Method and system for transitions of broadcast dash service receptions between unicast and broadcast
KR20160048202A (en) * 2013-09-03 2016-05-03 후아웨이 테크놀러지 컴퍼니 리미티드 Method and device for transmitting media stream and user equipment
KR20160106618A (en) * 2014-01-03 2016-09-12 브리티쉬브로드캐스팅코퍼레이션 Content delivery
KR20170026483A (en) * 2014-07-30 2017-03-08 엘지전자 주식회사 Broadcast transmission device, broadcast reception device, method for operating broadcast transmission device, and method for operating broadcast reception device

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100828066B1 (en) * 2006-12-07 2008-05-08 한국전자통신연구원 Method of multimedia broadcast and multicast service through the wireless and mobile communication network
KR20140114035A (en) * 2012-01-16 2014-09-25 퀄컴 인코포레이티드 Method and system for transitions of broadcast dash service receptions between unicast and broadcast
KR20160048202A (en) * 2013-09-03 2016-05-03 후아웨이 테크놀러지 컴퍼니 리미티드 Method and device for transmitting media stream and user equipment
KR20160106618A (en) * 2014-01-03 2016-09-12 브리티쉬브로드캐스팅코퍼레이션 Content delivery
KR20170026483A (en) * 2014-07-30 2017-03-08 엘지전자 주식회사 Broadcast transmission device, broadcast reception device, method for operating broadcast transmission device, and method for operating broadcast reception device

Also Published As

Publication number Publication date
DE112018002893T5 (en) 2020-02-20

Similar Documents

Publication Publication Date Title
WO2013089437A1 (en) Device and method for receiving media content
WO2016018042A1 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
WO2012060581A2 (en) Method for transreceiving media content and device for transreceiving using same
WO2013055191A2 (en) Apparatus and method for configuring control message in broadcasting system
WO2012011724A2 (en) Method for transceiving media files and device for transmitting/receiving using same
WO2015160137A1 (en) Broadcast signal transmitting apparatus, broadcast signal receiving apparatus, broadcast signal transmitting method and broadcast signal receiving method
WO2013141666A1 (en) Hybrid delivery method and reception method for mmt packaged svc video contents
WO2014171718A1 (en) Broadcasting transmission device, broadcasting reception device, operating method of broadcasting transmission device and operating method of broadcasting reception device
WO2011132883A2 (en) Method for transmitting/receiving internet-based content and transmitter/receiver using same
WO2016105090A1 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broadcast signal reception method
WO2010082783A2 (en) Non-real-time service processing method and a broadcasting receiver
WO2011034283A1 (en) Method of processing epg metadata in network device and the network device for controlling the same
WO2011132879A2 (en) Method for transmitting/receving internet-based content and transmitter/receiver using same
WO2010123248A2 (en) Method for transmitting an iptv streaming service by p2p transmission, and method for receiving an iptv streaming service by p2p transmission
WO2012011722A2 (en) Method for transmitting/receiving media and device for transmitting/receiving using same
WO2018174367A1 (en) Broadcast signal transmitting and receiving method and device
WO2019212318A1 (en) Broadcast signal transmission device, broadcast signal transmission method, broadcast signal reception method, and broadcast signal reception device
WO2011002147A1 (en) Method of processing data on epg in service provider connected to network and digital broadcast receiver of processing data on epg
WO2017209574A1 (en) Method and device for providing media content
WO2011132882A2 (en) Method for transmitting/receiving internet-based content and transmitter/receiver using same
WO2018101566A1 (en) Broadcast signal transmitting/receiving device and method
WO2022005102A1 (en) Method and apparatus for processing multicast signal
WO2010079907A2 (en) System, method, and computer readable recording medium for providing two-way service in digital cable broadcasting environment
WO2016178494A1 (en) Broadcast signal transmission device, broadcast signal reception device, broadcast signal transmission method, and broacast signal reception method
WO2022197169A1 (en) Multicast signal processing method and device

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: 18812613

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 18812613

Country of ref document: EP

Kind code of ref document: A1