[go: up one dir, main page]

WO2022098070A1 - 멀티캐스트 신호 처리 방법 및 장치 - Google Patents

멀티캐스트 신호 처리 방법 및 장치 Download PDF

Info

Publication number
WO2022098070A1
WO2022098070A1 PCT/KR2021/015747 KR2021015747W WO2022098070A1 WO 2022098070 A1 WO2022098070 A1 WO 2022098070A1 KR 2021015747 W KR2021015747 W KR 2021015747W WO 2022098070 A1 WO2022098070 A1 WO 2022098070A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
network
service
information
gateway
Prior art date
Application number
PCT/KR2021/015747
Other languages
English (en)
French (fr)
Inventor
권우석
윤준희
Original Assignee
엘지전자 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엘지전자 주식회사 filed Critical 엘지전자 주식회사
Priority to EP21889535.7A priority Critical patent/EP4243429A4/en
Priority to US18/030,179 priority patent/US12231704B2/en
Publication of WO2022098070A1 publication Critical patent/WO2022098070A1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1023—Media gateways
    • H04L65/103—Media gateways in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/148—Migration or transfer of sessions

Definitions

  • the present invention relates to an apparatus and method for processing a multicast signal.
  • a multicast transmission method for transmitting the same content to a plurality of users is effective because advantages of both unicast and broadcast can be utilized.
  • the existing multicast transmission method was only possible within a single network, and there was a disadvantage that multicast service between heterogeneous networks was impossible. For this reason, when the multicast receiving device connects and disconnects from different access networks, there is a problem in that a new multicast service must be started after the existing multicast service is terminated.
  • a plurality of transport protocols it is impossible to identify using a port number if the protocol constituting the payload on IP/UDP or IP/TCP is not registered with IANA.
  • the destination address and port number use the values assigned to multicast, so all receivers receive the corresponding packet. There is this.
  • An object of the present invention is to increase transmission efficiency in a method and apparatus for transmitting a multicast signal.
  • a multicast signal processing method may include generating multicast media data; generating signaling information for multicast media data; transmitting multicast media data in a multicast manner based on at least one of a first network and a second network; and transmitting signaling information for multicast media data; may include
  • a multicast signal processing apparatus includes a memory; and a processor coupled to the memory; The processor may be configured to receive the multicast media data based on at least one of the first network or the second network, and decode the multicast media data.
  • a media architecture for multicast media streaming based on a plurality of networks is presented, so that the same level of media service is possible in multiple networks to which the DVB Multicast ABR structure can be applied.
  • multicast content can be received through various access methods without depending on a network to which a receiving device is connected during multicast streaming.
  • the same level of ABR multicast service can be provided.
  • ABR adaptive bitrate
  • FIG. 2 illustrates a multicast rendezvous service-based presentation manifest acquisition process according to embodiments.
  • FIG. 3 shows a structure for a multicast rendezvous service according to embodiments.
  • FIG. 4 shows a structure for a multicast rendezvous service according to embodiments.
  • 5-6 show a flow diagram of multicast-based media reception according to embodiments.
  • FIG. 9 shows a multicast application method for 5G media streaming according to embodiments.
  • FIG. 10 shows a multitask streaming structure for both multicast network and communication network streaming according to embodiments.
  • FIG. 11 illustrates an architecture for wireless media transmission based on multicast and broadcast in a communication network according to embodiments.
  • 16 shows an example of multiple networks to which an apparatus connects according to embodiments.
  • 17, 18, and 19 are flowcharts for changing a network according to embodiments.
  • FIG. 20 shows an example in which a multicast server and a multicast gateway are configured in each network according to embodiments.
  • 21, 22, and 23 show a network change flow chart according to embodiments.
  • FIG. 24 shows an example in which a multicast server and a multicast gateway are configured in each network according to the embodiments.
  • FIG. 28 shows an example in which a single multicast server is serviced for a plurality of heterogeneous networks, and a multicast gateway for this is configured in each network according to the embodiments.
  • 29, 30, and 31 show a network change flow chart according to embodiments.
  • FIG. 32 shows an example in which a single multicast server is serviced for a plurality of heterogeneous networks, and a multicast gateway for this configures each network according to embodiments.
  • 33, 34, and 35 show a network change flow chart according to embodiments.
  • 36 illustrates an example in which all multicast rendezvous services are configured in co-located deployment when a multicast server and a multicast gateway are configured in each network according to the embodiments.
  • 40-41 show an embodiment in which a device accesses various serviceable networks when a multicast server and a multicast gateway are configured in each network according to the embodiments.
  • 45 shows an embodiment of a protocol that can be configured in a receiving device to access a plurality of networks according to embodiments.
  • FIG. 48 illustrates a method of generating and transmitting a service list and presentation manifest for ABR multicast according to embodiments.
  • 49 shows service list and presentation manifest management according to embodiments.
  • 50 shows a service list according to embodiments.
  • 51 illustrates a multicast session according to embodiments.
  • FIG. 52 illustrates an element included in a Request URL of an HTTP message according to embodiments.
  • 58, 59, 60, 61, 62, and 63 show a service provider change flow chart according to embodiments.
  • 64 shows a 5G system service infrastructure structure according to embodiments.
  • 65 shows a 5G system structure in a reference point representation according to embodiments.
  • 66 shows a 5G system structure for multiple PDU sessions according to embodiments.
  • 67 shows a 5G system structure for coexisting access to two data networks according to embodiments.
  • 68 illustrates a user plane protocol stack according to embodiments.
  • UDM Unified Data Management
  • 70 shows a structure for 5G media streaming according to embodiments.
  • 71 illustrates a Media Architecture for unicast downlink media streaming according to embodiments.
  • 73 shows a reference structure according to embodiments.
  • 75 shows a structure of a multicast gateway distributed in a home gateway device according to embodiments.
  • 76 shows a structure of a multicast gateway distributed in a terminal device according to embodiments.
  • 77 shows a hybrid broadcast receiving apparatus according to embodiments.
  • 79 shows a multicast signal processing method according to embodiments.
  • a multicast signal processing method/apparatus relates to a media transmission method in an adaptive bitrate multicast network.
  • Media may be referred to as a media signal, media data, or the like, and may be interpreted as a term corresponding to or including a service or service data.
  • the embodiments propose an architecture for media streaming in an IP (Internet Protocol)-based media delivery system.
  • IP Internet Protocol
  • the embodiments propose a media streaming architecture for multicast application when an IP-based media transmission system is configured with a plurality of networks.
  • the embodiments propose an ABR Multicast method when an IP-based media transmission system is configured with a plurality of networks.
  • the embodiments propose a service list receiving method (flow) and device (device, multicast signal processing apparatus according to embodiments) operation when an IP-based media transmission system is configured with a plurality of networks.
  • Embodiments propose signaling information necessary for a receiver (device) on a plurality of networks.
  • a multicast ABR architecture according to the configuration of a content provider and a service provider corresponding to a multicast signal processing apparatus according to embodiments is proposed.
  • the embodiments provide a media architecture for multicast media streaming based on a plurality of networks, so that the DVB Multicast ABR structure can be applied, and the same level of media service is available in multiple networks.
  • multicast content can be received through various access methods without depending on the network to which the receiving device is connected.
  • the ABR multicast structure defined in DVB is mainly defined when the multicast network is a single network.
  • 5G network wireless network
  • Multicast technology provides services in various network environments for universal media streaming, and transmission is possible in most IP-based networks.
  • a function and architecture adapted to each network are required.
  • the ABR multicast service is provided through multiple networks, it is necessary to define the transmission of the service list and its management plan in order to provide continuity to the service from the user's point of view.
  • This document describes the architecture and the interface for the DVB ABR multicast structure to be serviced through various networks.
  • a method for providing a service list through a plurality of networks and an interface and flow for processing the service list in the device are described.
  • ABR adaptive bitrate
  • the method/apparatus for processing a multicast signal may transmit media contents by multicast based on the structure shown in FIG. 1 .
  • Media content according to embodiments may be referred to as multicast media, multicast media data, service data, and the like.
  • Each component in FIG. 1 corresponds to hardware, software, a processor, and/or a combination thereof.
  • the interface of FIG. 1 may be defined as follows.
  • L A unicast interface (Unicast HTTP(S) interface) between a content playback function and a multicast gateway.
  • B It is a bootstrap unicast HTTP(S) interface between a content playback function and a multicast bootstrap function. It can be used to request an initial presentation manifest.
  • M This is an interface for the multicast server to transmit multicast IP contents and for the multicast gateway to receive it.
  • Ingest Interface to provide media contents to Multicast Server.
  • CMS Control interface for configuring Multicast server.
  • CMR Control interface for configuring multicast gateway.
  • Configuration Interface for exchanging configuration information between Content Provider, Provisioning, and Multicast Bootstrap functions.
  • Each module in FIG. 1 can be defined as follows. Each module may correspond to hardware, software, a processor, and/or a combination thereof.
  • Multicast and unicast transmission methods can be used to transmit media content to users, and media content data and control information are provided to the multicast server through an ingest interface for multicast transmission.
  • Media content data may be packaged in a format such as DASH or HLS, and a presentation manifest may be configured according to the packaging format.
  • Multicast Server Receives media content from the content provider and transmits it to the Multicast Gateway through the M interface using the IP Multicast transmission method. In this case, some control information may be transmitted together.
  • the multicast protocol may consider ROUTE, FLUTE, QUIC, RTP, and the like.
  • Multicast Gateway - Receives a packaged content segment transmitted by Multicast, and provides it to the Content playback function through the L interface through HTTP(S) method, etc.
  • the content segment is cached (cache)
  • a content segment may mean segmented media data It is possible to store (cache) segmented media data.
  • Provisioning (Network Control) - Provides configuration information for network and multicast streaming session to multicast server and multicast gateway.
  • Multicast Bootstrap The content playback function can process by targeting address information (url or address) to be initially accessed through the B interface. Handles the initial request for the presentation manifest coming from the content playback function via reference point B.
  • address information url or address
  • redirection information for receiving the manifest through the L interface is provided, and in the case of unicast, redirection information for receiving the manifest through the U interface is provided.
  • a multicast rendezvous service function may be performed in the DVB ABR multicast structure.
  • the content playback function manages content request, reception, decoding, presentation, and the like. Transmission of unicast through interface L may be considered.
  • Application - Application controls the content playback function based on user input.
  • it may be a built-in control application (EPG application) of a TV or set-top box, or a third-party application provided by a content provider.
  • EPG application built-in control application
  • the interface used by the application to control content playback may be implemented as a separate API, etc. according to each device.
  • the multicast signal processing method/apparatus includes a multicast server and a multicast gateway, or further includes a content provider, provisioning, multicast bootstrap unit, etc. may include
  • the multicast signal processing method/apparatus may include a content playback unit, an application, and the like in terms of performing an operation of receiving media.
  • FIG. 2 illustrates a multicast rendezvous service-based presentation manifest acquisition process according to embodiments.
  • the multicast signal processing method/apparatus according to the embodiments of FIG. 1 may perform a multicast rendezvous service as shown in FIG. 2 .
  • Each component in FIG. 2 corresponds to hardware, software, a processor, and/or a combination thereof.
  • a content playback function requests contents from a multicast gateway when receiving multicast, and receives content from content hosting in case of unicast reception.
  • a multicast rendezvous service can be accessed first through a reference point B. .
  • the multicast rendezvous service may provide a content playback function with a URL from which a presentation manifest can be appropriately obtained according to multicast and unicast.
  • FIG. 3 shows a structure for a multicast rendezvous service according to embodiments.
  • the multicast method/device may execute a rendezvous service as shown in FIG. 3 .
  • Each component in FIG. 3 corresponds to hardware, software, a processor, and/or a combination thereof.
  • Multicast rendezvous service may be configured in regular deployment and co-located deployment depending on whether HTTP(s) and unidirectional transmission are supported. .
  • the content playback function of the multicast signal processing apparatus may acquire manifest url information and configure for media reception through the following operation.
  • the multicast rendezvous service is located in the network and corresponds to a configuration managed and controlled by a system operator.
  • the content playback function may acquire manifest url information for receiving contents from the multicast rendezvous service through the reference point B when first accessing the contents desired to be received. For this, the following configuration can be made.
  • a configuration for a set of basic parameters (for example, the endpoint address of a multicast gateway, this configuration transport session, etc.) can be applied to the multicast gateway.
  • an in-band multicast gateway configuration method may be used.
  • a configuration for a set of a reference point CMR (reference point CMR) or a multicast session currently provisioned through a reference point CMS and M may be applied to the multicast gateway.
  • These configurations include in-band multicast gateway configuration methods as well as out-of-band push configuration, out-of-band pull configuration, and just-in-time configuration methods (out-of-band pushed configuration, out-of-band). pulled configuration, Just-in-time configuration method) may be applied.
  • FIG. 4 shows a structure for a multicast rendezvous service according to embodiments.
  • FIG. 4 shows a case in which a co-located deployment is performed further from FIG. 3 .
  • a multicast rendezvous service may be configured in the same device as a multicast gateway (a multicast processing device according to embodiments). It can be mainly used when the multicast ABR network is configured in a unidirectional deployment.
  • a multicast gateway a multicast processing device according to embodiments. It can be mainly used when the multicast ABR network is configured in a unidirectional deployment.
  • Each component in FIG. 4 corresponds to hardware, software, a processor, and/or a combination thereof.
  • the content playback function may acquire manifest url information for receiving contents from the multicast rendezvous service through the reference point B when first accessing the contents desired to be received. For this, the following configuration can be made.
  • a configuration for a set of basic parameters (eg, an endpoint address of a multicast gateway configuration transport session, etc.) may be applied to the Multicast rendezvous service.
  • the configuration for the multicast session set currently provisioned through the reference point M can be applied to the multicast gateway.
  • an in-band multicast gateway configuration method may be used for each configuration.
  • 5-6 show a flow diagram of multicast-based media reception according to embodiments.
  • a multicast signal processing method/apparatus may receive multicast media based on the following flowchart.
  • a corresponding application may obtain a URL to request an initial presentation manifest through a service directory, etc. (5000 ).
  • the URL indicates a multicast rendezvous service.
  • the application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the multicast rendezvous service.
  • the content playback function requests a presentation manifest from the multicast rendezvous service through the reference point B using the URL obtained from the application (5001).
  • the multicast rendezvous service checks the status of the multicast gateway and, if the service for the requested presentation manifest is defined in the multicast configuration, transmits the redirection URL for the multicast gateway to the content playback function (5002).
  • the multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway according to the redirection (5003).
  • the presentation manifest is previously cached in the multicast gateway, the corresponding presentation manifest is transmitted to the content playback function (5004).
  • the presentation manifest is not cached in the multicast gateway, the corresponding presentation manifest can be retrieved from the content hosting function through reference point A, and it is transmitted back to the content playback function.
  • the content playback function may receive the media segment for the corresponding contents through the multicast gateway based on the received presentation manifest.
  • Host FQDN (or IP address) and optionally the port number of the multicast rendezvous service.
  • ManifestPath The resource path to retrieve the presentation manifest on the specified host.
  • AToken This value is an authentication token that authorizes access to the multicast rendezvous service if requested by the system operator. This may have been included in the original presentation manifest URL, added by a third-party CDN broker as part of a previous HTTP redirect URL, or generated locally by the application.
  • MGid This value is the port number of the multicast gateway, optionally preceded by an IP address: in the format [IP address]:port.
  • the MGhost: value is the multicast gateway hostname.
  • This value is the hostname (FQDN) of the original destination host.
  • the application can replace the original destination hostname (FQDN) with the local multicast rendezvous service hostname or address. Also, if you rely on a third-party CDN broker, the latter can indicate the original destination hostname (FQDN) here before redirecting the request to the multicast rendezvous service.
  • FQDN original destination hostname
  • Redirect URL of Location response header is as follows:
  • Host The IP address or FQDN of the multicast gateway and optionally a port number (eg "router.example:8088” or "192.0.2.1:8088").
  • Session ID A unique presentation session identifier that may be delivered and generated by the multicast rendezvous service including one or more URL path elements.
  • ManifestPath The resource path to retrieve the presentation manifest on the specified host.
  • the conf: multicast session parameter takes the form of a multicast gateway configuration instance document containing one multicast session.
  • Documents are compressed using Gzip and base64url encoding before being included as URL query string parameters.
  • the multicast rendezvous service can redirect the request to the multicast gateway as follows:
  • the URL corresponding to the Location field of the HTTP header may include a session identifier and a query parameter for piggybacking a multicast gateway configuration instance document including a multicast session corresponding to the requested presentation manifest.
  • Multicast ABR may be connected to a 5G network (communication network).
  • 5G network communication network
  • FIG. 9 shows a multicast application method for 5G media streaming according to embodiments.
  • the multicast signal processing method/apparatus may support multicast in a 5G media streaming structure (Multicast ABR architecture).
  • Multicast ABR architecture shows an embodiment of a 5G media streaming architecture to which a multicast ABR architecture is applied. That is, the 5G structure and the DVB structure may be combined with each other.
  • the 5G application provider (5GMSd Application Provider) may be the same as the Content Provider of Multicast ABR shown in FIGS. 1-6 and the like, or may be a part of the Content Provider.
  • the application (5GMSd Aware Application) for receiving the corresponding 5G media streaming may be the same as the application of Multicast ABR shown in FIGS. 1-6, etc., or may be a part of the application.
  • the client (5GMSd Client) may be the same as the content playback function of the Multicast ABR of FIGS. 1-5 and the like, or may be a part of the content playback function.
  • the control unit 5GMSd AF may include a provisioning function including a network control sub function of the multicast ABR shown in FIGS. 1-6 and the like, and a multicast bootstrap function including a multicast rendezvous service.
  • Access information (presentation manifest url) for the 5GMSd Client to transmit the first multicast may be requested and received through the M5d interface, which may correspond to the B interface of the Multicast ABR of FIGS. 1-6 and the like.
  • Unicast streaming is transmitted from 5GMSd AS to Media Player through M4d interface, and in this case, HTTP(s) may be used.
  • Multicast server and Multicast Gateway can be configured for multicast transmission between 5GMSd AS and Media Player. Since data is transmitted through 5G RAN between Multicast Gateway and Media Player, only Unicast can be supported.
  • interfaces M4d_M and M4d_L can be defined as follows.
  • M4d_M - Multicast streaming is transmitted from 5GMSd AS to multicast server through M4d_M interface, and M interface defined in multicast ABR can be used between multicast server and multicast gateway.
  • M interface defined in multicast ABR can be used between multicast server and multicast gateway.
  • a multicast server function may be included in the 5GMS AS.
  • the M4d_M interface may be omitted.
  • the protocol defined in the M interface can be used.
  • M4d_L - M4d_L interface can be used between multicast gateway and media player.
  • M4d_M and M4d_L may use a protocol based on HTTP(s), and from the viewpoint of DVB Multicast ABR, M4d_M may correspond to an ingest interface, and M4d_L may correspond to an L interface.
  • FIG. 10 shows a multitask streaming structure for both multicast network and communication network streaming according to embodiments.
  • the multicast signal processing method/apparatus may transmit/receive and process media content when multicast streaming is simultaneously serviced in the DVB multicast ABR network and 5G media streaming.
  • Each component in FIG. 10 corresponds to hardware, software, a processor, and/or a combination thereof.
  • a use case of simultaneous multicast service through a 5G mobile network and other IP networks from the same content provider can be considered.
  • 10 illustrates an embodiment in which multicast streaming is simultaneously serviced to a 5G network and a DVB multicast ABR network.
  • Multicast interface M that delivers media from multicast server to multicast gateway can be configured in the same way.
  • the M2d and M4d_M interfaces defined in the 5G network may be the same interface as the Ingest interface. For this reason, the content provider can maintain the same protocol transmitted through each network.
  • FIG. 11 illustrates an architecture for wireless media transmission based on multicast and broadcast in a communication network according to embodiments.
  • a multicast gateway may be configured inside the 5G UE.
  • Each component in Fig. 11 corresponds to hardware, software, a processor, and/or a combination thereof.
  • 5GMSd Application Provider may be the same as Content Provider of Multicast ABR or may be a part of Content Provider.
  • the 5GMSd Aware Application for receiving the corresponding 5G media streaming may be the same as the Multicast ABR Application or may be a part of the Application.
  • 5GMSd Client may be the same as the content playback function of Multicast ABR, or may be a part of the content playback function.
  • 5GMSd AF may include a provisioning function including the network control sub function of Multicast ABR and a multicast bootstrap function including multicast rendezvous service.
  • Access information (presentation manifest url) for the 5GMSd Client to transmit multicast for the first time can be requested and received through the M5d interface, which may correspond to the B interface of Multicast ABR.
  • Unicast streaming is transmitted from 5GMSd AS to Media Player through M4d interface, and in this case, HTTP(s) may be used.
  • Multicast server and Multicast Gateway can be configured for multicast transmission between 5GMSd AS and Media Player.
  • the interface M4d_L between the Multicast Gateway and the Media Player can be implemented as an interface inside the UE.
  • Interface M4d_M between multicast server and multicast gateway can be defined as the same interface as M interface defined in multicast ABR. Therefore, as the multicast protocol, the protocol defined in the M interface may be used.
  • the method/device/processor (multicast signal processing method/device) according to the embodiments performs the above-described network control operations, and based on the related signaling information, provides a media architecture for multicast media streaming based on 5G network.
  • can Operations according to the embodiments provide an effect of receiving multicast content through various access methods without depending on a network to which a receiving device is connected during multicast streaming.
  • the same content can be transmitted to a plurality of receivers to efficiently use network resources.
  • Embodiments include a MABR architecture based on multiple IP networks.
  • Multiple IP networks may include various networks such as communication and broadcasting networks.
  • Each component included in the architecture according to the embodiments may correspond to hardware, software, a processor, and/or a combination thereof.
  • 9 to 11 correspond to the multicast signal processing method/apparatus according to the embodiments shown in FIGS. 1 to 6 .
  • FIGS. 12-13 show an embodiment of a structure in which a multicast server is configured for each network to provide an ABR multicast service. It mainly corresponds to the case where the multicast service server is deployed by the network operator.
  • the transceiver according to the embodiments may provide an ABR multicast service based on the multicast server structure shown in the following figure.
  • Each component in FIGS. 12-13 corresponds to hardware, software, a processor, and/or a combination thereof.
  • ABR multicast When ABR multicast is serviced through a plurality of heterogeneous networks, deployment of a multicast gateway that receives ABR multicast can be done separately.
  • Multicast gateway When multicast gateway is configured for ABR multicast service in ISP network, it can be configured in router or home gateway provided by ISP operator.
  • Multicast gateway (B) - When a multicast gateway is configured for ABR multicast service in a mobile network such as 5G system, it can be configured within the edge of the mobile network.
  • Multicast gateway When multicast gateway is configured for ABR multicast service in satellite broadcasting network, it can be configured in STB that can receive satellite broadcasting.
  • Multicast gateway (D) When multicast gateway is configured for ABR multicast service in Terrestrial Broadcast network, it can be configured in broadcast receiver.
  • the ABR multicast function can be configured independently for each network.
  • An embodiment of a structure in which a single multicast server provides ABR multicast service through a plurality of heterogeneous networks is shown. It mainly corresponds to the case where the multicast service server is deployed by the content provider.
  • the transceiver according to the embodiments may provide an ABR multicast service based on the multicast server structure shown in the following figure.
  • FIGS. 14-15 corresponds to hardware, software, a processor, and/or a combination thereof.
  • ABR multicast When ABR multicast is serviced through a plurality of heterogeneous networks, deployment of a multicast gateway that receives ABR multicast can be done separately.
  • Multicast gateway When multicast gateway is configured for ABR multicast service in ISP network, it can be configured in router or home gateway provided by ISP operator.
  • Multicast gateway (B) - When a multicast gateway is configured for ABR multicast service in a mobile network such as 5G system, it can be configured within the edge of the mobile network.
  • Multicast gateway When multicast gateway is configured for ABR multicast service in satellite broadcasting network, it can be configured in STB that can receive satellite broadcasting.
  • Multicast gateway (D) When multicast gateway is configured for ABR multicast service in Terrestrial Broadcast network, it can be configured in broadcast receiver.
  • the ABR multicast function can be configured independently for each network.
  • 16 shows an example of multiple networks to which an apparatus connects according to embodiments.
  • a method/apparatus for processing a multicast signal according to embodiments capable of receiving the same multicast media service by accessing a plurality of networks may be considered.
  • An architecture for a multicast signal processing method/device according to embodiments capable of receiving the same multicast streaming service by accessing a plurality of networks and an embodiment of an ABR multicast interface will be described. Embodiments may be implemented in various architectures.
  • a system may include a service provider, network(s), and a device.
  • a configuration of a service provider, network(s), and device according to embodiments is shown in FIG. 16 .
  • Each component in Fig. 16 corresponds to hardware, software, a processor, and/or a combination thereof.
  • a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • a case in which the device accesses the mobile network while simultaneously accessing Wi-Fi through the ISP network may be considered.
  • the content playback function in the device can consist of two L interfaces (L1, L2) and two B interfaces (B1, B2).
  • Media streaming can be received through the multicast gateway (A) through the L1 interface, and access information for the initial multicast gateway (A) can be received through the B1 interface.
  • Media streaming can be received through the multicast gateway (B) through the L2 interface, and access information for the initial multicast gateway (B) can be received through the B2 interface.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • FIGS. 1-6 and 9-11 show examples in which the multicast signal processing apparatus according to the embodiments, such as FIGS. 1-6 and 9-11, is configured according to types of networks according to the embodiments.
  • the following shows the flow of the process of receiving the same service even after the network is changed, following the process of acquiring the manifest and receiving multicast media for the device for this architecture.
  • Network change may include, for example, a change between network A (WI-FI) and network B (5G).
  • FIG. 17-19 The flowchart of Figs. 17-19 may be performed according to the embodiments shown in Figs. 1-6, 9-16, and the like. Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • the flow related to Multicast Server proceeds as follows.
  • Each function is deployed according to the architecture, and the configuration for multicast service is applied to multicast server, multicast gateway, and multicast rendezvous service.
  • the provisioning function delivers configuration information about the multicast session currently provisioned to the multicast server (A) and multicast server (B) through network control.
  • configuration information for a multicast session may be delivered.
  • the media segment is ingested from the content provider to the multicast server (A) and the multicast server (B), multicast transmission starts, and if there is a multicast gateway that can receive the media segment, it becomes available. .
  • the device When the device connects to network A, it can operate as follows.
  • Application can receive service list from service provider through network A.
  • the service list acquisition method defined in network A can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • a service list may be delivered through the service list element shown in FIG. 50 .
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to the Multicast rendezvous service (A).
  • the Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the Multicast rendezvous service (A).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (A) through the reference point B1 using the URL delivered from the application.
  • a manifest can be requested.
  • Multicast rendezvous service (A) checks the status of multicast gateway (A) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (A) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • Redirection may be performed through the manifest request and redirection information shown in FIG. 52 .
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (A) through the reference point L1 following the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server (A) to multicast gateway (A) through M1 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (A) and the media is played. If there is no separate control, media play continues.
  • the device changes the connection from network A to network B, it can operate as follows.
  • Application can receive service list from service provider through network B.
  • the service list acquisition method defined in network B can be used.
  • session information for the corresponding service ID can be exchanged.
  • the received service list may include a url to request a presentation manifest mapped to a service ID.
  • the application can obtain the URL to request the presentation manifest.
  • the URL points to the Multicast rendezvous service (B).
  • the Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the Multicast rendezvous service (B).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (B) through the reference point B2 using the URL delivered from the application.
  • Multicast rendezvous service (B) checks the status of multicast gateway (B) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (B) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (B) through the reference point L2 following the redirection.
  • the presentation manifest is cached in the multicast gateway (B) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server (B) to multicast gateway (B) through M2 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (B) and the media is played. If there is no separate control, media play continues.
  • FIG. 20 shows an example in which a multicast server and a multicast gateway are configured in each network according to embodiments.
  • Embodiments go further than the configuration of FIG. 16 and may include a network server and a gateway as shown in FIG. 20 .
  • a system according to embodiments may include a service provider, network(s), and a device.
  • a configuration of a service provider, network(s), and device according to embodiments is shown in FIG. 20 .
  • Each component in Fig. 20 corresponds to hardware, software, a processor, and/or a combination thereof.
  • a multicast server for each network, a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • a device accesses Wi-Fi through an ISP network and simultaneously accesses a set-top box through a satellite broadcasting network may be considered.
  • the content playback function in the device can consist of two L interfaces (L1, L2) and two B interfaces (B1, B2).
  • Media streaming can be received through the multicast gateway (A) through the L1 interface, and access information for the initial multicast gateway (A) can be received through the B1 interface.
  • Media streaming can be received through the multicast gateway (B) through the L2 interface, and access information for the initial multicast gateway (B) can be received through the B2 interface.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • 21, 22, and 23 show a network change flow chart according to embodiments.
  • FIG. 21-23 The flowchart of Figs. 21-23 may be performed according to the embodiments shown in Figs. 1-6, 9-16, 20, and the like. Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • the following shows the flow of the process of receiving the same service even after the network is changed, following the process in which the device acquires the manifest and receives the multicast media for the architecture according to the embodiments.
  • the difference from Figs. 17-19 is that the networks of Figs. 21-23 include a case in which one network is not a bidirectional network.
  • the flow related to Multicast Server proceeds as follows.
  • Each function is deployed according to the architecture, and the configuration for multicast service is applied to multicast server, multicast gateway, and multicast rendezvous service.
  • the provisioning function delivers configuration information about the multicast session currently provisioned to the multicast server (A) and multicast server (B) through network control.
  • the media segment is ingested from the content provider to the multicast server (A) and the multicast server (B), multicast transmission starts, and if there is a multicast gateway that can receive the media segment, it becomes available. .
  • the device When the device connects to network A, it can operate as follows.
  • Application can receive service list from service provider through network A.
  • the service list acquisition method defined in network A can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to the Multicast rendezvous service (A).
  • the Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the Multicast rendezvous service (A).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (A) through the reference point B1 using the URL delivered from the application.
  • Multicast rendezvous service (A) checks the status of multicast gateway (A) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (A) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (A) through the reference point L1 following the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server (A) to multicast gateway (A) through M1 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (A) and the media is played. If there is no separate control, media play continues.
  • the device changes the connection from network A to network B, it can operate as follows.
  • Application can receive service list from service provider through network B.
  • the service list acquisition method defined in network B can be used.
  • session information for the corresponding service ID can be exchanged.
  • the received service list may include a url to request a presentation manifest mapped to a service ID.
  • the application can obtain the URL to request the presentation manifest.
  • the URL points to the multicast gateway (B) and rendezvous service (B).
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to a multicast gateway (B) or a multicast rendezvous service (B).
  • the application controls the content playback function to start an operation for content reception, and in this case, a URL for a multicast gateway (B) or a multicast rendezvous service (B) can be delivered.
  • the following process can be selectively performed.
  • the content playback function requests a presentation manifest from the multicast rendezvous service (B) through the reference point B2 using the URL delivered from the application.
  • Multicast rendezvous service (B) checks the status of multicast gateway (B) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (B) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function receiving the redirection message follows the redirection.
  • a presentation manifest is requested from the multicast gateway (B) through the reference point L2.
  • the presentation manifest is cached in the multicast gateway (B) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server (B) to multicast gateway (B) through M2 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (B) and the media is played. If there is no separate control, media play continues.
  • FIG. 24 shows an example in which a multicast server and a multicast gateway are configured in each network according to the embodiments.
  • a system may include a service provider, network(s), and a device.
  • a configuration of a service provider, network(s), and device according to embodiments is shown in FIG. 24 .
  • Each component in Fig. 24 corresponds to hardware, software, a processor, and/or a combination thereof.
  • a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • a device accesses a set-top box through a satellite broadcasting network and simultaneously receives a broadcast through a terrestrial broadcasting network may be considered.
  • Network types according to embodiments may be different. Both can only be "one* networks.”
  • the content playback function in the device can consist of two L interfaces (L1, L2) and two B interfaces (B1, B2).
  • Media streaming can be received through the multicast gateway (A) through the L1 interface, and access information for the initial multicast gateway (A) can be received through the B1 interface.
  • Media streaming can be received through the multicast gateway (B) through the L2 interface, and access information for the initial multicast gateway (B) can be received through the B2 interface.
  • the L2 and B2 interfaces can be replaced with the device internal interfaces.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • FIG. 25-27 The flowchart of Figs. 25-27 may be performed according to the embodiments shown in Figs. 1-6, 9-16, 24, and the like. Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • the following shows the flow of the process of receiving the same service even after the network is changed, following the process in which the device acquires the manifest and receives the multicast media for the architecture according to the embodiments.
  • the flow related to Multicast Server proceeds as follows.
  • Each function is deployed according to the architecture, and the configuration for multicast service is applied to multicast server, multicast gateway, and multicast rendezvous service.
  • the provisioning function delivers configuration information about the multicast session currently provisioned to the multicast server (A) and multicast server (B) through network control.
  • the media segment is ingested from the content provider to the multicast server (A) and the multicast server (B), multicast transmission starts, and if there is a multicast gateway that can receive the media segment, it becomes available. .
  • the device When the device connects to network A, it can operate as follows.
  • Application can receive service list from service provider through network A.
  • the service list acquisition method defined in network A can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to a multicast gateway (A) or a multicast rendezvous service (A).
  • the application controls the content playback function to start an operation for content reception, and in this case, a URL for a multicast gateway (A) or a multicast rendezvous service (A) may be delivered.
  • the following process can be selectively performed.
  • the content playback function requests a presentation manifest from the multicast rendezvous service (A) through the reference point B1 using the URL delivered from the application.
  • Multicast rendezvous service (A) checks the status of multicast gateway (A) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (A) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function receiving the redirection message follows the redirection.
  • a presentation manifest is requested from the multicast gateway (A) through the reference point L1.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server (A) to multicast gateway (A) through M1 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (A) and the media is played. If there is no separate control, media play continues.
  • the device changes the connection from network A to network B, it can operate as follows.
  • Application can receive service list from service provider through network B.
  • the service list acquisition method defined in network B can be used.
  • session information for the corresponding service ID can be exchanged.
  • the received service list may include a url to request a presentation manifest mapped to a service ID.
  • interface L2 and B2 related operations can be selectively performed.
  • the application can obtain the URL to request the presentation manifest.
  • the URL points to the Multicast rendezvous service (B).
  • the Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the Multicast rendezvous service (B).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (B) through the reference point B2 using the URL delivered from the application.
  • Multicast rendezvous service (B) checks the status of multicast gateway (B) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (B) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (B) through the reference point L2 following the redirection.
  • the presentation manifest is cached in the multicast gateway (B) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server (B) to multicast gateway (B) through M2 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (B) and the media is played. If there is no separate control, media play continues.
  • the following further describes a method/apparatus for processing a multicast signal according to embodiments connectable to multiple networks.
  • a device capable of receiving the same multicast media service by connecting to a plurality of networks may be considered.
  • An embodiment of the architecture and ABR multicast interface for a device capable of receiving the same multicast streaming service by connecting to a plurality of networks will be described.
  • a multicast rendezvous service is different from a broadcast bootstram.
  • the rendezvous flow is a process in which the terminal provides the first network address to the terminal when the terminal wants to access the network.
  • the rendezvous function may be performed by the network according to the embodiments. Bootstrap may be performed by the terminal.
  • the rendezvous service may have a fixed address or URL. If the receiver is outside the network, the address for the media is redirected to the terminal because the terminal is connected to receive media when the terminal first connects. The terminal can receive the manifest for the actual media with the redirect address. In the multicast rendezvous service, since media transmission and reception is multicast method, the media is already watched by someone else, such a service is required.
  • FIG. 28 shows an example in which a single multicast server is serviced for a plurality of heterogeneous networks, and a multicast gateway for this is configured in each network according to the embodiments.
  • a system may include a service provider, network(s), and a device.
  • the configuration of the service provider, network(s), and device according to the embodiments is shown in FIG. 28 .
  • Each component in Fig. 28 corresponds to hardware, software, a processor, and/or a combination thereof.
  • a multicast server for each network, a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • a case in which the device accesses the mobile network while simultaneously accessing Wi-Fi through the ISP network may be considered.
  • the content playback function in the device can consist of two L interfaces (L1, L2) and two B interfaces (B1, B2).
  • Media streaming can be received through the multicast gateway (A) through the L1 interface, and access information for the initial multicast gateway (A) can be received through the B1 interface.
  • Media streaming can be received through the multicast gateway (B) through the L2 interface, and access information for the initial multicast gateway (B) can be received through the B2 interface.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • 29, 30, and 31 show a network change flow chart according to embodiments.
  • FIG. 29-31 The flowchart of Figs. 29-31 may be performed according to the embodiments shown in Figs. 1-6, 9-16, 28, and the like. Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • the following shows the flow of the process of receiving the same service even after the network is changed, following the process in which the device acquires the manifest and receives the multicast media for the architecture according to the embodiments.
  • the flow related to Multicast Server proceeds as follows.
  • Each function is deployed according to the architecture, and the configuration for multicast service is applied to multicast server, multicast gateway, and multicast rendezvous service.
  • the provisioning function delivers configuration information about the multicast session currently provisioned to the multicast server through network control.
  • the media segment is ingested from the content provider to the multicast server, multicast transmission starts, and if there is a multicast gateway that can receive the corresponding media segment, it becomes available for reception.
  • the device When the device connects to network A, it can operate as follows.
  • Application can receive service list from service provider through network A.
  • the service list acquisition method defined in network A can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to the Multicast rendezvous service (A).
  • the Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the Multicast rendezvous service (A).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (A) through the reference point B1 using the URL delivered from the application.
  • Multicast rendezvous service (A) checks the status of multicast gateway (A) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (A) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (A) through the reference point L1 following the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server to multicast gateway (A) through M1 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (A) and the media is played. If there is no separate control, media play continues.
  • the device changes the connection from network A to network B, it can operate as follows.
  • Application can receive service list from service provider through network B.
  • the service list acquisition method defined in network B can be used.
  • session information for the corresponding service ID can be exchanged.
  • the received service list may include a url to request a presentation manifest mapped to a service ID.
  • the application can obtain the URL to request the presentation manifest.
  • the URL points to the Multicast rendezvous service (B).
  • the Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the Multicast rendezvous service (B).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (B) through the reference point B2 using the URL delivered from the application.
  • Multicast rendezvous service (B) checks the status of multicast gateway (B) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (B) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (B) through the reference point L2 following the redirection.
  • the presentation manifest is cached in the multicast gateway (B) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server to multicast gateway (B) through M2 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (B) and the media is played. If there is no separate control, media play continues.
  • FIG. 32 shows an example in which a single multicast server is serviced for a plurality of heterogeneous networks, and a multicast gateway for this configures each network according to embodiments.
  • a system according to embodiments may include a service provider, network(s), and a device.
  • the configuration of the service provider, network(s), and device according to the embodiments is shown in FIG. 29 .
  • Each component in Fig. 29 corresponds to hardware, software, a processor, and/or a combination thereof.
  • a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • a device accesses Wi-Fi through an ISP network and simultaneously accesses a set-top box through a satellite broadcasting network may be considered.
  • the content playback function in the device can consist of two L interfaces (L1, L2) and two B interfaces (B1, B2).
  • Media streaming can be received through the multicast gateway (A) through the L1 interface, and access information for the initial multicast gateway (A) can be received through the B1 interface.
  • Media streaming can be received through the multicast gateway (B) through the L2 interface, and access information for the initial multicast gateway (B) can be received through the B2 interface.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • 33, 34, and 35 show a network change flow chart according to embodiments.
  • FIG. 33-35 The flowchart of Figs. 33-35 may be performed according to the embodiments shown in Figs. 1-6, 9-16, 32, and the like. Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • the following shows the flow of the process of receiving the same service even after the network is changed, following the process in which the device acquires the manifest and receives the multicast media for the architecture according to the embodiments.
  • the flow related to Multicast Server proceeds as follows.
  • Each function is deployed according to the architecture, and the configuration for multicast service is applied to multicast server, multicast gateway, and multicast rendezvous service.
  • the provisioning function delivers configuration information about the multicast session currently provisioned to the multicast server through network control.
  • the media segment is ingested from the content provider to the multicast server, multicast transmission starts, and if there is a multicast gateway that can receive the corresponding media segment, it becomes available for reception.
  • the device When the device connects to network A, it can operate as follows.
  • Application can receive service list from service provider through network A.
  • the service list acquisition method defined in network A can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to the Multicast rendezvous service (A).
  • Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the multicast rendezvous service (A).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (A) through the reference point B1 using the URL delivered from the application.
  • Multicast rendezvous service (A) checks the status of multicast gateway (A) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (A) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (A) through the reference point L1 following the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server to multicast gateway (A) through M1 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (A) and the media is played. If there is no separate control, media play continues.
  • the device changes the connection from network A to network B, it can operate as follows.
  • Application can receive service list from service provider through network B.
  • the service list acquisition method defined in network B can be used.
  • session information for the corresponding service ID can be exchanged.
  • the received service list may include a url to request a presentation manifest mapped to a service ID.
  • the application can obtain the URL to request the presentation manifest.
  • the URL points to the multicast gateway (B) and rendezvous service (B).
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to a multicast gateway (B) or a multicast rendezvous service (B).
  • the application controls the content playback function to start an operation for content reception, and in this case, a URL for a multicast gateway (B) or a multicast rendezvous service (B) can be delivered.
  • the following process can be selectively performed.
  • the content playback function requests a presentation manifest from the multicast rendezvous service (B) through the reference point B2 using the URL delivered from the application.
  • Multicast rendezvous service (B) checks the status of multicast gateway (B) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (B) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function receiving the redirection message follows the redirection.
  • a presentation manifest is requested from the multicast gateway (B) through the reference point L2.
  • the presentation manifest is cached in the multicast gateway (B) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server to multicast gateway (B) through M2 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (B) and the media is played. If there is no separate control, media play continues.
  • 36 illustrates an example in which all multicast rendezvous services are configured in co-located deployment when a multicast server and a multicast gateway are configured in each network according to the embodiments.
  • a system may include a service provider, network(s), and a device.
  • the configuration of the service provider, network(s), and device according to the embodiments is shown in FIG. 36 .
  • Each component in Fig. 36 corresponds to hardware, software, a processor, and/or a combination thereof.
  • the server may be located outside the network.
  • a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • a device accesses a set-top box through a satellite broadcasting network and simultaneously receives a broadcast through a terrestrial broadcasting network may be considered.
  • the content playback function in the device can consist of two L interfaces (L1, L2) and two B interfaces (B1, B2).
  • Media streaming can be received through the multicast gateway (A) through the L1 interface, and access information for the initial multicast gateway (A) can be received through the B1 interface.
  • Media streaming can be received through the multicast gateway (B) through the L2 interface, and access information for the initial multicast gateway (B) can be received through the B2 interface.
  • the L2 and B2 interfaces can be replaced with the device internal interfaces.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • FIG. 37-39 The flowchart of Figs. 37-39 may be performed according to the embodiments shown in Figs. 1-6, 9-16, 36, and the like. Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • the following shows the flow of the process of receiving the same service even after the network is changed, following the process in which the device acquires the manifest and receives the multicast media for the architecture according to the embodiments.
  • the flow related to Multicast Server proceeds as follows.
  • Each function is deployed according to the architecture, and the configuration for multicast service is applied to multicast server, multicast gateway, and multicast rendezvous service.
  • the provisioning function delivers configuration information about the multicast session currently provisioned to the multicast server through network control.
  • the media segment is ingested from the content provider to the multicast server, multicast transmission starts, and if there is a multicast gateway that can receive the corresponding media segment, it becomes available for reception.
  • the device When the device connects to network A, it can operate as follows.
  • Application can receive service list from service provider through network A.
  • the service list acquisition method defined in network A can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to a multicast gateway (A) or a multicast rendezvous service (A).
  • the application controls the content playback function to start an operation for content reception, and in this case, a URL for a multicast gateway (A) or a multicast rendezvous service (A) can be delivered.
  • the following process can be selectively performed.
  • the content playback function requests a presentation manifest from the multicast rendezvous service (A) through the reference point B1 using the URL delivered from the application.
  • Multicast rendezvous service (A) checks the status of multicast gateway (A) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (A) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function receiving the redirection message follows the redirection.
  • a presentation manifest is requested from the multicast gateway (A) through the reference point L1.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server to multicast gateway (A) through M1 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (A) and the media is played. If there is no separate control, media play continues.
  • the device changes the connection from network A to network B, it can operate as follows.
  • Application can receive service list from service provider through network B.
  • the service list acquisition method defined in network B can be used.
  • session information for the corresponding service ID can be exchanged.
  • the received service list may include a url to request a presentation manifest mapped to a service ID.
  • interface L2 and B2 related operations can be selectively performed.
  • the application can obtain the URL to request the presentation manifest.
  • the URL points to the Multicast rendezvous service (B).
  • the Application controls the content playback function to start an operation for content reception, and in this case, it can deliver the URL for the Multicast rendezvous service (B).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (B) through the reference point B2 using the URL delivered from the application.
  • Multicast rendezvous service (B) checks the status of multicast gateway (B) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (B) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (B) through the reference point L2 following the redirection.
  • the presentation manifest is cached in the multicast gateway (B) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server to multicast gateway (B) through M2 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (B) and the media is played. If there is no separate control, media play continues.
  • the following further describes a method/apparatus for processing a multicast signal according to embodiments connectable to multiple networks.
  • a multicast server may be located on each network.
  • 40-41 show an embodiment in which a device accesses various serviceable networks when a multicast server and a multicast gateway are configured in each network according to the embodiments.
  • Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • a system may include a service provider, network(s), and a device. Configurations of service providers, network(s), and devices according to embodiments are shown in FIGS. 40-41 .
  • FIG. 38 shows a structure in which a single multicast server provides a service to a plurality of heterogeneous networks, and a multicast gateway for this is configured in each network according to embodiments.
  • a system may include a service provider, network(s), and a device.
  • the configuration of the service provider, network(s), and device according to the embodiments is as follows.
  • Each component constituting the embodiments corresponds to hardware, software, a processor, and/or a combination thereof.
  • the transceiver apparatus has an effect of efficiently controlling and providing DVB Multicast ABR and 5G media streaming in various network environments based on the operations according to the embodiments. .
  • the following describes a reception operation and an operation for a reception apparatus according to the embodiments.
  • elements and attributes necessary for a device capable of ABR multicast streaming by accessing a plurality of transport networks are defined.
  • the receiver according to the embodiments may perform a reverse process of the operation of the transmitter.
  • the receiver according to the embodiments may perform ABR multicast streaming based on the following operation.
  • the receiver according to the embodiments may perform ABR multicast streaming based on the following network structure.
  • protocol stacks in receiving devices.
  • 39 shows a protocol configuration for ABR multicast according to embodiments.
  • multicast streaming can be transmitted from the multicast server through the M interface.
  • ROUTE or FLUTE may be used as a multicast transmission protocol.
  • Multicast gateway can use DASH or HLS for HTTP-based adaptive media streaming through L interface for playback function.
  • the protocol for HTTP-based adaptive media streaming reception from the multicast gateway, and the file format and media coded for the received adaptive streaming can be configured.
  • the Layer 1 and Layer 2 protocols may be configured as optimal protocols for each network.
  • embodiments may include the following protocols.
  • 45 shows an embodiment of a protocol that can be configured in a receiving device to access a plurality of networks according to embodiments.
  • the multicast signal processing apparatus When the multicast signal processing apparatus according to the embodiments is implemented as a receiving apparatus, it represents a protocol implemented on the architectures according to the above-described embodiments.
  • a case in which a multicast gateway is configured in a network in network A and a multicast gateway is configured in a device in network B according to embodiments is considered.
  • the multicast gateway configured on the network to service ABR multicast streaming through network A receives multicast streaming from the multicast server and transmits it to the device in an HTTP-based adaptive media streaming method through the L interface. do. Therefore, in the device, a protocol stack that can receive adaptive media streaming through the L interface can be configured.
  • a multicast gateway is configured in the device. Therefore, in the device, a protocol stack capable of receiving adaptive media streaming through the M interface for network B can be configured.
  • protocols for the M interface and the L interface can be simultaneously configured in the receiver device for accessing a plurality of networks to receive the ABR multicast service.
  • the multicast gateway function in the device can convert multicast streaming to HTTP-based adaptive media streaming in the same way as the multicast gateway configured on the network and deliver it to the L interface in the device.
  • a multicast gateway is configured in network A in network A and a multicast gateway is configured in device for network B.
  • the multicast gateway configured on the network to service ABR multicast streaming through network A receives multicast streaming from the multicast server and transmits it to the device in an HTTP-based adaptive media streaming method through the L interface. Therefore, in the device, a protocol stack that can receive adaptive media streaming through the L interface can be configured.
  • a multicast gateway is configured in the device. Therefore, in the device, a protocol stack capable of receiving adaptive media streaming through the M interface for network B can be configured.
  • protocols for the M interface and the L interface can be simultaneously configured in the receiver device for accessing a plurality of networks to receive the ABR multicast service.
  • the multicast gateway function in the device can be configured with an L interface in the device, unlike the multicast gateway configured on the network, and the L interface can be configured directly as a protocol stack without a separate interface.
  • streaming received through network A may operate as a playback function, and in case of streaming received through network B, it may operate as a multicast gateway.
  • the L interface is omitted, and the payload of the multicast protocol may be adaptive media streaming data.
  • a service provider may configure a presentation manifest (ex. MPD) together with a service list as follows.
  • a presentation manifest (ex. MPD)
  • service list In terms of providing service, it can be configured so that the service list and presentation manifest for the same contents do not overlap.
  • FIG. 48 illustrates a method of generating and transmitting a service list and presentation manifest for ABR multicast according to embodiments.
  • the multicast signal processing method/apparatus may generate a service list and a presentation manifest as shown in FIG. 48 and transmit/receive them.
  • Transmission elements can be determined according to the interface defined in the ABR Multicast architecture.
  • the application of the receiver device may receive a service list from the service list directory, and may include a service id and a url for multicast rendezvous service.
  • the content playback function requests the manifest to the multicast rendezvous service through the corresponding url
  • the address of the multicast gateway and the path to the corresponding manifest are obtained through the redirection message of the multicast rendezvous service, and the presentation manifest can be received through the L interface.
  • the multicast gateway may receive a corresponding presentation manifest (ex. MPD) from the multicast server, and may acquire multicast session configuration information for this purpose.
  • MPD presentation manifest
  • 49 shows service list and presentation manifest management according to embodiments.
  • the receiving device may manage the service list and the presentation manifest as shown in FIG. 49 .
  • the service list and presentation manifest (ex. MPD) configured according to the embodiments
  • the service list may be managed as follows in the receiver capable of receiving the ABR multicast service through a plurality of networks.
  • the adaptation set provided in each network may be different in a device receiving the ABR multicast service using a plurality of networks, a presentation manifest is separately configured and managed according to the network.
  • the service list according to the embodiments may be managed like a channel map.
  • 50 shows a service list according to embodiments.
  • Fig. 50 shows the syntax of a service list transmitted and received in Figs. 6, 17-19, 21-23, 25-27, 29-31, 33-35, 37-39, and the like.
  • Service List - This is a root element that includes configuration information for service.
  • Service identifier (@serviceIdentifier) - An identifier that can identify service.
  • Presentation ManifestRequestURL- When configured through a plurality of multicast rendezvous services for one service, it is an element for information on multicast rendezvous service.
  • Network type (@NetworkType)- This is the network type in which the Multicast rendezvous service is located. It can be used to set priority when devices connect to the network at the same time.
  • Host address (@HostAddress) - This is the address of the multicast rendezvous service.
  • Rendezvous service type (@RendezvousServerType)- This is an attribute for the deployment of multicast rendezvous service. For example, 0: regular deployment, 1: co-located deployment
  • Multicast Transport Session (MulticastTransportSession) -
  • the element for the multicast transport session can be transmitted as an option when the device includes a multicast gateway. If the MulticastTransportSession element is not sent, information can be provided through multicast gateway configuration.
  • 51 illustrates a multicast session according to embodiments.
  • the following shows an example of the configuration of a multicast session element.
  • the multicast session element is transmitted from the provisioning function to the multicast server and multicast gateway. Therefore, CMS and CMR interfaces can be used, respectively. If the network supports only unidirectional transmission, it can be transmitted from the multicast server to the multicast gateway through the M interface after being transmitted to the multicast server through the CMS interface.
  • @contentPlaybackAvailabilityOffset Duration string Availability time offset adjustment applied to the original presentation manifest when passed to an instance of the content playback function.
  • PresentationManifestLocator The URL of the presentation manifest for the linear service.
  • MulticastTransportSession A container for multicast transport session parameters.
  • the receiver may identify a network through which the same multicast service is received.
  • FIG. 52 illustrates an element included in a Request URL of an HTTP message according to embodiments.
  • Host FQDN (or IP address) and optionally the port number of the multicast rendezvous service.
  • ManifestPath The resource path to retrieve the presentation manifest on the specified host.
  • AToken The value is an authentication token that authorizes access to the multicast rendezvous service if requested by the system operator. This may have been included in the original presentation manifest URL, added by a third-party CDN broker as part of a previous HTTP redirect URL, or generated locally by the application.
  • MGid The value is the port number of the multicast gateway, optionally preceded by an IP address.
  • the format is: [IP address]:port.
  • the MGhost: value is the multicast gateway hostname.
  • Ori The value is the hostname (FQDN) of the original destination host.
  • the multicast gateway receives multicast by assigning a differential priority to the network in which each multicast gateway is configured can determine priorities.
  • the multicast rendezvous service When the multicast rendezvous service receives the request URL according to the embodiments, it may send a 307 Temporary Redirect response.
  • the syntax of the Redirect URL of the Location response header is as follows.
  • Host This can be the IP address or FQDN of the multicast gateway and optionally a port number (eg "router.example:8088” or "192.0.2.1:8088").
  • Session ID A unique presentation session identifier that may be delivered and generated by the multicast rendezvous service including one or more URL path elements.
  • ManifestPath The resource path to retrieve the presentation manifest on the specified host.
  • RequestedPriority Priority value requested in content playback.
  • the conf: multicast session parameter can take the form of a multicast gateway configuration instance document containing one multicast session.
  • Documents can be compressed using Gzip and base64url encoding before being included as a URL query string parameter.
  • Playback function requests the manifest to the multicast rendezvous service, if the priorities for multiple multicast gateways are set, the priority transmitted at the time of redirection transmission can be returned.
  • Multicast rendezvouse service can redirect to a multicast gateway having the highest priority possible for redirection.
  • the multicast rendezvous service can redirect the request to the multicast gateway as follows.
  • the URL corresponding to the Location field of the HTTP header may include a session identifier and a query parameter for piggybacking the multicast gateway configuration instance document including the multicast session corresponding to the requested presentation manifest.
  • the architecture according to the embodiments may include a content provider, a service provider, a network, a device, and the like, according to the embodiments.
  • Each component may correspond to hardware, software, a processor, and/or a combination thereof.
  • the processor according to the embodiments may perform the operations according to the embodiments and may be connected to a memory that stores information about the operations.
  • the architecture according to the embodiments shows a structure that is serviced using content generated from a plurality of content providers.
  • a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • the service provider may provide a service to the receiver device using a plurality of networks.
  • the service provider can configure the service list directory, and can acquire the content list to be serviced through the content provider control function configured in each content provider.
  • the received content list can compose the service list in a form suitable for the service, and the corresponding service list is provided to the application.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • Content provider server provides content to multicast server configured in service provider (ingest).
  • information on ingested content may be transmitted from each content provider control function to a service provider control function.
  • the service provider control function can use the information to configure multicast session configuration information and deliver it to the multicast server and multicast gateway.
  • L interface and B interface can be configured for each network in the content playback function in the device.
  • Media streaming can be received through multicast gateway (A), multicast gateway (B), multicast gateway (C), and multicast gateway (D) through L1, L2, L3, L4 interfaces, and B1, B2, B3, B4 Connection information for the initial multicast gateway can be received through the interface.
  • the L4 and B4 interfaces can be replaced with the device internal interfaces.
  • the architecture according to the embodiments shows a structure in which a content provider is serviced through a plurality of service providers.
  • a multicast server, a multicast gateway, and a multicast rendezvous service provide a service to a content playback function connected to each network.
  • each service provider may provide a service to the receiver device using a plurality of networks.
  • Each service provider can configure a service list directory, and can acquire a content list to be serviced through the content provider control function of the content provider.
  • the received content list can compose the service list in a form suitable for the service, and the corresponding service list is provided to the application.
  • the application obtains a list of multicast services and access information for the corresponding multicast rendezvous service.
  • the service discovery interface may follow a method defined separately between the service provider and the application.
  • each network can support transmission and reception of data for the service discovery interface.
  • Content provider server provides content to multicast server configured in service provider (ingest).
  • information on the ingested content may be transmitted from the content provider control function to the service provider control function.
  • the service provider control function can use the information to configure multicast session configuration information and deliver it to the multicast server and multicast gateway.
  • L interface and B interface can be configured for each network in the content playback function in the device.
  • Media streaming can be received through multicast gateway (A), multicast gateway (B), multicast gateway (C), and multicast gateway (D) through L1, L2, L3, L4 interfaces, and B1, B2, B3, B4 Connection information for the initial multicast gateway can be received through the interface.
  • the L4 and B4 interfaces can be replaced with the device internal interfaces.
  • 58, 59, 60, 61, 62, and 63 show a service provider change flow chart according to embodiments.
  • the following shows the flow of the process of receiving the same content even after the service provider is changed, following the process in which the device acquires the manifest and receives the multicast media for the architecture according to the embodiments.
  • the flow related to the content provider can proceed as follows.
  • the content provider control function passes the content list to the service provider control functions of service provider A and service provider B.
  • the service provider control function content list is reorganized into a service list, and the service list is transmitted to each connected application.
  • the flow related to Multicast Server proceeds as follows. (Operates independently for each service provider)
  • Each function is deployed according to the architecture, and the configuration for multicast service is applied to multicast server, multicast gateway, and multicast rendezvous service.
  • the provisioning function delivers configuration information about the multicast session currently provisioned to the multicast server through network control.
  • the media segment is ingested from the content provider to the multicast server, multicast transmission starts, and if there is a multicast gateway that can receive the corresponding media segment, it becomes available for reception.
  • a device When a device receives a service through service provider A, it can operate as follows.
  • Application (A) can receive service list from service list directory (A) through network A.
  • the service list acquisition method defined in network A can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • the URL to request the initial presentation manifest can be obtained from the application through the service directory.
  • the URL points to a multicast gateway (A) or a multicast rendezvous service (A).
  • Application (A) controls the content playback function to start an operation for content reception, and in this case, it can deliver a URL for a multicast gateway (A) or a multicast rendezvous service (A).
  • the content playback function requests a presentation manifest from the multicast rendezvous service (A) through the reference point B1 using the URL delivered from the application (A).
  • Multicast rendezvous service (A) checks the status of multicast gateway (A) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, enters the redirection URL for the multicast gateway (A) content Send to the playback function.
  • the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function Upon receiving the redirection message, the content playback function requests a presentation manifest from the multicast gateway (A) through the reference point L1 following the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server (A) to multicast gateway (A) through M1 interface.
  • the content playback function can receive the requested media segment through the multicast gateway (A) and the media is played. If there is no separate control, media play continues.
  • Application (B) can receive service list from service list directory (B) through network B.
  • the service list acquisition method defined in network B can be used. For example, if a service directory is configured in the DVB-I network, a service list can be received through interaction between a service provider, a service directory, and an application.
  • the service list may include the url to request the presentation manifest mapped to the service ID.
  • Application (B) can obtain the URL to request the presentation manifest.
  • the URL points to the multicast gateway (B) and rendezvous service (B).
  • the application can obtain the URL to request the initial presentation manifest through the service directory, etc.
  • the URL points to a multicast gateway (B) or a multicast rendezvous service (B).
  • the application controls the content playback function to start an operation for content reception, and in this case, a URL for a multicast gateway (B) or a multicast rendezvous service (B) can be delivered.
  • the content playback function requests a presentation manifest from the multicast rendezvous service (B) through the reference point B2 using the URL delivered from the application (B).
  • the multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network, and if the service for the requested presentation manifest is defined in the multicast configuration, the redirection URL for the multicast gateway (B) is content Send to the playback function. In this case, the updated multicast session configuration may be included in the transmitted redirection message.
  • the content playback function receiving the redirection message follows the redirection.
  • a presentation manifest is requested from the multicast gateway (B) through the reference point L2.
  • the presentation manifest is cached in the multicast gateway (B) in advance, the presentation manifest is transmitted to the content playback function.
  • the content playback function requests a media segment for the corresponding contents through the network (B) based on the received presentation manifest.
  • Multicast streaming is transmitted from multicast server to multicast gateway (B) through M interface.
  • the content playback function can receive the requested media segment through the multicast gateway (B) and the media is played. If there is no separate control, media play continues.
  • the method/device according to the embodiments may be associated with 5G System Architecture as follows.
  • the 5G System can be composed of the following network functions (NF).
  • NF network functions
  • AUSF Authentication Server Function
  • AMF Core Access and Mobility Management Function
  • DN Data network
  • SDSF Structured Data Storage network function
  • UDF Unstructured Data Storage network function
  • NEF Network Exposure Function
  • NEF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • 64 shows a 5G system service infrastructure structure according to embodiments.
  • the figure above shows the architecture for the non-roaming case of the 5G system as a service-based interface.
  • User plane data is transmitted through DN, UPF, (R)AN, and UE, and other functions can process control plane data.
  • each service-based interface is as follows: Namf: Service-based interface exhibited by AMF. Nsmf: Service-based interface exhibited by SMF. Nnef: Service-based interface exhibited by NEF. Npcf: Service-based interface exhibited by PCF. Nudm: Service-based interface exhibited by UDM. Naf: Service-based interface exhibited by AF. Nnrf: Service-based interface exhibited by NRF. Nausf: Service-based interface exhibited by AUSF.
  • 65 shows a 5G system structure in a reference point representation according to embodiments.
  • the following figure shows the 5G system architecture for the non-roaming case using a reference point that indicates how various network functions interact.
  • User plane data is transmitted through DN, UPF, (R)AN, and UE, and other functions can process control plane data. Accordingly, data is transmitted through N6 and N3, which are reference points between the corresponding functions, and the (R)AN and UE can be connected wirelessly.
  • the reference point may be defined as follows: N1: Reference point between the UE and the AMF.
  • N2 Reference point between the (R)AN and the AMF.
  • N3 Reference point between the (R)AN and the UPF.
  • N4 Reference point between the SMF and the UPF.
  • N5 Reference point between the PCF and an AF.
  • N6 Reference point between the UPF and a Data Network.
  • N7 Reference point between the SMF and the PCF.
  • N7r Reference point between the PCF in the visited network and the PCF in the home network.
  • N8 Reference point between the UDM and the AMF.
  • N9 Reference point between two Core UPFs.
  • N10 Reference point between the UDM and the SMF.
  • N11 Reference point between the AMF and the SMF.
  • N12 Reference point between AMF and AUSF.
  • N13 Reference point between the UDM and Authentication Server function the AUSF.
  • N14 Reference point between two AMFs.
  • N15 Reference point between the PCF and the AMF in case of non-roaming scenario, PCF in the visited network and AMF in case of roaming scenario.
  • N16 Reference point between two SMFs, (in roaming case between SMF in the visited network and the SMF in the home network).
  • N17 Reference point between AMF and EIR.
  • N18 Reference point between any NF and UDSF.
  • N19 Reference point between NEF and SDSF.
  • the reference point listed above may be defined as a separate protocol or as a message with a separate identifier on a common protocol.
  • the interface of the control plane can be physically shared with other reference points, and the reference point can be identified using each protocol or message set.
  • 66 shows a 5G system structure for multiple PDU sessions according to embodiments.
  • UPF and SMF for the corresponding DN may be configured separately, and this function may also be connected through a control plane function and a corresponding reference point, respectively. Therefore, each DN provides a separate PDU session, and the SMF can control the corresponding session.
  • FIG. 66 shows that two DNs (Data Networks) are connected at the same time, two or more DNs may be connected depending on the network configuration.
  • 67 shows a 5G system structure for coexisting access to two data networks according to embodiments.
  • 67 is a network architecture configured so that a PDU session provided by each DN can operate as a single session using a single SMF in a structure connected to two DNs.
  • a User Plane Protocol stack for one PDU session may be defined as shown in FIG. 68 .
  • 68 illustrates a user plane protocol stack according to embodiments.
  • PDU layer This layer corresponds to a PDU delivered between the UE and the DN through a PDU session. If the PDU session type is IPV6, it corresponds to an IPv6 packet. If the PDU session type is Ethernet, it corresponds to an Ethernet frame.
  • 5G Encapsulation This layer supports multiplexing traffic of different PDU sessions (which may correspond to different PDU session types) via N3 (i.e. between AN and 5GC) or N9 (i.e. between different UPFs in 5GC). . Provides encapsulation at the PDU session level. This layer also performs markings related to QoS flows.
  • AN protocol stack This protocol/layer set is AN specific. If the AN is a 3GPP RAN, these protocols/layers are defined by the 3GPP RAN.
  • the number of UPFs in the data path is not limited by the 3GPP specification. It may be in the data path of PDU sessions 0, 1, or multiple UPFs that do not support the PDU session anchor function for this PDU session.
  • the UPF acting as a PDU session anchor in a type PDU session is the IP anchor point of the IP address/prefix assigned to the UE.
  • AMF Access and Mobility Management function
  • the Access and Mobility Management function may include the following functions.
  • AMF may include the following functions: RAN CP interface termination (N2), NAS (N1) termination, NAS encryption and integrity protection, registration management, connection management, accessibility management, mobility management, legitimate interception (for AMF events and interfaces to LI systems), provides SM message transmission between UE and SMF. It provides transparent proxy for SM message routing, access authentication, access authorization, and SMS message transmission between UE and SMSF.
  • Security Anchor Function SEA
  • AMF retrieves security data from AUSF.
  • SCM Security Context Management
  • the SCM receives the key from the SEA, which it uses to derive the access network specific key.
  • AMF may include the following functions to support non-3GPP access networks.
  • N3IWF and N2 interfaces Supports N3IWF and N2 interfaces. Some information (eg, 3GPP cell identification) and procedures (eg, related to handover) defined through 3GPP access through this interface may not apply, and non-3GPP access-specific information that does not apply to 3GPP access may be applied. .
  • NAS signaling support with UE via N3IWF Some procedures supported by NAS signaling over 3GPP access may not apply to untrusted non-3GPP (eg paging) access.
  • the Session Management function may include the following functions.
  • a single SMF instance may support all or some of the following features:
  • Session management Session establishment, modification and teardown, including, for example, tunnel maintenance between UPF and AN nodes.
  • UE IP address assignment and management including optional authorization).
  • UP function selection and control Configure traffic steering in UPF to route traffic to the appropriate destination.
  • Legitimate interception for SM events and interfaces to LI systems). End of the SM portion of the NAS message. Downlink data notifications. Initiator of AN specific SM information sent to AN via N2 via AMF. Determines the SSC mode of the session.
  • Roaming function handles local enforcement to apply QoS SLA (VPLMN). Charging Data Acquisition and Charging Interface (VPLMN). Legitimate interception (from VPLMN for SM Events and interfaces to LI systems). Support interaction with external DN for signaling for PDU session authorization/authentication by external DN.
  • UPF User plane function
  • a single UPF instance may support all or some of the following features:
  • Anchor point for Intra-/Inter-RAT mobility (if applicable).
  • An uplink classifier that supports routing traffic flows into data networks.
  • QoS handling for the user plane eg packet filtering, gating, UL/DL rate enforcement.
  • Uplink traffic validation (SDF to QoS flow mapping). Transmission-level packet indication of uplink and downlink. Downlink packet buffering and downlink data notification triggers.
  • PCF Policy function
  • the policy function may include the following functions.
  • NEF Network Exposure Function
  • Network Exposure Function may include the following functions.
  • a network exposure function receives information from another network function (based on the exposed function of the other network function).
  • a standardized interface to the data storage network function (the interface to be defined in 3GPP) can be used to store the received information as structured data.
  • the stored information may be “re-exposed” by the NEF to other network functions and application functions and used for other purposes such as analytics.
  • the NF Repository Function may include the following functions.
  • Supports service search function Receives the NF Discovery Request from the NF instance, and provides information on the discovered NF instance (to be discovered) to the NF instance. Maintains information about available NF instances and supporting services.
  • UDM Unified Data Management
  • Unified Data Management can be divided into application front end (FE) and User Data Repository (UDR).
  • FE application front end
  • UDR User Data Repository
  • 59 shows a reference architecture for UDM, the following front end may be included.
  • UDM FE Responsible for credential processing, location management, subscription management, etc.
  • PCF responsible for policy control.
  • PCF is not part of UDM as it is a standalone network function in the overall 5GC architecture. However, the PCF can request and provide policy subscription information to the UDR, and for this reason it is exposed in the UDM architecture.
  • UDR stores data required for functions provided by UDM-FE and policy profiles required for PCF.
  • Data stored in UDRs includes:
  • UDM-FE accesses subscription information stored in User Data Store (UDR) and supports the following functions:
  • the front end implements the application logic and does not require an internal user data store. Multiple different frontends can serve the same user in different transactions.
  • N25/Nudr reference point/interface is defined for the front-end to read, update (including add, modify), delete, subscribe to data change notifications and notify data changes from UDRs.
  • N25 is the name of the P2P reference point and Nudr is the name of the service-based interface. Both FE and UDR are in HPLMN.
  • AUSF Authentication Server Function
  • AUSF supports the following functions: Supports AUSF (authentication server function).
  • Application functions interact with the 3GPP core network to provide services. For example, it supports: Application functions that are considered trusted by operators based on their impact on traffic routing, access to network function exposure, interaction with policy frameworks for policy control, and operator placement can interact directly with relevant network functions. Application functions that do not allow operators to directly access network functions must use an external exposure framework through the NEF to interact with the relevant network functions.
  • 70 shows a structure for 5G media streaming according to embodiments.
  • 70 shows a structure in which a function for downlink media streaming is configured in a 5G network.
  • 5GMSd Aware Application and 5GMSd Client are configured in UE, and 5GMSd AF and 5GMSd AS can be configured in DN (Data Network).
  • DN Data Network
  • the DN is configured in the network operated by the mobile network operator, it can be considered as Trusted DN.
  • the DN is configured outside the mobile network operator, it can be considered as an External DN (eg 3rd party CDN) .
  • Other functions and interfaces are additionally described in Annex A.
  • 71 illustrates a Media Architecture for unicast downlink media streaming according to embodiments.
  • Media Architecture for unicast downlink media streaming can be defined as follows.
  • each function and interface defines a logical interface in terms of media streaming.
  • 5GMSd Client on UE 5G Media Streaming Client for Downlink: Receiver of 5GMS Downlink Media Streaming Service accessible via well-defined interface/API.
  • the UE may be implemented in a self-contained manner such that interfaces M6d and M7d are not exposed at all.
  • the 5GMSd client has two sub-features.
  • Media Session Handler The capability of the UE to communicate with 5GMSd AF to establish, control and support the delivery of media sessions.
  • Media session handlers can expose APIs that can be used by 5GMSd-Aware applications.
  • Media Player Performs the function of a UE that can communicate with 5GMSd AS to stream media content and provide APIs to 5GMSd-aware applications for media playback and media session handlers for media session control.
  • 5GMSd aware applications 5GMSd clients are typically controlled by external media applications. An app that can implement external application or content service provider-specific logic and establish media sessions. Although the 5GMSd-Aware application is not defined in the 5G Media Streaming Specification, this function uses the 5GMSd interface and API to use the 5GMSd client and network functions.
  • 5GMSd AS An application server that hosts 5G media functions. There may be other implementations of 5GMSd AS (eg Content Delivery Network (CDN)).
  • CDN Content Delivery Network
  • 5GMSd Application Providers External application or content-specific media functions (eg media creation, encoding and formatting using 5GMSd to stream media to 5GMSd-aware applications).
  • External application or content-specific media functions eg media creation, encoding and formatting using 5GMSd to stream media to 5GMSd-aware applications.
  • 5GMSd AF Performs application functions that provide various control functions to media session handlers and/or 5GMSd application providers on the UE. It can relay or initiate requests for processing other policies or charging functions (PCFs), or interact with other network functions through NEFs.
  • PCFs policies or charging functions
  • Each interface for 5G Downlink Media Streaming can be defined as follows.
  • M1d (5GMSd Provisioning API): An external API exposed by 5GMSd AF to provision usage of 5G media streaming system and to obtain feedback.
  • M2d 5GMSd Ingest API: An optional external API exposed by the 5GMSd AS used when a 5GMSd AS with a trusted DN is selected to host content for streaming services.
  • M3d (internal): Internal API used to exchange information about content hosted on 5GMSd AS within trusted DN.
  • M4d Media Streaming API: An API that 5GMSd AS exposes to media players to stream media content.
  • M5d Media Session Handling API: An API exposed to media session handlers by 5GMSd AF for media session handling, control and support. This includes appropriate security mechanisms as well. Perform authorization and authentication.
  • M6d UE Media Session Handling APIs: It is an API that is exposed to Media Player by Media Session Handler for client internal communication and exposed to 5GMSd-Aware Application so that 5GMS functions can be used.
  • M7d UE Media Player API: An API that the media player exposes to 5GMSd aware applications and media session handlers to use the media player.
  • M8d (Application API): An application program interface used to exchange information between 5GMSd-aware applications and 5GMSd application providers (eg, to provide service access information to 5GMSd-aware applications). This API is external to the 5G system and is not specified by 5GMS.
  • the method/apparatus according to the embodiments may be associated with the MULTICAST ADAPTIVE BITRATE SYSTEM ARCHITECTURE as follows.
  • the relationship between logical functions can be defined as a reference point.
  • this architecture when this architecture is actually used, it can be implemented as a concrete interface, and each specific protocol can be used to exchange necessary information between related functions.
  • the reference point for content transmission in the above architecture is as follows.
  • interface L can be implemented as a local API.
  • multicast gateway It is also used by multicast gateway to retrieve content directly from content hosting function via unicast when U cannot perform content recovery.
  • M Responsible for multicast IP content transmission by the multicast server function, reception by the multicast gateway function, and reception by the unicast repair service function in some distributions.
  • this interface can be used to pass payloads used for content recovery functions.
  • U' Responsible for unicast interaction between unicast recovery service and multicast server instead of fetching recovery content via A.
  • this interface may be used to carry payloads used for content recovery functions.
  • Pin Post content to content hosting function by content packaging sub-function, which can be implemented as a push interface or fetch content on demand from content packaging function.
  • the content is collected by the multicast server function, and this is generally implemented as a full interface.
  • Pin' Ingest the content by the multicast server directly in the content packaging function, which is usually implemented as a push interface.
  • Reference points for transmitting control signaling and operational reporting information in the above architecture are as follows.
  • CMS Control interface for configuring multicast server functions.
  • CMR Control interface for configuring multicast gateway functions.
  • CCP Control interface for configuring provisioning functions.
  • RS Service report by multicast gateway function to service report capture function.
  • RCP Service Reporting by the Service Reporting Capture subfunction for the Content Provider Metrics Reporting Capture function.
  • RPM Replay Metrics Reporting to Content Provider Metric Report Capture Capability by Content Replay Function.
  • 73 shows a reference structure according to embodiments.
  • the content encoding function converts the source media stream into encoded media to reduce bitrate.
  • a single source media stream may be converted into a plurality of different encoded representations to meet delivery conditions.
  • a virtual segment boundary marker may be included in the encoded representation so that the content playback function can adaptively operate according to delivery conditions.
  • the output of the encoder can be a cleartext stream formatted to be suitable for transmission to an encryption function or a packaging function.
  • it may be an MPEG elementary stream, MPEG-2 TS, or an intermediate format having a similar purpose.
  • Content encryption function receives cleartext stream as input and encrypts it with cipertext stream. Encryption key can be obtained from the DRM license management function.
  • the content packaging function collects one or more encoded representations and organizes the data according to the desired packaging format.
  • the output of the packager is a sequence of packaged media segments containing representation switching points aligned across multiple representations of the same source media stream.
  • Packaging format can be ISO Base Media File Format (MP4) and fragmented MPEG-2 TS.
  • the content hosting function can prepare prepared content for use in the following cases.
  • the content hosting function can be implemented as a simple web server, part of an origin cluster, or operated as a distributed CDN. Therefore, by using load balancing and request distribution technology (DNS round-robin, HTTP 302 redirect), the client can receive the content from the appropriate content server.
  • DNS round-robin HTTP 302 redirect
  • Multicast server collects content from content sources. That is, the media stream is input to the Oin interface, and the protocol normally loaded on the media player can be used.
  • the payload of the collected media stream is encapsulated in the delivery unit of the multicast transport protocol and transmitted through the network. Also, it is transmitted to the subscribed multicast gateway client using IP multicast through the M interface. It can be configured by receiving configuration information from the network control function through the CMS interface.
  • the packaged media segment is downloaded from the content hosting function based on the description in the presentation manifest.
  • the interface Oin may have different detailed operation characteristics, but may be functionally the same as the interface L.
  • Segments can be packaged in MPEG-DASH or HLS, and segments can be simultaneously downloaded from one or more representations described in the presentation manifest.
  • Manifest formats such as DVB-DASH, MPEG-DASH, and HLS can be supported.
  • HTTP(S) push interface such as WebDAV (Web Distributed Authoring and Versioning) can be provided.
  • the content packaging subfunction uploads the media segment to the content ingest function as soon as it is created. Segment can be packaged in a format such as MPEG-DAH or HLS.
  • the packager sends MPEG-2 TS packets in RTP.
  • the segment boundary can be displayed using a virtual segment boundary marker.
  • the stream received by the Content ingest subfunction is transmitted as the payload of the IP multicast packet through the M interface.
  • Unicast repair service provides payload repair function to unicast repair client inside multicast gateway through U reference point.
  • the following repair modes can be considered.
  • Unicast repair service receives multicast content transmitted through reference point M, and caches a copy of packet stream locally to satisfy repair request of Unicast repair client.
  • the packet repair request may be transferred to the multicast server through the U' interface.
  • the unicast repair service may convert a packet repair request into an HTTP request for a content hosting function using the same interface as the reference point A.
  • Multicast Gateway can be implemented with local origin including forward proxy or reverse proxy.
  • Multicast Gateway can be embodied as a home gateway device or a user's premises equipment such as an IP-connected set-top box (STB). It can also be located on an upstream network node instead of a user's premises equipment.
  • STB IP-connected set-top box
  • a content request is received from one or more instances of the Content Playback function through the L interface.
  • the content cached in the Asset storage subfunction is directly serviced, or the content obtained through the A interface is indirectly serviced.
  • the content obtained through the A interface can be optionally cached in the Asset storage subfunction.
  • the service management subfunction may collect service configuration information for a multicast content stream receivable through the M interface and location information of a service reporting capture function. Such information can be received as follows.
  • the multicast reception subfunction receives the content stream requested by the end device or configured for the end device through the M interface.
  • Content received normally without errors can be cached in the asset storage so that the content can be used later.
  • Content damaged during transmission can be repaired using a specific technique (e.g. Forward Error Correction, unicast repair by the Unicast repair client via U or unicast retrieval via A) before the multicast gateway caches it. Unrecovered content is not delivered through the L interface.
  • a specific technique e.g. Forward Error Correction, unicast repair by the Unicast repair client via U or unicast retrieval via A
  • Multicast packet loss is detected and recovered using Forward Error Correction information received through the M interface or by using a unicast repair service (e.g. unicast packet retransmission or multicast segment loss signaling) through the U interface.
  • a unicast repair service e.g. unicast packet retransmission or multicast segment loss signaling
  • unicast transmission through interface A can be used.
  • Asset storage subfunction provides a function to temporarily store information to be provided through the L interface.
  • the storage function is performed only by the multicast gateway.
  • Managed pre-positioned media content assets For example, all or part of content or advertisement-related information that is popular with a large number of users can be stored in advance before actual use.
  • Service-related metrics e.g. telemetry and analytics data
  • Service reporting capture subfunction Through the RS interface by the Service reporting subfunction.
  • the purpose of the provisioning function is as follows.
  • the Provisioning function can be linked with the Content Provider control function based on information transmitted through the CCP interface.
  • the service reporting information collected by the multicast gateway may be provided to the service reporting capture function through the RS interface.
  • the report may include metrics and major indicators (e.g. cache hit-ratio, viewership) that inform the performance of the service. Metrics can vary depending on which channel was requested, when the channel was established, and how many segments were cached. Service reporting information can be used to improve service performance or configure a multicast channel.
  • the service reporting capture function may export service reporting information to the Content Provider metrics reporting capture function through the RCP interface.
  • Information such as multicast content and bitrate may be included in the corresponding reporting information.
  • the network control function may perform functions such as control, configuration, and allocation of network resources.
  • it may include resources for multicast transmission in the M interface and unicast operation in the U and A interfaces.
  • the network control function can distribute the configuration information for the transmittable multicast stream to the network resource, and additionally, this configuration information can be sent to the multicast server through the CMS interface or to the multicast gateway through the CMR interface. there is.
  • the configuration information for the transmittable multicast stream can be updated according to the control policy of the content provider or the number of requests from the client.
  • the Content Provider control function enables the network control function to provide information on available services through the multicast delivery path M through the CCP interface.
  • a single Content Provider control function can interact with multiple Network Control functions operated by different network providers.
  • the content playback function is a function that manages content request, reception, decryption, presentation, and the like. Only unicast transmission is supported through interface L. Playback operates regardless of the transmission path through which the content is delivered.
  • the content playback function may be located separately from the multicast gateway in an end device such as a smartphone. Alternatively, it can be combined with a multicast gateway in a set-top box or connected TV.
  • Content unpackaging subfunction can extract elementary stream data from the obtained transport object and provide it to Content decryption and Content decoding subfunction. For example, in the case of the ISO Base Media File Format segment, an appropriate media data box is extracted, and in the case of MPEG-2 TS, the desired PID is filtered and the payload of the recombined PES packet is extracted.
  • the Content decryption subfunction obtains a decryption key from the appropriate DRM license management function and decrypts the encrypted elementary stream.
  • the Content decoding subfunction reads and interprets the contents of elementary media stream to enable rendering for playback on screen or loudspeaker.
  • the Playback metrics reporting subfunction may report information related to the operation and quality of content playback to the Content Provider metrics reporting capture function through the RPM interface. Metrics may include HTTP request/response, initial playback delay, buffer level, presentation switching event, network throughput, etc.
  • the reported playback metric is directly related to the QoE of the end user and can be used to optimize the quality in the content provider or network.
  • Multicast rendezvous service manages data records for multiple multicast gateway instances (current multicast gateway status, multicast session status and related data, etc.).
  • the network control function may provide such related information to the multicast rendezvous service.
  • Multicast rendezvous service handles the initial request for presentation manifest coming through reference point B from the content playback function.
  • the multicast rendezvous service determines whether there is an active multicast session for the linear service corresponding to the requested presentation manifest. In addition, it is determined whether there is a suitable active multicast gateway to be used by the content playback function for the corresponding request.
  • the multicast rendezvous service can redirect the request to the multicast gateway. Otherwise, the multicast rendezvous service redirects the request to the content hosting function, and in this case, the session operates as unicast.
  • the DRM license management function provides an appropriate encryption key used by the Content encryption function to protect the core content, and provides a license to the Content decryption subfunction so that the Content playback function can decrypt the protected content.
  • Application controls the Content playback function.
  • it may be a built-in control application (EPG application) of a TV or set-top box, or a third-party application provided by a content provider.
  • the interface that an application uses to control content playback generally involves passing a reference point in a presentation manifest (e.g. URL of MPEG DASH MPD) for initiating playback of an individual linear service.
  • An application can interact with the service management subfunction of the multicast gateway to discover existing linear services and to control reception by the multicast gateway.
  • An application may discover the existence of a linear service through an application-specific service directory function and individual interaction.
  • the service directory function may be configured by a content provider control function.
  • the multicast gateway function can be implemented in various nodes within the network.
  • Fig. 74 shows a multicast gateway deployed in a network edge device.
  • the terminal device does not support IP multicast reception from the home network.
  • the terminal device includes a content playback function, and an application that controls linear playback is installed.
  • Multicast gateway provides multicast-to-unicast conversion function to multiple home gateway devices. Therefore, traffic in the access network between the network edge device and the home gateway device becomes unicast.
  • 75 shows a structure of a multicast gateway distributed in a home gateway device according to embodiments.
  • Multicast gateways are implemented in home gateway devices such as routers, which are mainly supplied by ISPs (Internet Service Providers).
  • the multicast gateway provides a multicast-to-unicast conversion function to a plurality of terminal devices in the same home network. Each of these terminal devices has an instance of the Content playback function, and an application related thereto is installed.
  • 76 shows a structure of a multicast gateway distributed in a terminal device according to embodiments.
  • the terminal device supports IP multicast reception in the home network.
  • Each terminal device includes both a multicast gateway and a content playback function, and an application for controlling linear playback is installed.
  • the multicast gateway function should provide content service only to the corresponding host terminal device.
  • Home gateway device can only join multicast group and perform related operations. This behavior can lead to unpredictable quality changes when the home network does not support full multicast delivery.
  • 77 shows a hybrid broadcast receiving apparatus according to embodiments.
  • the reception apparatus according to the embodiments may be represented as shown in FIG. 77 .
  • Each component of the receiving apparatus according to the embodiments may correspond to hardware, software, a processor, and/or a combination thereof.
  • 5GC 5G Core Network
  • 5GMS 5G Media Streaming
  • 5GMSd 5G Media Streaming downlink
  • 5GMSu 5G Media Streaming uplink
  • 5GS 5G Systems
  • AF Application Function
  • ABR Adaptive Bit Rate
  • AMF Access and Mobility Function
  • API Application Programming Interface
  • App Application
  • AS Application Server
  • CAPIF Common API Framework
  • CDN Content Delivery Network
  • DASH Dynamic and Adaptive Streaming over HTTP
  • DN Data Network
  • DNAI Data Network Application Identifier
  • DNN Data Network Name
  • DRM Digital Rights Management
  • EPC Evolved Packet Core
  • EPS Evolved Packet System
  • EUTRAN Evolved Universal Terrestrial Radio Access Network
  • FLUS Framework for Live Uplink Streaming
  • FQDN Fully -Qualified Domain Name
  • GPU Graphics Processing Unit
  • GSM Global System for Mobile communication
  • HPLMN Home Public Access
  • IP Internet Protocol
  • ISO International Organization for Standardization
  • HLS HTTP Live Streaming
  • HTTP HyperText Transfer Protocol
  • HTTPS Secure HyperText Transfer Protocol
  • MBMS Multimedia Broadcast Multicast Services (pertaining to 3GPP)
  • MPD Media Presentation Description pertaining to MPEG-DASH
  • MPEG Moving Pictures Experts Group
  • OTT Over The Top
  • PID Packet Identifier (pertaining to MPEG-2 Transport Stream)
  • RTCP RTP Control Protocol
  • RTP Real-time Transport Protocol
  • STB Set- Top Box
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • URL Uniform Resource Locator
  • the multicast signal processing apparatus may receive a multicast signal and decode multicast media data as follows.
  • a multicast signal processing method may include receiving media based on a multicast scheme.
  • the media reception operation may include the operations of FIGS. 1-6, 9-16, 40-43, 44-49, 54-57, 64-67, and the like.
  • the multicast signal processing method according to the embodiments may further include receiving signaling information on media.
  • the signaling information reception operation may include the operations of FIGS. 6-8, 17-19, 50-53, 58-63, and the like.
  • the multicast signal processing method according to the embodiments may further include decoding the media.
  • the media decoding operation may include the operations of FIGS. 1-6, 9-16, 40-43, 44-49, 54-57, 64-67, and the like.
  • 79 shows a multicast signal processing method according to embodiments.
  • a multicast signal processing apparatus (a content provider, a multicast server, a multicast caseway, a network control unit, a multicast Langlebu service control unit, etc.) may generate and transmit a multicast signal as follows.
  • the multicast signal processing method may include generating signaling information for media.
  • the signaling information generating operation may include the operations of FIGS. 5-76-8, 14-3617-19, 45-4850-53, 51-5358-63, and the like.
  • the multicast signal processing method may further include transmitting media and signaling information based on a multicast method.
  • the operation of transmitting media and signaling information may include operations of FIGS. 1-6, 9-16, 40-43, 44-49, 54-57, 64-67, and the like.
  • an apparatus for processing a multicast signal includes a memory; and a processor coupled to the memory; including, the processor may receive multicast media data based on at least one of the first network and the second network, and may decode the multicast media data.
  • embodiments may provide multicast over multiple networks.
  • the first network and the second network are different from each other, and at least one of the first network or the second network may include a communication network, a broadcast network, a two-way network, or a unidirectional network.
  • embodiments include a network change, rendezvous, redirection, media reception flow diagram.
  • Multicast media data is received through the first network, and in response to a change from the first network to the second network, the processor receives service list information through the second network, and based on the service list information Obtain multicast rendezvous service information, receive presentation manifest information based on the rendezvous service information, receive redirection information based on the presentation manifest information, and receive presentation manifest information based on the redirection information By receiving the information, it is possible to receive multicast media data.
  • embodiments include a flow diagram of a plurality of networks, and referring to Figure 45, embodiments include a service list.
  • the processor based on at least one of the first network or the second network, receives service list information, the service list information for the first network includes address information for manifest information for multicast media data, The service list information for the second network includes address information for manifest information for the multicast media data, and the service list information for the first network and the service list information for the second network is for the multicast media data. It may include an identifier and address information for a multicast rendezvous.
  • the embodiments include a service list and a presentation manifest (ex. MPD) for a plurality of networks.
  • the processor may manage presentation manifest information for each of the first network and the second network for the multicast media data.
  • embodiments include a service list.
  • the processor receives service list information for multicast media data, the service list information includes presentation manifest request information, and the presentation manifest request information includes type information of a network for a multicast rendezvous service, multicast rendezvous It may include host address information for the service and type information of the multicast langrebu service.
  • inventions support a multicast session.
  • the processor may receive multicast session information for multicast media data, and the multicast session information may include identification information on a network through which the multicast session is transmitted.
  • a multicast signal processing method includes: receiving, by a processor, multicast media data based on at least one of a first network or a second network; and decoding the multicast media data; may include
  • the method of receiving the multicast signal may include a reverse process of transmitting the multicast signal.
  • a multicast signal processing apparatus may perform a signal processing method.
  • a multicast signal processing method may include generating multicast media data; generating signaling information for multicast media data; transmitting multicast media data in a multicast manner based on at least one of a first network and a second network; and transmitting signaling information for multicast media data; may include
  • a multicast signal processing apparatus includes a memory; and a processor coupled to the memory; comprising, the processor generates multicast media data, generates signaling information for the multicast media data, and transmits the multicast media data in a multicast manner based on at least one of a first network and a second network , and signaling information for multicast media data may be transmitted.
  • the apparatus has an effect of efficiently utilizing various networks in broadcasting and multicast transmission based on operation/configuration and/or signaling information according to the embodiments.
  • the method/apparatus according to the above-described embodiments can reduce the load of the network in various streaming sessions, reduce the implementation cost, and efficiently provide the ABR Multicast service in connection with various networks and/or devices. It works. In order to provide this effect, the architecture and flow according to the embodiments are required.
  • Various components of the apparatus of the embodiments may be implemented by hardware, software, firmware, or a combination thereof.
  • Various components of the embodiments may be implemented with one chip, for example, one hardware circuit.
  • the components according to the embodiments may be implemented with separate chips.
  • at least one or more of the components of the device according to the embodiments may be composed of one or more processors capable of executing one or more programs, and the one or more programs may be implemented Any one or more of the operations/methods according to the examples may be performed or may include instructions for performing the operations/methods.
  • Executable instructions for performing the method/acts of the apparatus according to the embodiments may be stored in non-transitory CRM or other computer program products configured for execution by one or more processors, or one or more may be stored in temporary CRM or other computer program products configured for execution by processors.
  • the memory according to the embodiments may be used as a concept including not only volatile memory (eg, RAM, etc.) but also non-volatile memory, flash memory, PROM, and the like. Also, it may be implemented in the form of a carrier wave, such as transmission through the Internet.
  • the processor-readable recording medium is distributed in a computer system connected through a network, so that the processor-readable code can be stored and executed in a distributed manner.
  • first, second, etc. may be used to describe various components of the embodiments. However, interpretation of various components according to the embodiments should not be limited by the above terms. These terms are only used to distinguish one component from another. it is only For example, the first user input signal may be referred to as a second user input signal. Similarly, the second user input signal may be referred to as a first user input signal. Use of these terms should be interpreted as not departing from the scope of the various embodiments. Although both the first user input signal and the second user input signal are user input signals, they do not mean the same user input signals unless the context clearly indicates otherwise.
  • the operations according to the embodiments described in this document may be performed by a transceiver including a memory and/or a processor according to the embodiments.
  • the memory may store programs for processing/controlling operations according to the embodiments, and the processor may control various operations described in this document.
  • the processor may be referred to as a controller or the like.
  • operations may be performed by firmware, software, and/or a combination thereof, and the firmware, software, and/or a combination thereof may be stored in a processor or stored in a memory.
  • the transceiver device may include a transceiver for transmitting and receiving media data, a memory for storing instructions (program code, algorithm, flowchart and/or data) for a process according to embodiments, and a processor for controlling operations of the transmitting/receiving device.
  • a processor may be referred to as a controller or the like, and may correspond to, for example, hardware, software, and/or a combination thereof. Operations according to the above-described embodiments may be performed by a processor.
  • the processor may be implemented as an encoder/decoder or the like for the operation of the above-described embodiments.
  • the embodiments may be applied in whole or in part to a point cloud data transmission/reception device and system.
  • Embodiments may include modifications/modifications, which do not depart from the scope of the claims and the like.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

실시예들에 따른 멀티캐스트 신호 처리 방법은 멀티캐스트 미디어 데이터를 생성하는 단계; 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 생성하는 단계; 멀티캐스트 미디어 데이터를 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 방식으로 전송하는 단계; 및 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 전송하는 단계; 를 포함할 수 있다. 실시예들에 따른 멀티캐스트 신호 처리 장치는 메모리; 및 메모리에 연결된 프로세서; 를 포함하고, 프로세서는, 제1네트워크 또는 제2네트워크 중 적어호 하나에 기반하여 멀티캐스트 미디어 데이터를 수신하고, 멀티캐스트 미디어 데이터를 디코딩할 수 있다.

Description

멀티캐스트 신호 처리 방법 및 장치
본 발명은 멀티캐스트 신호를 처리하는 장치 및 방법에 관한 것이다.
디지털 기술 및 통신 기술의 발전으로 방송, 영화뿐만 아니라 인터넷 및 개인 미디어 등의 다양한 영역에서 오디오/비디오 중심의 멀티미디어 컨텐츠 보급 및 수요가 급속도로 확대되고 있다. 또한, 디스플레이 기술의 발전과 더불어 가정에서의 TV 화면이 대형화 됨에 따라 UHD (Ultra High Definition) 방송 서비스에 대한 논의가 증가되고 있는 추세이다.
방송 서비스와 관련하여, 복수의 사용자에게 동일한 컨텐츠를 전송하는 멀티캐스트 (multicast) 전송 방식은 유니캐스트 (unicast)와 브로드캐스트 (broadcast)의 장점을 모두 활용할 수 있으므로 효과적이다. 하지만, 기존의 멀티캐스트 전송 방식은 단일 네트워크 내에서만 가능했으며 이종망 간의 멀티캐스트 서비스가 불가능한 단점이 있었다. 이로 인해 멀티캐스트 수신 장치가 서로 다른 억세스 네트워크를 접속 및 접속해제하는 경우 기존 멀티캐스트 서비스가 종료된 후 새로운 멀티캐스트 서비스를 시작해야하는 문제점이 있었다. 또한 복수의 전송 프로토콜이 사용되는 경우 IP/UDP 또는 IP/TCP상에서 페이로드를 구성하는 프로토콜이 IANA에 등록되지 경우 포트 넘버를 이용하여 식별하는 것이 불가능하다. IP multicast의 경우 destination address및 port number는 멀티캐스트 에 할당된 값을 사용 하게 되므로, 모든 수신기에서 해당 패킷을 수신 하는데, 이때 알려지지 않은 프로토콜이 사용된 경우 해당 패킷에 대한 멀티캐스트를 처리할 수 없는 문제점이 있다.
본 발명의 목적은, 멀티캐스트 신호를 전송하는 방법 및 장치에 있어서 전송 효율을 높이는 것이다.
또한, 멀티플 네트워크들 간 멀티캐스트 서비스를 효울적으로 제공하는 것이다.
다만, 전술한 기술적 과제만으로 제한되는 것은 아니고, 기재된 전체 내용에 기초하여 당업자가 유추할 수 있는 다른 기술적 과제로 실시예들의 권리범위가 확장될 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 방법은 멀티캐스트 미디어 데이터를 생성하는 단계; 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 생성하는 단계; 멀티캐스트 미디어 데이터를 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 방식으로 전송하는 단계; 및 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 전송하는 단계; 를 포함할 수 있다. 실시예들에 따른 멀티캐스트 신호 처리 장치는 메모리; 및 메모리에 연결된 프로세서; 를 포함하고, 프로세서는, 제1네트워크 또는 제2네트워크 중 적어호 하나에 기반하여 멀티캐스트 미디어 데이터를 수신하고, 멀티캐스트 미디어 데이터를 디코딩할 수 있다.
본 발명의 실시예에 따르면, 멀티플 네트워크들 간 멀티캐스트 서비스를 제공할 수 있다.
실시예들에 따르면, 복수의 network 기반의 multicast media streaming 을 위한 media architecture를 제시하여, DVB Multicast ABR 구조가 적용될 수 있는 여러 network 에서도 동일한 수준의 media 서비스가 가능하다.
실시예들에 따르면, multicast streaming시 수신 device가 접속되어 있는 network 에 의존하지 않고, 다양한 접속 방법을 통해 multicast content를 수신할 수 있다.
실시예들에 따르면, 다양한 기기가 각각 별도의 network에 접속되어 있는 경우에 대해서도, 동일한 수준의 ABR multicast service 를 제공할 수 있다.
도면은 실시예들을 더욱 이해하기 위해서 포함되며, 도면은 실시예들에 관련된 설명과 함께 실시예들을 나타낸다. 이하에서 설명하는 다양한 실시예들의 보다 나은 이해를 위하여, 하기 도면들에 걸쳐 유사한 참조 번호들이 대응하는 부분들을 포함하는 다음의 도면들과 관련하여 이하의 실시예들의 설명을 반드시 참조해야 한다.
도1은 실시예들에 따른 멀티캐스트 ABR(Adaptive Bitrate) 구조를 나타낸다.
도2는 실시예들에 따른 멀티캐스트 랑데부 서비스 기반 프리젠테이션 마니페스트 획득 과정을 나타낸다.
도3은 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.
도4는 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.
도5-6은 실시예들에 따른 멀티캐스트 기반 미디어 수신의 흐름도를 나타낸다.
도7은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
도8은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
도9는 실시예들에 따른 5G 미디어 스트리밍에 대한 멀티캐스트 적용 방안을 나타낸다.
도10은 실시예들에 따른 멀티캐스트 네트워크 및 통신 네트워크 스트리밍 모두를 위한 멀티태스트 스트리밍 구조를 나타낸다.
도11은 실시예들에 따른 통신 네트워크에서 멀티캐스트 및 브로드캐스트에 기초하여 무선 미디어 전송을 하는 아키텍쳐를 나타낸다.
도12-13은 실시예들에 따른 각 네트워크에서 멀티캐스트 서버 구성 예시를 나타낸다.
도14-15는 실시예들에 따른 모든 네트워크들에 대한 멀티캐스트 서버 구성 예시를 나타낸다.
도16은 실시예들에 따른 장치가 접속하는 멀티플 네트워크 예시를 나타내다.
도17, 도18, 도19는 실시예들에 따른 네트워크 변경에 관한 흐름도를 나타낸다.
도20은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다.
도21, 도22, 도23은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도24는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다
도25, 도26, 도27은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도28은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타내다.
도29, 도30, 도31은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도32는 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 를 구성하는 예시를 나타낸다.
도33, 도34, 도35는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도36은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우, 모든 multicast rendezvous service가 co-located deployment 로 구성되는 예시를 나타내다.
도37, 도38, 도39는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도40-41은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 실시예를 나타낸다.
도42-43은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 제공하며, 이에 대한 multicast gateway가 각각의 network 에 구성되는 구조를 나타낸다.
도44는 실시예들에 따른 ABR 멀티캐스트를 위한 프로토콜 구성을 나타낸다.
도45는 실시예들에 따른 복수의 network에 접속하기 위해 수신 장치에 구성될 수 있는 protocol 에 대한 실시 예를 나타낸다.
도46은 실시예들에 따른 프로토콜을 나타낸다.
도47은 실시예들에 따른 서비스 및 서비스에 관한 정보의 구성을 나타낸다.
도48은 실시예들에 따른 ABR 멀티캐스트를 위한 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 전송하는 방법을 나타낸다.
도49는 실시예들에 따른 service list 및 presentation manifest 관리를 나타낸다.
도50은 실시예들에 따른 서비스 리스트를 나타낸다.
도51은 실시예들에 따른 멀티캐스트 세션을 나타낸다.
도52는 실시예들에 따른 HTTP message의 Request URL에 포함되는 엘리먼트를 나타낸다.
도53은 실시예들에 따른 Location response header 의 Redirect URL 에 포함되는 정보를 나타낸다.
도54-55는 실시예들에 따른 멀티플 컨텐츠 프로바이더를 나타낸다.
도56-57은 실시예들에 따른 멀티플 서비스 프로바이더를 나타낸다.
도58, 59, 60, 61, 62, 63은 실시예들에 따른 서비스 프로바이더 변경 흐름도를 나타낸다.
도64는 실시예들에 따른 5G 시스템 서비스 기반 구조를 나타낸다.
도65는 실시예들에 따른 레퍼런스 포인트 리프리젠테이션 내 5G 시스템 구조를 나타낸다.
도66은 실시예들에 따른 멀티플 PDU 세션을 위한 5G 시스템 구조를 나타낸다.
도67은 실시예들에 따른 두 가지 데이터 네트워크들에 공존하는 접속을 위한 5G 시스템 구조를 나타낸다.
도68은 실시예들에 따른 유저 플레인 프로토콜 스택을 나타낸다.
도69는 실시예들에 따른 Unified Data Management (UDM) 을 나타낸다.
도70은 실시예들에 따른 5G 미디어 스트리밍을 위한 구조를 나타낸다.
도71은 실시예들에 따른 유니캐스트 다운링크 미디어 스트리밍을 위한 미디어 아키텍처(Media Architecture for unicast downlink media streaming)를 나타낸다.
도72는 실시예들에 따른 레퍼런스 구조를 나타낸다.
도73은 실시예들에 따른 레퍼런스 구조를 나타낸다.
도74는 실시예들에 따른 멀티캐스트 게이트웨이 배포 모델을 나타낸다.
도75는 실시예들에 따른 홈 게이트웨이 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
도76은 실시예들에 따른 단말 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
도77은 실시예들에 따른 하이브리드 방송 수신 장치를 나타낸다.
도78은 실시예들에 따른 멀티캐스트 신호 처리 방법을 나타낸다.
도79는 실시예들에 따른 멀티캐스트 신호 처리 방법을 나타낸다.
실시예들의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 실시예들의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 실시예들의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 실시예들에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 실시예들이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
실시예들에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 실시예들은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 적응적 비트레이트 멀티캐스트(Adaptive Bitrate Multicast) 네트워크에서 미디어(Media) 전송 방법에 관한 것이다.
실시예들에 따른 미디어는 미디어 신호, 미디어 데이터 등으로 지칭가능하고, 서비스 또는 서비스 데이터에 대응하거나 서비스를 포함하는 용어로 해석될 수 있다.
실시예들은 IP(Internet Protocol) 기반 media 전송 시스템에서 미디어 스트리밍(media streaming)을 위한 아키텍쳐(architecture)를 제안한다.
실시예들은 IP 기반 media 전송 시스템이 복수의 네트워크(network)로 구성되어 있는 경우 Multicast 적용을 위한 미디어 스트리밍 아키텍쳐(media streaming architecture)를 제안한다.
실시예들은 IP 기반 media 전송 시스템이 복수의 network 로 구성되어 있는 경우 ABR Multicast 방법을 제안한다.
실시예들은 IP 기반 media 전송 시스템이 복수의 network 로 구성되어 있는 경우 서비스 리스트(service list) 수신 방법(flow) 및 디바이스(device, 실시예들에 따른 멀티캐스트 신호 처리 장치) 동작을 제안한다.
실시예들은 복수의 network 상에서 수신기(device)에 필요한 시그널링 정보를 제안한다.
실시예들에 따른 멀티캐스트 신호 처리 장치에 대응하는 컨텐츠 프로바이더(Content provider) 및 서비스 프로바이더(service provider)의 구성에 따른 멀티캐스트 ABR 구조(multicast ABR architecture)를 제안한다.
실시예들은 복수의 network 기반의 멀티캐스트 미디어 스트리밍(multicast media streaming)을 위한 media architecture를 제시하여, DVB Multicast ABR 구조가 적용될 수 있고, 여러 network 에서도 동일한 수준의 media 서비스가 가능한 효과를 제공한다. 특히, multicast streaming시 수신 device가 접속되어 있는 network 에 의존하지 않고, 다양한 접속 방법을 통해 multicast content를 수신할 수 있다.
따라서, 다양한 기기가 각각 별도의 network에 접속되어 있는 경우, 동일한 수준의 ABR multicast service 를 제공 할 수 있다.
Network의 다양성과 함께, 다양한 기기가 network에 접속하게 되면서, 다양한 device 및 다수의 사용자에게 media streaming이 제공되는 것이 필요하다. 이러한 환경에서 모든 streaming session에 대해, 유니캐스트(unicast)로만 전송되는 경우에는 network의 부하의 증가로 media streaming 서비스뿐만 아니라, 해당 network를 이용한 다른 서비스에 대한 품질이 나빠지는 결과를 초래할 수 있다. 따라서, multicast 효율적인 multicast streaming 전송이 필요하다. 현재, DVB에서 정의 하고 있는 ABR multicast 구조는 multicast 를 제공하는 network가 단일 network 인 경우에 대해 주로 정의 되고 있다. 동일한 서비스를 5G network(무선 네트워크)를 포함하는 다양한 network 를 통해 서비스 하기 위해, 디바이스가 각각의 network 상에서 원활히 동작하도록 할 필요가 있다. 이를 위한 interface 및 architecture의 update가 필요할 수 있다. 또한, 기존의 service provider 가 ABR multicast 를 지원 하기 위해 너무 많은 network 의 변경이 이루어지는 경우, 구현의 어려움 및 비용 문제로 인해 실제 ABR Multicast service 가 제공되지 않는 경우가 될 수 있다.
Multicast 기술은 보편적인 media streaming을 위해 다양한 network 환경에서 서비스를 제공하고 있으며, IP 기반의 network에서 대부분 전송이 가능하다. 또한 복수의 이종 network 에 대해서 동일한 function을 이용하여 ABR multicast 서비스를 제공하기 위해서 각각의 network에 적응된 function 및 architecture 가 필요 하다. ABR multicast service가 여러 network를 통해 제공되는 경우, 사용자 관점에서 service에 대한 연속성을 제공해 주기 위해 service list에 대한 전송 및 이에 대한 관리방안에 대한 정의 가 필요하다.
본 문서에서는 DVB ABR multicast 구조가 다양한 network 를 통해 서비스 될 수 있는 architecture 및 이에 대한 interface를 기술 한다. 또한, 복수의 network를 통해 service list를 제공 하는 방안 및 해당 service list 에 대해 device 내에서 처리하는 interface 및 flow 를 기술 한다.
도1은 실시예들에 따른 멀티캐스트 ABR(Adaptive Bitrate) 구조를 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 도1과 같은 구조에 기반하여 미디어 컨텐츠(Media contents)를 multicast 로 전송할 수 있다. 실시예들에 따른 미디어 컨텐츠는 멀티캐스트 미디어, 멀티캐스트 미디어 데이터, 서비스 데이터 등으로 지칭될 수 있다. 도1의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
도1의 interface는 다음과 같이 정의될 수 있다.
L: 컨텐츠 플레이백부(Content Playback function) 및 멀티캐스트 게이트웨이(Multicast gateway) 사이의 유니캐스트 인터페이스(Unicast HTTP(S) interface)이다.
B: 컨텐츠 플레이백부(Content playback function) 및 멀티캐스트 부트스트랩부(Multicast Bootstrap function) 사이의 부트스트랩 유니캐스트 인터페이스(Bootstrap unicast HTTP(S) interface)이다. 최초 프리젠테이션 마니페스트(presentation manifest)를 요청하는데 사용될 수 있다.
M: 멀티캐스트 서버(Multicast Server)가 Multicast IP contents 전송을 하고 이를 멀티캐스트 게이트웨이(Multicast Gateway)가 수신하기 위한 interface이다.
U: Content Playback function이 content provider로부터 직접 unicast로 media content 를 수신하기 위한 interface이다.
인제스트(Ingest): Media contents를 Multicast Server에 제공하기 위한 interface이다.
CMS: Multicast server 를 configuration 하기 위한 control interface이다.
CMR: Multicast gateway 를 configuration 하기 위한 control interface이다.
Configuration: Content Provider, Provisioning, Multicast Bootstrap function 사이에 configuration 정보를 교환하기 위한 interface이다.
도1의 각 모듈은 다음과 같이 정의 할 수 있다. 각 모듈은 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응할 수 있다.
컨텐츠 프로바이더(Content Provider): Media content를 생성 하거나, 생성된 media content 를 저장하고 있으며, 이를 network를 통해 사용자에게 전달한다. 사용자에게 media content를 전송하기 위해 multicast 및 unicast 전송 방식을 사용 할 수 있으며, Multicast로 전송하기 위해서 multicast server에 ingest interface를 통해 media content data 및 control 정보 등을 제공한다. Media content data는 DASH 또는 HLS 등의 format으로 packaging 될 수 있으며, packaging format 에 따라 presentation manifest를 각각 구성할 수 있다.
멀티캐스트 서버(Multicast Server) - Media Content 를 Content provider로부터 제공 받아, IP Multicast 전송 방식 등을 이용하여, M interface를 통해 Multicast Gateway로 전송한다. 이때, 일부 control 정보가 함께 전송될 수 있다. Multicast protocol은 ROUTE, FLUTE, QUIC, RTP 등을 고려할 수 있다.
멀티캐스트 게이트웨이(Multicast Gateway - Multicast 로 전송되는 패키징된 컨텐츠 세그먼트(content segment)를 수신하고, 이를 다시 HTTP(S) 방식 등을 통해 L interface로 Content playback function에 제공한다. 이를 위해, content segment를 캐쉬(cache) 할 수 있다. 컨텐츠 세그먼트는 분할된 미디어 데이터를 의미할 수 있다. 분할된 미디어 데이터를 저장(캐쉬)할 수 있다.
프로비져닝(Provisioning) (Network Control) - 멀티캐스트 서버(Multicast Server) 및 멀티캐스트 게이트웨이(Multicast Gateway) 에 network 및 multicast streaming session 에 대한 구성(configuration) 정보를 제공한다.
멀티캐스트 부트스트랩(Multicast Bootstrap) - Content playback function이 B interface를 통해 최초 접속 되어야할 주소정보(url 또는 address)를 타겟팅(targeting)하여 처리할 수 있다. Content playback function 으로 부터 reference point B를 통해 오는 presentation manifest에 대한 초기 요청을 처리한다. Multicast 의 경우 L interface를 통한 manifest 수신을 위한 리다이렉션(redirection) 정보를 제공하고, Unicast 의 경우 U interface를 통한 manifest 수신을 위한 redirection 정보를 제공한다. DVB ABR Multicast 구조에서 멀티캐스트 랑데부 서비스(Multicast Rendezvous Service function)를 수행할 수 있다.
컨텐츠 플레이백(Content Playback) - Content playback function은 content의 요청, 수신, 디코딩(decryption), 프리젠테이션(presentation) 등을 관리한다. 인터페이스 L을 통해 unicast 전송을 고려할 수 있다.
어플리케이션(Application) - Application은 사용자의 입력을 바탕으로, Content playback function을 제어한다. 예를 들어, TV 나 set-top box 의 내장 control application (EPG application)또는 Content Provider가 제공하는 third-party application 이 될 수 있다. Application이 Content playback을 제어하는데 사용하는 인터페이스는 각각의 device에 따라 별도의 API 등으로 구현될 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 미디어를 전송하는 동작을 수행하는 관점에서, 멀티캐스트 서버, 멀티캐스트 게이트웨이를 포함하거나, 나아가, 컨텐츠 프로바이더, 프로비져닝, 멀티캐스트 부트스트랩부 등을 포함할 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 미디어를 수신하는 동작을 수행하는 관점에서, 컨텐츠 플레이백부, 어플리케이션 등을 포함할 수 있다.
도2는 실시예들에 따른 멀티캐스트 랑데부 서비스 기반 프리젠테이션 마니페스트 획득 과정을 나타낸다.
도1의 실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 도2와 같이 멀티캐스트 랑데부 서비스를 수행할 수 있다. 도2의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
컨텐츠 플레이백부(content playback function)는 multicast 수신 시 multicast gateway에 contents를 요청하고, unicast인 수신의 경우 컨텐츠 호스팅(content hosting)으로부터 content를 수신한다. 이를 위해 최초 Content playback function이 media contents를 수신을 위한 프리젠테이션 마니페스트(presentation manifest)를 획득하기 위해, 멀티캐스트 랑데부 서비스(Multicast rendezvous service)에 참조 포인트B(reference point B)를 통해 먼저 접속할 수 있다. 멀티캐스트 랑데부 서비스(multicast rendezvous service)는 멀티캐스트(multicast) 및 유니캐스트(unicast) 에 따라 적절하게 presentation manifest 를 획득할 수 있는 URL을 content playback function에 제공할 수 있다.
도3은 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.
도1-2 구조에서 실시예들에 따른 멀티캐스트 방법/장치는 도3과 같이 랑데부 서비스를 실행할 수 있다. 도3의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른 멀티캐스트 랑데부 서비스 배치 방안(Deployment of Multicast Rendezvous service):
멀티캐스트 랑데부 서비스(Multicast rendezvous service)는 HTTP(s) 와 단일 방향(unidirectional) 전송에 대한 지원 여부에 따라, 보통 배치(regular deployment) 및 같이 배치되는 경우(co-located deployment)로 구성될 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 장치의 Content playback function는 다음과 같은 동작을 통해서, manifest url 정보를 획득하고, 미디어 수신을 위한 구성(configuration)을 수행할 수 있다.
보통 배치(Regular deployment) - Multicast rendezvous service 가 Network에 구성되어 있으며, 시스템 오퍼레이터(system operator)에 의해 관리되는 경우.
같이 배치되는 경우(Co-located deployment) - Multicast rendezvous service 가 Multicast gateway와 동일한 장치 내 구현되어 있는 경우
보통 배치(Regular deployment)
도3을 참조하면, Multicast rendezvous service 가 network에 위치하며, system operator에 의해 관리 및 제어되는 구성에 해당한다.
Content playback function은 수신을 희망하는 contents에 최초 접근시, reference point B를 통해 Multicast rendezvous service 로부터 contents 수신을 위한 manifest url 정보를 획득할 수 있다. 이를 위해, 다음과 같은 configuration이 이루어 질 수 있다.
기본적 파라미터(Basic parameter)의 set (예를 들어, 멀티캐스트 게이트ㅜ에이 구성 트랜스포트 세션의 엔드포인트 주소 등)에 대한 configuration이 Multicast gateway에 적용 될 수 있다. 이러한 configuration으로 인-밴드 멀티캐스트 게이트웨이 구성 방법(in-band multicast gateway configuration method)이 사용될 수 있다.
레퍼런스 포인트 CMR(Reference point CMR), 또는 레퍼런스 포인트 CMS(reference point CMS)와 M을 통해 현재 프로비전(provision)되어 있는 멀티캐스트 세션(multicast session)의 set에 대한 configuration이 Multicast gateway에 적용될 수 있다. 이러한 configuration은 in-band multicast gateway configuration method 뿐만 아니라, 아웃-오브-밴드 푸쉬 구성, 아웃-오브-밴드 풀 구성, 저스트-인-타임 구성 방법(out-of-band pushed configuration, out-of-band pulled configuration, Just-in-time configuration method)이 적용될 수 있다.
도4는 실시예들에 따른 멀티캐스트 랑데부 서비스를 위한 구조를 나타낸다.
도4는 도3에서 나아가, 같이 배치되는 경우(Co-located deployment) 를 나타낸다.
Co-located deployment:
도4와 같이, Multicast rendezvous service 가 multicast gateway와 동일한 장치(실시예들에 따른 멀티캐스트 처리 장치)에 구성될 수 있다. 주로 Multicast ABR network가 단일 방향 배치(unidirectional deployment )로 구성되어 있는 경우에 사용될 수 있다. 도4의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
Content playback function은 수신을 희망하는 contents에 최초 접근시, reference point B를 통해 Multicast rendezvous service 로부터 contents 수신을 위한 manifest url 정보를 획득할 수 있다. 이를 위해, 다음과 같은 configuration이 이루어 질 수 있다.
기초 파라미터(Basic parameter) 의 set (ex. 멀티캐스트 게이트웨이 구성 트랜스포트 세션의 엔드포인트 주소 등) 에 대한 configuration 이 Multicast rendezvous service 에 적용될 수 있다.
reference point M을 통해 현재 provision 되어 있는 multicast session의 set에 대한 configuration 이 Multicast gateway 에 적용될 수 있다.
이때, 각각의 configuration은 in-band multicast gateway configuration method가 사용될 수 있다.
도5-6은 실시예들에 따른 멀티캐스트 기반 미디어 수신의 흐름도를 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치(도1-4)는 다음과 같은 흐름도에 기반하여 멀티캐스트 미디어를 수신할 수 있다.
실시예들에 따른 멀티캐스트 오퍼레이션(Multicast operation):
사용자 또는 멀티캐스트 신호 처리 장치가 수신할 multicast contents를 선택하면, 해당 어플리케이션(Application)가 서비스 디렉토리(Service directory) 등을 통해 최초 프리젠테이션 마니페스트(presentation manifest)를 요청할 URL을 획득할 수 있다(5000). 이때 URL은 멀티캐스트 랑데부 서비스(Multicast rendezvous service)를 가리킨다.
어플리케이션(Application)은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service 에 대한 URL을 전달할 수 있다.
Content playback function은 application으로부터 획득한 URL을 이용하여, reference point B를 통해 Multicast rendezvous service에 presentation manifest를 요청한다(5001).
Multicast rendezvous service는 Multicast gateway의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway 에 대한 redirection URL을 content playback function에 전송한다(5002). 이때 전송되는 redirection message에 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 Multicast gateway에 presentation manifest를 요청한다(5003).
Multicast gateway 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다(5004).
Multicast gateway에 presentation manifest가 cache 되어 있지 않은 경우, reference point A를 통해 해당 presentation manifest 를 Content hosting function으로부터 가져 올 수 있으며 이를 다시 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 Multicast gateway를 통해 수신할 수 있다.
이와 같은 동작에서, content playback function이 Multicast rendezvous service에 보내는 HTTP message의 Request URL의 syntax는 다음과 같다:
http[s]://<Host>/<ManifestPath>[?<field>=<value>[&<field>=<value>]*]
도7은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
위URL에 포함되는엘리먼트(element)들은 도7과 같다.
Host: FQDN(또는 IP 주소) 및 선택적으로 멀티캐스트 랑데뷰 서비스의 포트 번호이다.
ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.
AToken: 이 값은 시스템 운영자가 요구하는 경우 멀티캐스트 랑데뷰 서비스에 대한 액세스를 승인하는 인증 토큰이다. 이것은 원래 프레젠테이션 매니페스트 URL에 포함되었을 수도 있고, 이전 HTTP 리디렉션 URL의 일부로 타사 CDN 브로커에 의해 추가되었을 수도 있고, 애플리케이션에 의해 로컬로 생성되었을 수도 있다.
MGstatus: 이 값은 멀티캐스트 게이트웨이의 현재 상태이다: 0 = inactive, 1 = active
MGid: 이 값은 멀티캐스트 게이트웨이의 포트 번호이며 선택적으로 IP 주소가 앞에 온다: 포맷은[IP address]:port이다.
MGhost: 값은 멀티캐스트 게이트웨이 호스트 이름이다.
Ori: 이 값은 원래 대상 호스트의 호스트 이름(FQDN)이다.
어프릴케이션은 원래 대상 호스트 이름(FQDN)을 로컬 멀티캐스트 랑데뷰 서비스 호스트 이름 또는 주소로 대체할 수 있다. 또한 타사 CDN 브로커에 의존하는 경우 후자는 멀티캐스트 랑데뷰 서비스로 요청을 리디렉션하기 전에 원래 대상 호스트 이름(FQDN)을 여기에서 나타낼 수 있다.
Multicast rendezvous service 는 이러한 request URL 을 수신 하면, 307 Temporary Redirect 응답을 보낼 수 있다. 여기에서, Location response header 의 Redirect URL 의 syntax는 다음과 같다:
http[s]://<Host>[/session ID]/<ManifestPath>[?conf=<multicast session
도8은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
위 URL에 포함되는 엘리먼트들은 도8과 같다.
Host: 멀티캐스트 게이트웨이의 IP 주소 또는 FQDN 및 선택적으로 포트 번호(예: "router.example:8088" 또는 "192.0.2.1:8088")이다.
Session ID: 하나 이상의 URL 경로 요소를 포함하는 멀티캐스트 랑데뷰 서비스에 의해 전달되고 생성될 수 있는 고유한 프레젠테이션 세션 식별자이다.
ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.
conf: 멀티캐스트 세션 매개변수는 하나의 멀티캐스트 세션을 포함하는 멀티캐스트 게이트웨이 구성 인스턴스 문서의 형식을 취한다.
문서는 URL 쿼리 문자열 매개변수로 포함되기 전에 Gzip 및 base64url 인코딩을 사용하여 압축된다.
이때, presentation manifest 가 multicast session configuration내의 multicast session 과 관련된 것이면 (service를 multicast로 전송 가능), Multicast rendezvous service는 다음과 같이 request를 Multicast gateway로 redirection 할 수 있다:
HTTP/1.1 307 Temporary Redirect
Server: <Multicast gateway>
Location: http[s]://<Multicast gateway>/<ManifestPath>
HTTP header의 Location field 에 해당 하는 URL은 session identifier 와 요청된 presentation manifest 에 해당 하는 multicast session을 포함하는 multicast gateway configuration instance document를 piggybacking 하는 query parameter 를 포함할 수 있다.
실시예들에 따른 멀티캐스트 ABR은 5G 네트워크(통신 네트워크)와 연결될 수 있다.
도9는 실시예들에 따른 5G 미디어 스트리밍에 대한 멀티캐스트 적용 방안을 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 5G media streaming 구조에서 multicast를 지원할 수 있다(Multicast ABR architecture). 도9는 Multicast ABR architecture 를 적용한 5G Media streaming architecture에 대한 실시예를 도시한 것이다. 즉, 5G 구조 및 DVB 구조가 서로 결합될 수 있다.
5G 어플리케이션 프로바이더(5GMSd Application Provider)는 도1-6 등의 Multicast ABR 의 Content Provider와 동일하거나, Content Provider의 부분일 수 있다. 해당 5G media streaming 을 수신 하기 위한 어플리케이션(5GMSd Aware Application)은 도1-6 등의 Multicast ABR 의 Application 과 동일하거나, Application의 부분일 수 있다. 클라이언트(5GMSd Client)는 도1-5 등의 Multicast ABR의 content playback function 과 동일하거나, content playback function의 부분일 수 있다. 제어부(5GMSd AF) 에는 도1-6 등의 Multicast ABR 의 network control sub function을 포함하는 provisioning function과, multicast rendezvous service 를 포함하는 multicast bootstrap function이 포함될 수 있다.
5GMSd Client 가 최초 multicast 전송을 위한 접속 정보(access information) (presentation manifest url)은 M5d interface를 통해 요청 및 수신될 수 있으며, 이것은 도1-6 등의 Multicast ABR의 B interface의 에 해당할 수 있다.
유니캐스트 스트리밍(Unicast streaming)은 M4d interface를 통해 5GMSd AS 로부터 Media Player로 전송되며, 이때, HTTP(s)가 이용될 수 있다.
5GMSd AS 와 Media Player 사이의 multicast 전송을 위해 Multicast server 및 Multicast Gateway 가 구성될 수 있다. Multicast Gateway 와 Media Player 사이에는 5G RAN을 통해 data가 전송되므로, Unicast 만 지원될 수 있다.
Multicast 전송을 위해 다음과 같이 인터페이스 M4d_M 및 M4d_L 을 정의 할 수 있다.
M4d_M - Multicast streaming은 M4d_M interface를 통해 5GMSd AS 로부터 multicast server로 전송되고, multicast server 와 multicast gateway 사이는 multicast ABR 에서 정의 된 M interface가 이용될 수 있다. 또다른 실시예로, 5GMS AS 내에 multicast server 기능이 포함 될 수 있다. 이 경우, M4d_M interface는 생략될 수 있다. Multicast protocol 은 M interface에서 정의 된 protocol이 사용될 수 있다.
M4d_L - Multicast gateway 와 Media player 사이는 M4d_L interface 가 이용될 수 있다. 여기에서, M4d_M 과 M4d_L 은 HTTP(s) 를 기반으로 하는 protocol을 이용할 수 있으며, DVB Multicast ABR 관점에서 M4d_M 은 ingest interface, M4d_L 은 L interface에 해당 할 수 있다.
도10은 실시예들에 따른 멀티캐스트 네트워크 및 통신 네트워크 스트리밍 모두를 위한 멀티태스트 스트리밍 구조를 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 Multicast streaming 이 DVB Multicast ABR network 와 5G Media streaming 에 동시에 서비스 되는 경우, 미디어 컨텐츠를 송수신하고 처리할 수 있다. 도10의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
Multicast streaming 이 서비스 되는 복수의 network 가 존재할 수 있으며, 5G network 가 그 중 하나라고 할 때, 실시예들에 따른 동일한 content provider 로 부터 5G mobile network 와 그 외의 IP network를 통해 동시에 multicast 서비스 되는 유즈 케이스(use case)를 고려할 수 있다. 도10은 Multicast streaming이 5G network 및 DVB Multicast ABR network에 동시에 service 되는 실시 예에 대해 도시한 것이다.
멀티캐스트 세션 구성(multicast session configuration)을 위한 프로비져닝(provisioning)은 및 각각의 network의 특성에 따라 별도로 정의 될 수 있다. Multicast server 에서 multicast gateway로 media를 전달하는 multicast interface M은 동일하게 구성 될 수 있다.
이때, 5G network 에서 정의 되는 M2d 및 M4d_M interface는 Ingest interface와 동일한 interface 가 될 수 있다. 이로 인해, content provider 에서는 각각의 network 를 통해 전송되는 protocol을 동일하게 유지할 수 있다.
도11은 실시예들에 따른 통신 네트워크에서 멀티캐스트 및 브로드캐스트에 기초하여 무선 미디어 전송을 하는 아키텍쳐를 나타낸다.
5G RAN 에서 multicast 및 broadcast 무선 전송이 지원 되는 경우, multicast gateway 가 5G UE 내부에 구성될 수 있다. 도11의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
5GMSd Application Provider는 Multicast ABR 의 Content Provider와 동일하거나, Content Provider의 부분일 수 있다. 해당 5G media streaming 을 수신 하기 위한 5GMSd Aware Application 은 Multicast ABR 의 Application 과 동일하거나, Application의 부분일 수 있다. 5GMSd Client는 Multicast ABR의 content playback function 과 동일하거나, content playback function의 부분일 수 있다. 5GMSd AF 에는 Multicast ABR 의 network control sub function을 포함하는 provisioning function과, multicast rendezvous service 를 포함하는 multicast bootstrap function이 포함될 수 있다.
5GMSd Client 가 최초 multicast 전송을 위한 access information (presentation manifest url)은 M5d interface를 통해 요청 및 수신될 수 있으며, 이것은 Multicast ABR의 B interface의 에 해당할 수 있다.
Unicast streaming은 M4d interface를 통해 5GMSd AS 로부터 Media Player로 전송되며, 이때, HTTP(s)가 이용될 수 있다.
5GMSd AS 와 Media Player 사이의 multicast 전송을 위해 Multicast server 및 Multicast Gateway 가 구성될 수 있다. 이러한 경우 Multicast Gateway 와 Media Player 사이의 interface M4d_L은 UE 내부의 interface로 구현 될 수 있다.
Multicast server 와 multicast gateway 사이의 interface M4d_M 는 multicast ABR 에서 정의 된 M interface 와 동일한 interface로 정의 될 수 있다. 따라서, Multicast protocol 은 M interface에서 정의 된 protocol이 사용될 수 있다.
실시예들에 따른 방법/장치/프로세서(멀티캐스트 신호 처리 방법/장치)는 상술한 네트워크 제어 동작들을 수행하고, 관련 시그널링 정보에 기반하여, 5G network 기반의 multicast media streaming 을 위한 media architecture를 제공할 수 있다. 실시예들에 따른 동작들은 multicast streaming시 수신 device가 접속되어 있는 network 에 의존하지 않고, 다양한 접속 방법을 통해 multicast content를 수신할 수 있는 효과를 제공한다. 또한, multicast 전송 구조를 제시함으로써, 동일한 content 를 복수의 수신기에 전송하여 network 의 자원을 효율적으로 사용할 수 있다.
실시예들은 멀티플 IP네트워크들 기반 MABR 아키텍쳐를 포함한다.
실시예들에 따른 멀티플 IP네트워크들은 통신, 방송망 등 다양한 네트워크 등을 포함할 수 있다.
실시예들에 따른 ABR multicast 구조 및 interface가 실제 서비스 되기 위해 각각의 network에 적용 되기 위해 추가적인 architecture 구성 및 이에 대한 interface 의 적용 방안에 대해 기술한다. 실시예들에 따른 아키텍쳐에 포함된 각 구성요소는 하드웨어, 소프트웨어, 프로세서 및/또는 그것들의 조합에 대응할 수 있다.
도9내지 11은 도1내지 도6에 도시된 실시예들에 따른 멀티캐스트 신호 처리 방법/장치에 대응한다.
도12-13은 실시예들에 따른 각 네트워크에서 멀티캐스트 서버 구성 예시를 나타낸다.
도12-13은 multicast server 가 각각의 network 마다 구성되어 ABR multicast service를 제공하는 구조에 대한 실시예를 나타낸다. 주로 multicast service server가 network operator 에 의해 deployment 되어 있는 경우에 해당 한다. 실시예들에 따른 송수신 장치는 다음 그림의 멀티캐스트 서버 구조에 기반하여 ABR 멀티캐스트 서비스를 제공할 수 있다. 도12-13의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
복수의 이종 network를 통해, ABR multicast 가 service 되는 경우는 ABR multicast를 수신 하는 multicast gateway의 deployment가 별도로 이루어 질 수 있다.
Multicast gateway (A) - ISP network에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 ISP operator로부터 제공되는 router 또는 home gateway 내에 구성 될 수 있다.
Multicast gateway (B) - 5G 시스템과 같은 Mobile network 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 mobile network의 edge 내에 구성 될 수 있다.
Multicast gateway (C) - 위성 방송 network에 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 위성 방송을 수신할 수 있는 STB 내에 구성 될 수 있다.
Multicast gateway (D) - Terrestrial Broadcast network서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 broadcast 수신기 내에 구성 될 수 있다.
이러한 ABR multicast service 가 복수의 이종 네트워크를 통해 제공 되는 경우라 하더라도, 각각의 네트워크에 대해서 독립적으로 ABR multicast function이 구성될 수 있다.
도14-15는 실시예들에 따른 모든 네트워크들에 대한 멀티캐스트 서버 구성 예시를 나타낸다.
단일 Multicast server가 복수의 이종 network를 통해 ABR multicast service를 제공하는 구조에 대한 실시 예를 나타낸다. 주로 multicast service server가 content provider에 의해 deployment 되어 있는 경우에 해당 한다. 실시예들에 따른 송수신 장치는 다음 그림의 멀티캐스트 서버 구조에 기반하여 ABR 멀티캐스트 서비스를 제공할 수 있다.
도14-15의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
복수의 이종 network를 통해, ABR multicast 가 service 되는 경우는 ABR multicast를 수신 하는 multicast gateway의 deployment가 별도로 이루어 질 수 있다.
Multicast gateway (A) - ISP network에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 ISP operator로부터 제공되는 router 또는 home gateway 내에 구성 될 수 있다.
Multicast gateway (B) - 5G 시스템과 같은 Mobile network 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 mobile network의 edge 내에 구성 될 수 있다.
Multicast gateway (C) - 위성 방송 network에 에서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 위성 방송을 수신할 수 있는 STB 내에 구성 될 수 있다.
Multicast gateway (D) - Terrestrial Broadcast network서 ABR multicast 의 서비스를 위해 multicast gateway가 구성되는 경우에는 broadcast 수신기 내에 구성 될 수 있다.
이러한 ABR multicast service 가 복수의 이종 네트워크를 통해 제공 되는 경우라 하더라도, 각각의 네트워크에 대해서 독립적으로 ABR multicast function이 구성될 수 있다.
도16은 실시예들에 따른 장치가 접속하는 멀티플 네트워크 예시를 나타내다.
실시예들에 따른network 구조에서, 복수의 network 에 접속하여 동일한 multicast media service를 수신 할 수 있는 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 고려할 수 있다. 복수의 network 에 접속하여 동일한 multicast streaming service를 수신 할 수 있는 실시예들에 따른 멀티캐스트 신호 처리 방법/장치에 대한 architecture 및 ABR multicast interface에 대한 실시예에 대해 기술한다. 실시예들은 다양한 아키텍쳐들로 구현될 수 있다.
다음은 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 regular deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도16과 같다. 도16의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, mobile network 에 접속하는 경우를 고려할 수 있다.
Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
도12 내지 도16은 도1-6, 도9-11 등 실시예들에 따른 멀티캐스트 신호 처리 장치가 실시예들에 따른 네트워크들 타입에 따라 구성되는 예시를 나타낸다.
다음은 이러한 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.
실시예들에 따른 네트워크 변경은, 예를 들어, 네트워크A (WI-FI) 및 네트워크B (5G) 간 변경을 포함할 수 있다.
도17, 도18, 도19은 실시예들에 따른 네트워크 변경에 관한 흐름도를 나타낸다.
도17-19의 흐름도는 도1-6, 9-16 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.
각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.
Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server (A) 와 multicast server (B)에 전달한다.
도51-52에 도시된 멀티케스트 세션 엘리먼트를 통해서, 멀티캐스트 세션에 대한 구성 정보를 전달할 수 있다.
Multicast session이 시작되면, content provider 로부터 multicast server (A) 와 multicast server (B)에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.
Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.
Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
도50에 도시된 서비스 리스트 엘리먼트를 통해서, 서비스 리스트를 전달할 수 있다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.
도52에 도시된 마니페스트 요청 및 리다이렉션 정보를 통해서, 마니페스트를 요청할 수 있다.
Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
도52에 도시된 마니페스트 요청 및 리다이렉션 정보를 통해서, 리다이렉션을 수행할 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.
도47-49에 도시된 프리젠테이션 마니페스트를 요청할 수 있다.
Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming 이 multicast server(A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.
Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.
Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.
Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.
Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming이 multicast server(B) 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.
Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
도20은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다.
실시예들은 도16의 구성에서 더 나아가, 도20과 같이, 네트워크 서버 및 게이트웨이를 포함할 수 있다.
Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, Multicast rendezvous service가 regular deployment 및 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도20과 같다. 도20의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
상기 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, 위성 방송 network를 통한 셋탑박스에 접속하는 경우를 고려할 수 있다.
Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
도21, 도22, 도23은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도21-23의 흐름도는 도1-6, 9-16, 20 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다. 도17-19과 차이는 도21-23의 네트워크는 하나의 네트워크가 양방향 네트워크가 아닌 경우를 포함하는 것이다.
Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.
각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.
Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server (A) 와 multicast server (B)에 전달한다.
Multicast session이 시작되면, content provider 로부터 multicast server (A) 와 multicast server (B)에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.
Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.
Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.
Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.
Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming 이 multicast server(A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.
Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.
Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 및 rendezvous service (B)를 가리킨다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 또는 Multicast rendezvous service (B)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(B) 또는 Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.
Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.
Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따른다.
획득된 URL을 이용하여, reference point L2을 통해 Multicast gateway(B)에 presentation manifest를 요청한다.
Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming이 multicast server(B) 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.
Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
도24는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다
다음은 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도24과 같다. 도24의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 위성 방송 network를 통한 셋탑박스에 접속하면서 동시에, 지상파 방송 network를 통한 방송 수신을 하는 경우를 고려할 수 있다. 실시예들에 따른 네트워크 타입이 상이할 수 있다. 둘다 단"눰* 네트워크일 수 있다.
Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (B) 와 multicast rendezvous service (B)는 device 내에 구성되어 있으므로, L2, B2 interface는 device 내부 interface 로 대체할 수 있다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
도25, 도26, 도27는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도25-27의 흐름도는 도1-6, 9-16, 24 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.
Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.
각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.
Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server (A) 와 multicast server (B)에 전달한다.
Multicast session이 시작되면, content provider 로부터 multicast server (A) 와 multicast server (B)에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.
Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.
Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(A) 또는 Multicast rendezvous service (A)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(A) 또는 Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.
Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.
Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따른다.
획득된 URL을 이용하여, reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.
Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming 이 multicast server(A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.
Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.
Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
Multicast gateway 와 multicast rendezvous service가 device 내에 구성되어 있으므로 interface L2 및 B2 관련 operation은 선택적으로 수행될 수 있다.
수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.
Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.
Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming이 multicast server(B) 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.
Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
다음은 멀티플 네트워크들에 접속 가능한 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 더 설명한다. 실시예들에 따른 기술한 network 구조에서, 복수의 network 에 접속하여 동일한 multicast media service를 수신 할 수 있는 device 를 고려할 수 있다. 복수의 network 에 접속하여 동일한 multicast streaming service를 수신 할 수 있는 device에 대한 architecture 및 ABR multicast interface에 대한 실시예에 대해 기술한다.
실시예들에 따른 멀티캐스트 랑데부 서비스는 방송의 부트스트램과 다르다. 네트워크에서 랑데부 플로우는 단말이 네트워크에 접속하고자 할 때 네트워크 최초 어드레스를 단말에 제공하는 과정이다.
랑데부 기능은 실시예들에 따른 네트워크가 수행할 수 있다. 부트스트랩은 단말이 수행하는 것일 수 있다. 랑데부서비스는 어드레스나 URL이 고정되어 있을 수 있다. 수신기가 네트워크 외부에 있을 경우, 단말이 처음 접속 시 미디어 수신을 위해서 접속했으니 미디어를 위한 주소를 단말에 리다이렉션한다. 단말은 리다이렉션 주소를 가지고 실제 미디어를 위한 메니페스트를 받을 수 있다. 멀티캐스트 랑데부 서비스는 미디어 송수신이 멀티캐스트 방식이라서 미디어가 이미 다른 누군가가 보고 있는 미디어라서, 이러한 서비스가 요구된다.
도28은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타내다.
다음은 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 regular deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도28와 같다. 도28의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, mobile network 에 접속하는 경우를 고려할 수 있다.
Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
도29, 도30, 도31은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도29-31의 흐름도는 도1-6, 9-16, 28 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.
Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.
각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.
Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server 에 전달한다.
Multicast session이 시작되면, content provider 로부터 multicast server 에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.
Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.
Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.
Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.
Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming 이 multicast server 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.
Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.
Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.
Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.
Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.
Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
도32는 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 를 구성하는 예시를 나타낸다.
다음은 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, Multicast rendezvous service가 regular deployment 및 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도29와 같다. 도29의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 ISP network 를 통해 Wi-Fi 에 접속과 동시에, 위성 방송 network를 통한 셋탑박스에 접속하는 경우를 고려할 수 있다.
Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
도33, 도34, 도35는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도33-35의 흐름도는 도1-6, 9-16, 32 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.
Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.
각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.
Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server 에 전달한다.
Multicast session이 시작되면, content provider 로부터 multicast server에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.
Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.
Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (A)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.
Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.
Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming 이 multicast server 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.
Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.
Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 및 rendezvous service (B)를 가리킨다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 또는 Multicast rendezvous service (B)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(B) 또는 Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.
Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.
Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따른다.
획득된 URL을 이용하여, reference point L2을 통해 Multicast gateway(B)에 presentation manifest를 요청한다.
Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.
Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
도36은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우, 모든 multicast rendezvous service가 co-located deployment 로 구성되는 예시를 나타내다.
다음은 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도36과 같다. 도36의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다. 서버가 네트워크의 외부에 위치할 수 있다.
실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다. 예를 들어, device 가 위성 방송 network를 통한 셋탑박스에 접속하면서 동시에, 지상파 방송 network를 통한 방송 수신을 하는 경우를 고려할 수 있다.
Device 내의 content playback function은 두개의 L interface (L1, L2) 및 두개의 B interface (B1, B2)가 구성 될 수 있다. L1 interface 를 통해 multicast gateway(A)를 통해 media streaming 을 수신할 수 있으며, B1 interface를 통해 초기 multicast gateway(A) 에 대한 접속 정보를 수신 할 수 있다. L2 interface 를 통해 multicast gateway(B)를 통해 media streaming 을 수신할 수 있으며, B2 interface를 통해 초기 multicast gateway(B) 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (B) 와 multicast rendezvous service (B)는 device 내에 구성되어 있으므로, L2, B2 interface는 device 내부 interface 로 대체할 수 있다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
도37, 도38, 도39은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도37-39의 흐름도는 도1-6, 9-16, 36 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.
Multicast Server 와 관련한 flow 는 다음과 같이 진행된다.
각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.
Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server에 전달한다.
Multicast session이 시작되면, content provider 로부터 multicast server에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.
Device 가 network A 에 접속하게 되면 다음과 같이 동작할 수 있다.
Application 은 network A를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(A) 또는 Multicast rendezvous service (A)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(A) 또는 Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.
Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있으므로 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.
Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따른다.
획득된 URL을 이용하여, reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.
Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming 이 multicast server 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.
Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
이 상태에서, device 가 network A 에서 network B로 접속을 변경하게 되면 다음과 같이 동작할 수 있다.
Application 은 network B를 거쳐 service provider 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. Network A를 통해 수신된 multicast session 을 이어서 수신 하기 위해 해당 service ID 에 대한 session 정보를 교환 할 수 있다. 수신된 service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
Multicast gateway 와 multicast rendezvous service가 device 내에 구성되어 있으므로 interface L2 및 B2 관련 operation은 선택적으로 수행될 수 있다.
수신중에 있는 service 에 대해, Application에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast rendezvous service (B)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application으로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.
Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L2를 통해 Multicast gateway(B)에 presentation manifest를 요청한다.
Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M2 interface를 통해 전송된다.
Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
다음은 멀티플 네트워크들에 접속 가능한 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 더 설명한다.
각 네트워크 상에서 멀티캐스트 서버가 위치할 수 있다.
도40-41은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 실시예를 나타낸다.
실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 앞서 기술한 바와 같이, 앞서 기술한 내용을 바탕으로, Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 경우에 대한 실시예를 나타낸다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도40-41과 같다.
도38은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 제공하며, 이에 대한 multicast gateway가 각각의 network 에 구성되는 구조를 나타낸다.
다음은 앞서 기술한 바와 같이, 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 경우에 대한 실시예를 나타낸다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 다음과 같다.
실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
도16 내지 도43 등에 따라, 실시예들에 따른 송수신 장치는 실시예들에 따른 동작에 기반하여, DVB Multicast ABR 및 5G media streaming 를 다양한 네트워크 환경에서 효율적으로 제어하고, 제공할 수 있는 효과가 있다.
다음은 실시예들에 따른 수신 동작 및 수신 장치를 위한 동작을 설명한다.
전술한 실시예들에 따른 아키텍쳐들에 대하 다음과 같은 프로토콜이 구현될 수 있다..
실시예들에 따른 기술된 architecture 를 바탕으로, 복수의 전송 network 에 접속 하여 ABR multicast streaming을 수 있는 device를 위해 필요한 element 및 attribute 를 정의 한다.
실시예들에 따른 수신기는 송신기의 동작을 역과정을 수행할 수 있다. 실시예들에 따른 수신기는 이하의 동작에 기반하여 ABR multicast streaming을 수행할 수 있다. 실시예들에 따른 수신기는 이하의 네트워크 구조에 기반하여, ABR multicast streaming을 수행할 수 있다.
다음은 수신 장치들 내 프로토콜 스택들 예시이다.
도39는 실시예들에 따른 ABR 멀티캐스트를 위한 프로토콜 구성을 나타낸다.
Multicast ABR 전송을 위해 multicast server에서 M interface를 통해 multicast streaming을 전송 할 수 있다. 이때, multicast 전송 protocol로 ROUTE 또는 FLUTE를 사용할 수 있다. Multicast gateway는 playback function에 L interface를 통해 HTTP 기반의 adaptive media streaming을 위해 DASH 또는 HLS 를 사용 할 수 있다. Playback function 에는 multicast gateway로부터 HTTP 기반의 adaptive media streaming 수신을 위한 protocol 과, 수신된 adaptive streaming 에 대한 file format 과 media coded 이 구성될 수 있다. 여기에서, Layer 1 및 Layer 2 protocol은 각각의 network에 최적의 protocol로 구성될 수 있다.
복수의 네트워크들에 접속하기 위해서 실시예들은 다음과 같은 프로토콜들을 포함할 수 있다.
도45는 실시예들에 따른 복수의 network에 접속하기 위해 수신 장치에 구성될 수 있는 protocol 에 대한 실시 예를 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 장치가 수신 장치로 구현될 때, 전술한 실시예들에 따른 아키텍쳐들 상 구현되는 프로토콜을 나타낸다.
실시예들에 따른, network A 에는 multicast gateway 가 network 에 구성되어 있고, network B에 대해서는 multicast gateway가 device 내에 구성되어 있는 경우를 고려 한다.
실시예들에 따른, network A를 통해 ABR multicast streaming을 서비스 하기 위해 network상에 구성되어 있는 multicast gateway 는 multicast server로부터 multicast streaming을 수신하고 이를 L interface를 통해 HTTP 기반의 adaptive media streaming 방식으로 device로 전송한다. 따라서, device 에서는 L interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.
또한, network B를 통해 ABR multicast streaming을 수신하기 위해서는 device 내에 multicast gateway가 구성되는 것을 고려할 수 있다. 따라서, device 에서는 network B 에 대한 M interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.
따라서, 복수의 network 에 접속하여 ABR multicast 서비스를 수신 하기 위한 수신기 device 내에는 M interface 및 L interface에 대한 protocol이 동시에 구성될 수 있다. 이때, device 내의 multicast gateway function은 network 상에 구성되어 있는 multicast gateway와 동일한 방식으로, multicast streaming 을 HTTP 기반의 adaptive media streaming 으로 전환하여 device 내의 L interface로 전달할 수 있다.
도46은 실시예들에 따른 프로토콜을 나타낸다.
실시예에서, network A 에는 multicast gateway 가 network 에 구성되어 있고, network B에 대해서는 multicast gateway가 device 내에 구성되어 있는 경우를 고려 한다.
실시예에서, network A를 통해 ABR multicast streaming을 서비스 하기 위해 network상에 구성되어 있는 multicast gateway 는 multicast server로부터 multicast streaming을 수신하고 이를 L interface를 통해 HTTP 기반의 adaptive media streaming 방식으로 device로 전송한다. 따라서, device 에서는 L interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.
또한, network B를 통해 ABR multicast streaming을 수신하기 위해서는 device 내에 multicast gateway가 구성되는 것을 고려할 수 있다. 따라서, device 에서는 network B 에 대한 M interface를 통해 adaptive media streaming을 수신할 수 있는 protocol stack이 구성될 수 있다.
따라서, 복수의 network 에 접속하여 ABR multicast 서비스를 수신 하기 위한 수신기 device 내에는 M interface 및 L interface에 대한 protocol이 동시에 구성될 수 있다. 이때, device 내의 multicast gateway function은 network 상에 구성되어 있는 multicast gateway와는 달리, device 내에서 L interface 가 구성될 수 있으며, 이때의 L interface는 별도의 interface 없이, 직접 protocol stack으로 구성할 수 있다. Device에서는 network A를 통해 수신되는 streaming 의 경우, playback function으로 동작하고, network B를 통해 수신되는 streaming 의 경우 multicast gateway로 동작 할 수 있다. Multicast gateway로 동작하는 경우에는 L interface 가 생략되고, multicast protocol의 payload가 adaptive media streaming data 가 될 수 있다.
다음음 실시예들에 따른 서비스 리스트 및 프리젠테이션 마니페스트를 생성하고 송수신하는 동작을 설명한다.
도47은 실시예들에 따른 서비스 및 서비스에 관한 정보의 구성을 나타낸다.
DASH 기반의 ABR multicast service 에 대해서, 실시예들에 따른 서비스 프로바이더(service provider )는 service list와 함께, 다음과 같이 presentation manifest (ex. MPD)를 구성할 수 있다. Service 를 제공하는 측면에서는 동일한 contents 에 대한 service list 및 presentation manifest 에 대해서는 중복되지 않도록 구성될 수 있다.
도48은 실시예들에 따른 ABR 멀티캐스트를 위한 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 전송하는 방법을 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 ABR 멀티캐스트를 지원하기 위해서, 도48과 같이 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 송수신할 수 있다.
ABR Multicast architecture에 정의 되어 있는 interface 에 따라 전송할 수 있는 element 가 결정될 수 있다. 수신기 device의 application은 service list directory 로부터 service list를 수신받을 수 있으며, service id 와 multicast rendezvous service에 대한 url을 포함할 수 있다. 해당 url을 통해 content playback function이 multicast rendezvous service에 manifest를 요청하면, multicast rendezvous service의 redirection message를 통해 multicast gateway 의 address 및 해당 manifest 에 대한 path를 획득하여, L interface를 통해 presentation manifest를 수신 할 수 있다. Multicast gateway는 multicast server로부터 해당 presentation manifest (ex. MPD)를 수신할 수 있으며, 이를 위해 multicast session configuration 정보를 획득할 수 있다.
도49는 실시예들에 따른 service list 및 presentation manifest 관리를 나타낸다.
실시예들에 따른 수신 장치에서 도49와 같이 service list 및 presentation manifest 를 관리할 수 있다. 실시예들에 따른 구조로 구성된 service list 및 presentation manifest (ex. MPD) 에 대해서, 복수의 network 를 통해 ABR multicast 서비스를 수신할 수 있는 수신기 내에는 다음과 같이 service list 가 관리 될 수 있다.
즉, 동일한 서비스에 대해서 네트워크 1 및 네트워크2와 같은 멀티플 네트워크들에 대한 MPD를 생성하고 송수신할 수 있다.
실시예에서, 복수의 network 를 이용하여 ABR multicast service 수신하는 device에서 각각의 network 에서 제공되는 adaptation set이 상이할 수 있으므로, network에 따라 별도로 presentation manifest를 구성하여 관리한다.
ABR multicast service 수신 function이 TV 등에서 구성되고 해당 수신기에 방송 contents 도 동시에 수신될 때, 실시예들에 따른 service list는 channel map 과 같이 관리 될 수 있다.
도50은 실시예들에 따른 서비스 리스트를 나타낸다.
도50은 도6, 17-19, 21-23, 25-27, 29-31, 33-35, 37-39 등에서 송수신되는 서비스 리스트의 신택스를 나타낸다.
서비스 리스트(ServiceList) - service 에 대한 구성정보를 포함하는 root element이다.
서비스 식별자(@serviceIdentifier) - service 를 식별할 수 있는 식별자이다.
프리젠테이션 마니페스트 요청 주소(PresentationManifestRequestURL)- 하나의 service에 대해서 복수의 멀티캐스트 랑데부 서비스(multicast rendezvous service)를 통해 configuration 될 때, multicast rendezvous service 에 대한 정보를 위한 element이다.
네트워크 타입(@NetworkType)- Multicast rendezvous service가 위치한 network type이다. device가 network에 동시에 접속하였을 때, 우선순위 설정에 사용할 수 있다.
호스트 주소(@HostAddress)- 해당하는 multicast rendezvous service의 address이다.
랑데부 서비스 타입(@RendezvousServerType)- multicast rendezvous service의 deployment 에 대한 attribute이다. 예를 들어, 0: regular deployment(보통 배치), 1: co-located deployment(함께 배치)
멀티캐스트 트랜스포트 세션(MulticastTransportSession)- multicast transport session 에 대한 element는 device 가 multicast gateway를 포함하는 경우에 optional 로 전송할 수 있다. MulticastTransportSession element 를 보내지 않는 경우에는 multicast gateway configuration을 통해 정보를 제공할 수 있다.
도51은 실시예들에 따른 멀티캐스트 세션을 나타낸다.
다음은 multicast session element의 구성에 대한 실시예를 나타낸다. Multicast session element는 provisioning function으로부터 multicast server 및 multicast gateway로 전송된다. 따라서 각각 CMS 및 CMR interface가 사용될 수 있다. Network가 unidirectional 전송만 지원 하는 경우, CMS interface를 통해 multicast server로 전달된 후, M interface를 통해 multicast server 로부터 multicast gateway로 전달될 수 있다.
@serviceIdentifier: 이 세션이 연결된 논리 서비스의 서비스 식별자이다.
@contentPlaybackAvailabilityOffset : Duration string 콘텐츠 재생 기능의 인스턴스에 전달될 때 원래 프레젠테이션 매니페스트에 적용되는 가용성 시간 오프셋 조정이다.
@networkIdentifier: 현재 멀티캐스트 세션이 전송되는 네트워크의 식별자이다.
PresentationManifestLocator: 선형 서비스에 대한 프레젠테이션 매니페스트의 URL이다.
@manifestId: 멀티캐스트 세션 범위 내에서 이 프레젠테이션 매니페스트를 고유하게 식별한다.
@contentType: 이 프레젠테이션 매니페스트의 MIME 콘텐츠 유형이다.
MulticastTransportSession: 멀티캐스트 전송 세션 매개변수용 컨테이너이다.
@networkIdentifier - 현재의 multicast session이 서비스 되고 있는 network 에 대한 식별자. 수신기에서 동일한 multicast service가 수신되는 network를 식별할 수 있다.
실시예들에 따른 마니페스트 요청 및 리다이렉션 동작(Manifest request and redirection)
위와 같은 architecture에서, content playback function이 Multicast rendezvous service에 보내는 HTTP message의 Request URL의 syntax는 다음과 같다.
http[s]://<Host>/<ManifestPath>[?<field>=<value>[&<field>=<value>]*]
실시예들에 따른 URL에 포함되는 element들은 도52와 같다.
도52는 실시예들에 따른 HTTP message의 Request URL에 포함되는 엘리먼트를 나타낸다.
Host: FQDN(또는 IP 주소) 및 선택적으로 멀티캐스트 랑데뷰 서비스의 포트 번호이다.
ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.
AToken: 값은 시스템 운영자가 요구하는 경우 멀티캐스트 랑데뷰 서비스에 대한 액세스를 승인하는 인증 토큰이다. 이것은 원래의 프리젠테이션 매니페스트 URL에 포함되었을 수도 있고, 이전 HTTP 리디렉션 URL의 일부로 타사 CDN 브로커에 의해 추가되었을 수도 있고, 애플리케이션에 의해 로컬로 생성되었을 수도 있다.
Priority: 다중 네트워크 구축 시 프레젠테이션 검색 우선 순위이다.
MGstatus: 값은 멀티캐스트 게이트웨이의 현재 상태이다. 예를 들어, 0 = inactive, 1 = active
MGid: 값은 멀티캐스트 게이트웨이의 포트 번호이며 선택적으로 IP 주소가 앞에 온다. 포맷은 다음과 같다: [IP address]:port.
MGhost: 값은 멀티캐스트 게이트웨이 호스트 이름이다.
Ori: 값은 원래 대상 호스트의 호스트 이름(FQDN)이다.
응용 프로그램은 원래 대상 호스트 이름(FQDN)을 로컬 멀티캐스트 랑데뷰 서비스 호스트 이름 또는 주소로 대체할 수 있다. 또한 타사 CDN 브로커에 의존하는 경우 후자는 멀티캐스트 랑데뷰 서비스로 요청을 리디렉션하기 전에 원래 대상 호스트 이름(FQDN)을 여기에서 나타낸다.
Priority - Playback function 이 multicast rendezvous service 에 manifest를 요청할 때, 해당 multicast rendezvous service가 복수의 multicast gateway로 redirection하는 것이 가능 할 때, 각각의 multicast gateway가 구성되어 있는 network에 차등적인 priority 를 부여하여, multicast 수신의 우선 순위를 결정 할 수 있다.
Multicast rendezvous service 는 실시예들에 따른 request URL 을 수신 하면, 307 Temporary Redirect 응답을 보낼 수 있다. 여기에서, Location response header 의 Redirect URL 의 syntax는 다음과 같다.
http[s]://<Host>[/session ID]/<ManifestPath>[?conf=<multicast session
실시예들에 따른 URL에 포함되는 element들은 다음과 같다.
도53은 실시예들에 따른 Location response header 의 Redirect URL 에 포함되는 정보를 나타낸다.
Host: 멀티캐스트 게이트웨이의 IP 주소 또는 FQDN 및 선택적으로 포트 번호(예: "router.example:8088" 또는 "192.0.2.1:8088")일 수 있다.
Session ID: 하나 이상의 URL 경로 요소를 포함하는 멀티캐스트 랑데뷰 서비스에 의해 전달되고 생성될 수 있는 고유한 프레젠테이션 세션 식별자이다.
ManifestPath: 지정된 호스트에서 프레젠테이션 매니페스트를 검색하기 위한 리소스 경로이다.
RequestedPriority : 콘텐츠 재생에서 요청된 우선 순위 값이다.
conf: 멀티캐스트 세션 매개변수는 하나의 멀티캐스트 세션을 포함하는 멀티캐스트 게이트웨이 구성 인스턴스 문서의 형식을 취할 수 있다..
문서는 URL 쿼리 문자열 매개변수로 포함되기 전에 Gzip 및 base64url 인코딩을 사용하여 압축될 수 있다.
RequestedPriority - Playback function 이 multicast rendezvous service 에 manifest를 요청할 때, 복수의 multicast gateway에 대한 priority가 설정 되어 있는 경우, redirection 전송시 요청시 전송되었던 priority를 되돌려 줄 수 있다. Multicast rendezvouse service 는 redirection 가능한 가장 상위 값의 priority를 가지는 multicast gateway로 redirection 해 줄수 있다.
이때, presentation manifest 가 multicast session configuration내의 multicast session 과 관련된 것이면 (service를 multicast로 전송 가능), Multicast rendezvous service는 다음과 같이 request를 Multicast gateway로 redirection 할 수 있다.
HTTP/1.1 307 Temporary Redirect
Server: <Multicast gateway>
Location: http[s]://<Multicast gateway>/<ManifestPath>[?<requestedPriority]*
HTTP header의 Location field 에 해당 하는 URL은 session identifier 와 요청된 presentation manifest 에 해당 하는 multicast session을 포함하는 multicast gateway configuration instance document를 piggybacking 하는 query parameter 를 포함할 수 있다.
다음은 실시예들에 따른 컨텐츠 프로바이더 및 서비스 프로바이더 동작을 설명한다.
실시예들에 따른 architecture는 실시예들에 따른 컨텐츠 프로바이더, 서비스 프로바이더, 네트워크, 디바이스 등을 포함할 수 있다. 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응할 수 있다. 실시예들에 따른 프로세서는 실시예들에 따른 동작을 수행할 수 있고, 동작에 관한 정보를 저장하는 메모리와 연결될 수 있다.
도54-55는 실시예들에 따른 멀티플 컨텐츠 프로바이더를 나타낸다.
실시예들에 따른 architecture는 복수의 content provider 로부터 생성된 content를 이용하여 service 되는 구조에 대해 도시한다. 실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다.
이때, service provider 는 복수의 network 를 이용해 수신기 device에 서비스를 제공할 수 있다. Service provider는 service list directory를 구성 할 수 있고, 각각의 content provider 에 구성되어 있는 content provider control function을 통해 service 될 content list를 획득할 수 있다. 수신된 content list는 service에 적합한 형태로 service list를 구성할 수 있으며, 해당 service list는 application에 제공된다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
Content provider server는 service provider에 구성되어 있는 multicast server로 content 를 제공한다 (ingest). 이때, ingest 되는 content 에 대한 정보는 각각의 content provider control function으로부터 service provider control function으로 전달 될 수 있다. Service provider control function 은 해당 정보를 이용해 multicast session configuration 정보로 구성하고 이를 multicast server 및 multicast gateway로 전달할 수 있다.
Device 내의 content playback function에는 각각의 network 에 대해 L interface 및 B interface 가 구성 될 수 있다. L1, L2, L3, L4 interface 를 통해 multicast gateway(A), multicast gateway (B), multicast gateway (C), multicast gateway (D) 를 통해 media streaming 을 수신할 수 있으며, B1, B2, B3, B4 interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (D) 와 multicast rendezvous service (D)는 device 내에 구성되어 있으므로, L4, B4 interface는 device 내부 interface 로 대체할 수 있다.
도56-57은 실시예들에 따른 멀티플 서비스 프로바이더를 나타낸다.
실시예들에 따른 architecture는 content provider 가 복수의 service provider를 통해 service 되는 구조에 대해 도시한다. 실시예들에 따른 architecture에서는 각각의 network 에 대해서, multicast server, multicast gateway, multicast rendezvous service 가 각각의 network에 접속되어 있는 content playback function에 service를 제공한다.
이때, 각각의 service provider 는 복수의 network 를 이용해 수신기 device에 서비스를 제공할 수 있다. Service provider는 각각 service list directory를 구성 할 수 있고, content provider의 content provider control function을 통해 service 될 content list를 획득할 수 있다. 수신된 content list는 service에 적합한 형태로 service list를 구성할 수 있으며, 해당 service list는 application에 제공된다.
Service discovery interface를 통해 application은 multicast service 의 list 및 해당하는 multicast rendezvous service 에 대한 접속 정보를 획득한다. Service discovery interface는 service provider 와 application 사이에서 별도로 정의된 방법을 따를 수 있다. 또한 각각의 network 는 service discovery interface에 대한 data 의 송수신을 지원 할 수 있다.
Content provider server는 service provider에 구성되어 있는 multicast server로 content 를 제공한다 (ingest). 이때, ingest 되는 content 에 대한 정보는 content provider control function으로부터 service provider control function으로 전달 될 수 있다. Service provider control function 은 해당 정보를 이용해 multicast session configuration 정보로 구성하고 이를 multicast server 및 multicast gateway로 전달할 수 있다.
Device 내의 content playback function에는 각각의 network 에 대해 L interface 및 B interface 가 구성 될 수 있다. L1, L2, L3, L4 interface 를 통해 multicast gateway(A), multicast gateway (B), multicast gateway (C), multicast gateway (D) 를 통해 media streaming 을 수신할 수 있으며, B1, B2, B3, B4 interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway (D) 와 multicast rendezvous service (D)는 device 내에 구성되어 있으므로, L4, B4 interface는 device 내부 interface 로 대체할 수 있다.
도58, 59, 60, 61, 62, 63은 실시예들에 따른 서비스 프로바이더 변경 흐름도를 나타낸다.
다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, service provider 가 변경된 이후에도 동일한 content 를 수신하는 과정에 대한 flow를 나타낸 것이다.
Content provider와 관련한 flow는 다음과 같이 진행될 수 있다.
Content provider control function은 content list를 service provider A와 service provider B의 service provider control function 에 전달한다.
Service provider control function content list를 service list 로 재구성하고, 연계된 각각의 application에 service list를 전송한다.
Multicast Server 와 관련한 flow 는 다음과 같이 진행된다. (각각의 service provider에 독립적으로 동작)
각각의 function이 architecture에 따라 deploy 되고 Multicast service 에 대한 configuration 이 multicast server, multicast gateway, multicast rendezvous service 에 적용된다.
Provisioning function은 network control을 통해 현재 provisioning 되어 있는 multicast session에 대한 configuration 정보를 multicast server에 전달한다.
Multicast session이 시작되면, content provider 로부터 multicast server에 media segment가 ingest 되고, multicast 전송을 시작하며, 해당 media segment를 수신할 수 있는 multicast gateway 가 있으면 수신 가능한 상태가 된다.
Device 가 service provider A 를 통해 service 를 수신 하면 다음과 같이 동작할 수 있다.
Application (A) 는 network A를 거쳐 service list directory (A) 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network A 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
Application (A)를 통해 사용자가 수신할 multicast contents를 선택하면, 해당 Application 에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(A) 또는 Multicast rendezvous service (A)를 가리킨다.
Application (A)는 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(A) 또는 Multicast rendezvous service(A) 에 대한 URL을 전달 할 수 있다.
Content playback function은 application (A)로부터 전달된 URL을 이용하여, reference point B1를 통해 Multicast rendezvous service(A)에 presentation manifest를 요청한다.
Multicast rendezvous service(A)는 동일 network에 구성되어 있는 Multicast gateway(A)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(A) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따라 reference point L1을 통해 Multicast gateway(A)에 presentation manifest를 요청한다.
Multicast gateway(A) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming 이 multicast server (A) 에서 multicast gateway(A) 로 M1 interface를 통해 전송된다.
Content playback function은 Multicast gateway(A)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
이 상태에서, device 가 service provider A 에서 Service provider B로 접속하고 이와 함께 network 역시 network (B)로 변경하게 되면 다음과 같이 동작할 수 있다.
Application (B) 는 network B를 거쳐 service list directory (B) 로부터 service list 를 수신 할 수 있다. Service list 를 수신 하기 위해서 network B 에서 정의 되어 있는 service list 획득 방법이 사용 될 수 있다. 예를 들어, DVB-I network 에서 service directory 가 구성되어 있으면, service provider, service directory, application 사이의 상호 동작을 통해 service list를 수신할 수 있다. ABR multicast 동작을 위해서, service list 에는 service ID 에 mapping 되는 presentation manifest를 요청할 url 이 포함 될 수 있다.
수신중에 있는 service 에 대해, Application (B)에서는 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 및 rendezvous service (B)를 가리킨다.
사용자가 수신할 multicast contents를 선택하면, 해당 Application에서 Service directory 등을 통해 최초 presentation manifest 를 요청할 URL을 획득할 수 있다. 이때 URL은 Multicast gateway(B) 또는 Multicast rendezvous service (B)를 가리킨다.
Application 은 content playback function이 content 수신을 위한 동작을 시작할 수 있도록 제어하며, 이때, Multicast gateway(B) 또는 Multicast rendezvous service(B) 에 대한 URL을 전달 할 수 있다.
Multicast gateway 와 multicast rendezvous service가 동일한 장치에 구성되어 있는 경우 (co-located deployment), 다음 과정은 선택적으로 수행될 수 있다.
Content playback function은 application (B) 로부터 전달된 URL을 이용하여, reference point B2를 통해 Multicast rendezvous service(B)에 presentation manifest를 요청한다.
Multicast rendezvous service(B)는 동일 network에 구성되어 있는 Multicast gateway(B)의 상태를 체크 하고, 요청된 presentation manifest 에 대한 service가 multicast configuration에 정의 되어 있으면, Multicast gateway(B) 에 대한 redirection URL을 content playback function에 전송한다. 이때 전송되는 redirection message에 업데이트 된 multicast session configuration을 포함시킬 수 있다.
Redirection message를 수신한 content playback function은 해당 redirection을 따른다.
획득된 URL을 이용하여, reference point L2을 통해 Multicast gateway(B)에 presentation manifest를 요청한다.
Multicast gateway(B) 에 미리 presentation manifest 가 cache 되어 있는 경우, 해당 presentation manifest 를 content playback function으로 전송한다.
Content playback function은 수신된 presentation manifest를 바탕으로 network (B)를 통해 해당 contents 에 대한 media segment 를 요청한다.
Multicast streaming이 multicast server 에서 multicast gateway(B) 로 M interface를 통해 전송된다.
Content playback function은 Multicast gateway(B)를 통해 요청한 media segment를 수신할 수 있으며 media가 play 된다. 별도의 control이 없는 경우 media 의 play가 지속된다.
실시예들에 따른 방법/장치는 다음과 같이 5G System Architecture와 연계될 수 있다.
The 5G System 은 다음과 같은 network functions (NF)으로 구성될 수 있다.
실시예들에 따른 약자는 다음과 같다: Authentication Server Function (AUSF), Core Access and Mobility Management Function (AMF), Data network (DN), e.g. operator services, Internet access or 3rd party services, Structured Data Storage network function (SDSF), Unstructured Data Storage network function (UDSF), Network Exposure Function (NEF), NF Repository Function (NRF), Policy Control function (PCF), Session Management Function (SMF), Unified Data Management (UDM), User plane Function (UPF), Application Function (AF), User Equipment (UE), (Radio) Access Network ((R)AN).
도64는 실시예들에 따른 5G 시스템 서비스 기반 구조를 나타낸다.
위의 그림은 5G system의 non-roaming case 에 대한 architecture를 service 기반의 interface로 나타낸 것이다. User plane data는 DN, UPF, (R)AN, UE을 거쳐 전달되며, 그외의 다른 function은 control plane data를 처리할 수 있다.
여기에서 각각의 service 기반 interface는 다음과 같다: Namf: Service-based interface exhibited by AMF. Nsmf: Service-based interface exhibited by SMF. Nnef: Service-based interface exhibited by NEF. Npcf: Service-based interface exhibited by PCF. Nudm: Service-based interface exhibited by UDM. Naf: Service-based interface exhibited by AF. Nnrf: Service-based interface exhibited by NRF. Nausf: Service-based interface exhibited by AUSF.
도65는 실시예들에 따른 레퍼런스 포인트 리프리젠테이션 내 5G 시스템 구조를 나타낸다.
다음 그림은 여러 network function이 어떻게 상호동작 하는지 나타내는 reference point를 이용하여 non-roaming case에 대한 5G system architecture를 나타낸 것이다.
User plane data는 DN, UPF, (R)AN, UE을 거쳐 전달되며, 그외의 다른 function은 control plane data를 처리할 수 있다. 따라서, 해당 function사이의 reference point인 N6, N3를 통해 data가 전달되며, (R)AN과 UE 사이는 무선으로 연결될 수 있다.
여기에서, reference point는 다음과 같이 정의 될 수 있다: N1: Reference point between the UE and the AMF. N2: Reference point between the (R)AN and the AMF. N3: Reference point between the (R)AN and the UPF. N4: Reference point between the SMF and the UPF. N5: Reference point between the PCF and an AF. N6: Reference point between the UPF and a Data Network. N7: Reference point between the SMF and the PCF. N7r: Reference point between the PCF in the visited network and the PCF in the home network. N8: Reference point between the UDM and the AMF. N9: Reference point between two Core UPFs. N10: Reference point between the UDM and the SMF. N11: Reference point between the AMF and the SMF. N12: Reference point between AMF and AUSF. N13: Reference point between the UDM and Authentication Server function the AUSF. N14: Reference point between two AMFs. N15: Reference point between the PCF and the AMF in case of non-roaming scenario, PCF in the visited network and AMF in case of roaming scenario. N16: Reference point between two SMFs, (in roaming case between SMF in the visited network and the SMF in the home network). N17: Reference point between AMF and EIR. N18: Reference point between any NF and UDSF. N19: Reference point between NEF and SDSF.
위에서 열거된 reference point는 별도의 protocol로 정의 되거나, 공통된 protocol상에서, 별도의 식별자를 가지는 message로 정의 될 수 있다. 이를 위해, control plane의 interface는 물리적으로는 다른 reference point와 공유될 수 있으며 각각의 protocol 또는 message set 등을 이용해 reference point를 식별 할 수 있다.
도66은 실시예들에 따른 멀티플 PDU 세션을 위한 5G 시스템 구조를 나타낸다.
도66은 앞서 기술한 5G system architecture를 기반으로, 두개의 DN을 지원 하기 위한 network 구조를 나타낸다. 하나의 DN이 접속되기 위해서는 해당 DN에 대한 UPF 및 SMF 가 별도로 구성될 수 있고, 이 function은 또한 각각 control plane function과 해당 reference point를 통해 연결될 수 있다. 따라서, 각각의 DN은 별도의 PDU session을 제공하게 되고 SMF가 해당 session을 제어할 수 있다.
도66에서는 동시에 두 개의 DN (Data Network) 에 접속 되는 것을 나타내고 있으나 network 구성에 따라 두개 이상의 DN과 접속될 수 있다.
도67은 실시예들에 따른 두 가지 데이터 네트워크들에 공존하는 접속을 위한 5G 시스템 구조를 나타낸다.
도67은 하나의 PDU 세션 옵션을 따를 수 있다.
도67은 두 개의 DN에 접속되어 있는 구조에서 단일 SMF를 이용하여 각각의 DN에서 제공하는 PDU session이 단일 session으로 동작할 수 있게 구성된 network architecture 이다.
이러한 network 구조에 대해, 하나의 PDU session에 대한 User Plane Protocol stack 은 도68과 같이 정의 될 수 있다.
도68은 실시예들에 따른 유저 플레인 프로토콜 스택을 나타낸다.
PDU layer: 이 계층은 PDU 세션을 통해 UE와 DN 간에 전달되는 PDU에 해당한다. PDU 세션 유형이 IPV6인 경우 IPv6 패킷에 해당한다. PDU 세션 유형이 이더넷인 경우 이더넷 프레임에 해당한다.
5G Encapsulation: 이 계층은 N3(즉, AN과 5GC 간) 또는 N9(즉, 5GC의 서로 다른 UPF 간)를 통해 서로 다른 PDU 세션(다른 PDU 세션 유형에 해당할 수 있음)의 다중화 트래픽을 지원한다. PDU 세션 수준에서 캡슐화를 제공한다. 이 계층은 QoS 흐름과 관련된 표시도 수행한다.
AN protocol stack: 이 프로토콜/계층 세트는 AN에 따라 다르다. AN이 3GPP RAN인 경우 이러한 프로토콜/계층은 3GPP RAN에 의해 정의된다.
데이터 경로에 있는 UPF의 수는 3GPP 사양에 의해 제한되지 않는다. 이 PDU 세션에 대한 PDU 세션 앵커 기능을 지원하지 않는 PDU 세션 0, 1 또는 다중 UPF의 데이터 경로에 있을 수 있다. IP의 경우 유형 PDU 세션에서 PDU 세션 앵커 역할을 하는 UPF는 UE에 할당된 IP 주소/접두사의 IP 앵커 포인트이다.
앞서 기술한 5G architecture에 대해서, 각각의 function에 대한 기능은 아래와 같다.
액세스 및 이동성 관리 기능(Access and Mobility Management function) (AMF)
The Access and Mobility Management function (AMF) 은 다음과 같은 기능을 포함할 수 있다. 단일 AMF instance 는 아래의 기능 전부 또는 일부를 지원할 수 있다: RAN CP 인터페이스 종료(N2), NAS(N1) 종료, NAS 암호화 및 무결성 보호, 등록 관리, 연결 관리, 접근성 관리, 모빌리티 관리, 적법한 가로채기(AMF 이벤트 및 LI 시스템에 대한 인터페이스용), UE와 SMF 간의 SM 메시지 전송을 제공한다. SM 메시지 라우팅을 위한 투명한 프록시, 액세스 인증, 액세스 권한 부여, UE와 SMSF 간의 SMS 메시지 전송을 제공한다. 보안 앵커 기능(SEA). AUSF 및 UE와 상호 작용하고 UE 인증 프로세스의 결과로 설정된 중간 키를 수신한다. USIM 기반 인증의 경우 AMF는 AUSF에서 보안 자료를 검색한다. 보안 컨텍스트 관리(SCM). SCM은 액세스 네트워크 특정 키를 파생하는 데 사용하는 SEA로부터 키를 받는다.
또한, AMF는 non-3GPP access network를 지원하기 위해 다음과 같은 기능을 포함 할 수 있다.
N3IWF와 N2 인터페이스 지원. 이 인터페이스를 통해 3GPP 액세스를 통해 정의된 일부 정보(예: 3GPP 셀 식별) 및 절차(예: 핸드오버 관련)가 적용되지 않을 수 있으며, 3GPP 액세스에는 적용되지 않는 비 3GPP 액세스 특정 정보가 적용될 수 있다.
N3IWF를 통한 UE와의 NAS 시그널링 지원. 3GPP 액세스를 통한 NAS 시그널링이 지원하는 일부 절차는 신뢰할 수 없는 비-3GPP(예: 페이징) 액세스에 적용되지 않을 수 있다.
N3IWF를 통해 연결된 UE의 인증 지원. 비 3GPP 액세스를 통해 연결되거나 3GPP 및 비 3GPP 액세스를 통해 동시에 연결된 UE의 이동성, 인증 및 별도의 보안 컨텍스트 상태 관리. 3GPP 및 비 3GPP 액세스에 대해 유효한 조정된 RM 관리 컨텍스트를 지원한다. 비 3GPP 액세스를 통한 연결을 위해 UE에 대한 전용 CM 관리 컨텍스트를 지원한다. 세션 관리 기능(SMF)
Session Management function (SMF) 은 다음과 같은 기능을 포함할 수 있다. 단일 SMF instance 는 아래의 기능 전부 또는 일부를 지원할 수 있다:
세션 관리. 예를 들어 UPF와 AN 노드 간의 터널 유지 관리를 포함하여 세션 설정, 수정 및 해제. UE IP 주소 할당 및 관리(선택적 권한 부여 포함). UP 기능 선택 및 제어. 트래픽을 적절한 대상으로 라우팅하도록 UPF에서 트래픽 조정을 구성한다. 정책 제어 기능에 대한 인터페이스 종료. 정책 시행 및 QoS의 일부를 제어한다. 적법한 가로채기(SM 이벤트 및 LI 시스템에 대한 인터페이스용). NAS 메시지의 SM 부분 종료. 다운링크 데이터 알림. AMF를 통해 N2를 통해 AN으로 전송되는 AN 특정 SM 정보의 개시자. 세션의 SSC 모드를 결정한다. 로밍 기능: QoS SLA(VPLMN)를 적용하기 위해 로컬 적용을 처리한다. 충전 데이터 수집 및 충전 인터페이스(VPLMN). 적법한 가로채기(SM 이벤트 및 LI 시스템에 대한 인터페이스를 위한 VPLMN에서). 외부 DN에 의한 PDU 세션 승인/인증을 위한 신호 전송을 위한 외부 DN과의 상호 작용 지원.
사용자 평면 기능(UPF)
User plane function (UPF) 은 다음과 같은 기능을 포함할 수 있다. 단일 UPF instance 는 아래의 기능 전부 또는 일부를 지원할 수 있다:
Intra-/Inter-RAT 이동성을 위한 앵커 포인트(해당되는 경우). 데이터 네트워크에 대한 상호 연결의 외부 PDU 세션 지점이다. 패킷 라우팅 및 전달. 정책 규칙 시행의 패킷 검사 및 사용자 평면 부분. 적법한 도청(UP 수집). 트래픽 사용량 보고. 데이터 네트워크로의 트래픽 흐름 라우팅을 지원하는 업링크 분류기. 멀티홈 PDU 세션을 지원하는 분기점. 사용자 평면에 대한 QoS 처리(예: 패킷 필터링, 게이팅, UL/DL 속도 시행). 업링크 트래픽 검증(SDF 대 QoS 흐름 매핑). 업링크 및 다운링크의 전송 수준 패킷 표시. 다운링크 패킷 버퍼링 및 다운링크 데이터 알림 트리거.
정책 기능(PCF)(Policy function) (PCF)
Policy function (PCF) 은 다음과 같은 기능을 포함할 수 있다.
네트워크 동작을 제어하는 통합 정책 프레임워크를 지원한다. 정책 규칙을 적용하기 위해 제어 평면 기능에 제공한다. UDR(사용자 데이터 저장소)의 정책 결정과 관련된 구독 정보에 액세스하기 위해 프런트 엔드를 구현한다.
네트워크 노출 기능(Network Exposure Function) (NEF)
Network Exposure Function (NEF) 은 다음과 같은 기능을 포함할 수 있다.
섹션 5.13에 설명된 대로 제3자, 내부 노출/재노출, 애플리케이션 기능, 에지 컴퓨팅을 위해 3GPP 네트워크 기능이 제공하는 서비스 및 기능을 안전하게 노출하는 수단을 제공한다.
네트워크 노출 기능은 다른 네트워크 기능에서 정보를 수신합니다(다른 네트워크 기능의 노출된 기능을 기반으로 함). 데이터 저장 네트워크 기능(3GPP에서 정의할 인터페이스)에 대한 표준화된 인터페이스를 사용하여 수신된 정보를 구조화된 데이터로 저장할 수 있다. 저장된 정보는 NEF에 의해 다른 네트워크 기능 및 애플리케이션 기능에 "재노출"될 수 있으며 분석과 같은 다른 목적으로 사용될 수 있다.
NF 저장소 기능(NF Repository Function) (NRF)
NF Repository Function (NRF) 은 다음과 같은 기능을 포함할 수 있다.
서비스 검색 기능을 지원합니다. NF 인스턴스로부터 NF Discovery Request를 수신하고, 발견된 NF 인스턴스(발견될)의 정보를 NF 인스턴스에 제공한다. 사용 가능한 NF 인스턴스 및 지원 서비스에 대한 정보를 유지 관리한다.
도59는 실시예들에 따른 Unified Data Management (UDM) 을 나타낸다.
Unified Data Management (UDM)는 application front end (FE) 와User Data Repository (UDR)로 나눌 수 있다.
도59는 UDM에 대한 reference architecture를 나타낸 것이며, 다음과 같은 front end 가 포함될 수 있다.
UDM FE: 자격 증명 처리, 위치 관리, 구독 관리 등을 담당한다.
PCF: 정책통제를 담당한다. PCF는 전체 5GC 아키텍처에서 독립 실행형 네트워크 기능이므로 UDM의 일부가 아니다. 그러나 PCF는 UDR에 정책 구독 정보를 요청하고 제공할 수 있으며 이러한 이유로 UDM 아키텍처에 표시된다.
UDR은 UDM-FE에서 제공하는 기능에 필요한 데이터와 PCF에 필요한 정책 프로필을 저장한다. UDR에 저장된 데이터에는 다음이 포함된다:
구독 식별자, 보안 자격 증명, 액세스 및 이동성 관련 구독 데이터 및 세션 관련 구독 데이터를 포함한 사용자 구독 데이터, 정책 데이터. UDM-FE는 UDR(사용자 데이터 저장소)에 저장된 구독 정보에 액세스하고 다음 기능을 지원한다.
인증 자격 증명 처리. 사용자 식별 처리. 액세스 권한 부여. 등록/이동성 관리. 구독 관리. SMS 관리. 프런트 엔드는 애플리케이션 로직을 구현하며 내부 사용자 데이터 저장소가 필요하지 않다. 여러 개의 서로 다른 프런트 엔드가 서로 다른 트랜잭션에서 동일한 사용자에게 서비스를 제공할 수 있다.
N25/Nudr 기준점/인터페이스는 프런트 엔드가 읽기, 업데이트(추가, 수정 포함), 삭제, 데이터 변경 알림 구독 및 UDR의 데이터 변경 알림을 위해 정의된다. N25는 P2P 기준점의 이름이고 Nudr은 서비스 기반 인터페이스의 이름이다. FE와 UDR은 모두 HPLMN에 있다.
인증 서버 기능(Authentication Server Function) (AUSF)
AUSF는 다음 기능을 지원한다. AUSF(인증 서버 기능)를 지원한다.
응용 기능(Application Function) (AF)
애플리케이션 기능(AF)은 서비스를 제공하기 위해 3GPP 코어 네트워크와 상호 작용한다. 예를 들어 다음을 지원한다. 트래픽 라우팅에 대한 애플리케이션 영향, 네트워크 기능 노출에 액세스, 정책 제어를 위한 정책 프레임워크와 상호 작용, 운영자 배치를 기반으로 운영자가 신뢰하는 것으로 간주되는 응용 프로그램 기능은 관련 네트워크 기능과 직접 상호 작용할 수 있다. 운영자가 네트워크 기능에 직접 액세스하도록 허용하지 않은 응용 프로그램 기능은 관련 네트워크 기능과 상호 작용하기 위해 NEF를 통해 외부 노출 프레임워크를 사용해야 한다.
도70은 실시예들에 따른 5G 미디어 스트리밍을 위한 구조를 나타낸다.
5G 시스템 내 5G 다운링크 미디어 스트리밍(5G Downlink Media Streaming within the 5G System)
도70은 5G network내에 downlink media streaming을 위한 function이 구성되어 있는 구조를 나타낸다.
도70 구조에서, 5G media streaming을 위해서, UE 에는 5GMSd Aware Application 과 5GMSd Client가 구성되며, DN (Data Network)에는 5GMSd AF 및 5GMSd AS 가 구성 될 수 있다. 여기에서, mobile network operator 가 운용하는 network 내에 DN 이 구성되어 있으면 Trusted DN 으로 고려 될 수 있으며, mobile network operator 밖에 DN이 구성되어 있으면, (예를 들어 3rd party CDN 등) External DN으로 고려 될 수 있다. 그 외 Function 및 interface 는 Annex A에 추가로 기술되어 있다.
도71은 실시예들에 따른 유니캐스트 다운링크 미디어 스트리밍을 위한 미디어 아키텍처(Media Architecture for unicast downlink media streaming)를 나타낸다.
전술한 network architecture에 대해서, unicast downlink media streaming 을 위한 Media Architecture 는 다음과 같이 정의 될 수 있다. 여기에서, 각각의 function 및 interface는 media streaming 관점의 logical interface를 정의 한 것이다.
각각의 function은 다음과 같이 정의 될 수 있다.
UE 상의 5GMSd 클라이언트(다운링크용 5G 미디어 스트리밍 클라이언트): 잘 정의된 인터페이스/API를 통해 액세스할 수 있는 5GMS 다운링크 미디어 스트리밍 서비스의 수신기. 대안적으로, UE는 인터페이스 M6d 및 M7d가 전혀 노출되지 않도록 자체 포함된 방식으로 구현될 수 있다.
5GMSd 클라이언트에는 두 가지 하위 기능이 있습니다.
미디어 세션 핸들러: 미디어 세션의 전달을 설정, 제어 및 지원하기 위해 5GMSd AF와 통신하는 UE의 기능이다. 미디어 세션 핸들러는 5GMSd-Aware 애플리케이션에서 사용할 수 있는 API를 노출할 수 있다.
미디어 플레이어: 미디어 콘텐츠를 스트리밍하기 위해 5GMSd AS와 통신하고 미디어 재생을 위해 5GMSd 인식 애플리케이션에, 미디어 세션 제어를 위해 미디어 세션 핸들러에 API를 제공할 수 있는 UE의 기능을 수행한다.
5GMSd 인식 애플리케이션: 5GMSd 클라이언트는 일반적으로 외부 미디어 애플리케이션에 의해 제어된다. 외부 애플리케이션 또는 콘텐츠 서비스 제공자 특정 로직을 구현하고 미디어 세션을 설정할 수 있는 앱이다. 5GMSd-Aware 애플리케이션은 5G 미디어 스트리밍 사양에 정의되어 있지 않지만, 이 기능은 5GMSd 인터페이스 및 API를 사용하여 5GMSd 클라이언트 및 네트워크 기능을 사용한다.
5GMSd AS: 5G 미디어 기능을 호스팅하는 애플리케이션 서버이다. 5GMSd AS의 다른 구현이 있을 수 있다(예: CDN(Content Delivery Network)).
5GMSd 애플리케이션 제공자: 외부 애플리케이션 또는 콘텐츠별 미디어 기능(예: 5GMSd를 사용하여 미디어를 5GMSd 인식 애플리케이션으로 스트리밍하는 미디어 생성, 인코딩 및 포맷)한다.
5GMSd AF: UE 상의 미디어 세션 핸들러 및/또는 5GMSd 애플리케이션 제공자에게 다양한 제어 기능을 제공하는 애플리케이션 기능을 수행한다. 다른 정책 또는 과금 기능(PCF) 처리에 대한 요청을 릴레이 또는 시작하거나 NEF를 통해 다른 네트워크 기능과 상호 작용할 수 있다.
5G Downlink Media Streaming 을 위한 각각의 interface 는 다음과 같이 정의 될 수 있다.
M1d(5GMSd 프로비저닝 API): 5G 미디어 스트리밍 시스템의 사용을 프로비저닝하고 피드백을 얻기 위해 5GMSd AF에 의해 노출되는 외부 API이다.
M2d(5GMSd Ingest API): 신뢰할 수 있는 DN의 5GMSd AS가 스트리밍 서비스용 콘텐츠를 호스팅하도록 선택될 때 사용되는 5GMSd AS에 의해 노출되는 선택적 외부 API이다.
M3d: (내부): 신뢰할 수 있는 DN 내의 5GMSd AS에서 호스팅되는 콘텐츠에 대한 정보를 교환하는 데 사용되는 내부 API이다.
M4d(미디어 스트리밍 API): 5GMSd AS가 미디어 콘텐츠를 스트리밍하기 위해 미디어 플레이어에 노출하는 API이다.
M5d(미디어 세션 처리 API): 미디어 세션 처리, 제어 및 지원을 위해 5GMSd AF에 의해 미디어 세션 핸들러에 노출되는 API이다. 여기에는 적절한 보안 메커니즘도 포함된다. 권한 부여 및 인증을 수행한다.
M6d(UE Media Session Handling APIs): 클라이언트 내부 통신을 위해 Media Session Handler에 의해 Media Player에 노출되고 5GMSd-Aware Application에 노출되어 5GMS 기능을 사용할 수 있도록 하는 API이다.
M7d(UE 미디어 플레이어 API): 미디어 플레이어를 사용하기 위해 미디어 플레이어가 5GMSd 인식 애플리케이션 및 미디어 세션 핸들러에 노출하는 API이다.
M8d: (응용 프로그램 API): 5GMSd 인식 응용 프로그램과 5GMSd 응용 프로그램 공급자 간의 정보 교환에 사용되는 응용 프로그램 인터페이스(예: 5GMSd 인식 응용 프로그램에 서비스 액세스 정보 제공). 이 API는 5G 시스템 외부에 있으며 5GMS에서 지정하지 않는다.
멀티캐스트 적응형 비트레이트 시스템 아키텍처(MULTICAST ADAPTIVE BITRATE SYSTEM ARCHITECTURE)
실시예들에 따른 방법/장치는 다음과 같이 MULTICAST ADAPTIVE BITRATE SYSTEM ARCHITECTURE와 연계될 수 있다.
도72는 실시예들에 따른 레퍼런스 구조를 나타낸다.
참조 포인트(REFERENCE POINTS):
도72의 reference architecture 에서, logical function 간의 관계는 reference point로 정의 할 수 있다. 실제 이러한 architecture가 실제로 사용되는 경우에는, 구체적인 interface 로 구현될 수 있으며 각각 특정 프로토콜을 사용하여 관련 function 사이에 필요한 정보를 교환 할 수 있다.
데이터 플레인 참조 포인트(DATA PLANE REFERENCE POINTS):
위의 architecture에서 content를 전송하기 위한 reference point는 다음과 같다.
L: 콘텐츠 재생 기능과 멀티캐스트 게이트웨이 간의 유니캐스트 HTTP(및 이후에는 HTTPS) 상호 작용을 수행한다. 이 인터페이스에는 지정된 모든 유형의 콘텐츠 가져오기가 포함된다.
멀티캐스트 게이트웨이와 콘텐츠 재생 기능이 셋톱박스와 같은 단일 종단 장치에 공존하는 경우 인터페이스 L은 로컬 API로 구현될 수 있다.
B: 콘텐츠 재생 기능과 멀티캐스트 랑데부 서비스 기능 간의 직접 부트스트랩 유니캐스트 HTTP(S) 상호작용을 담당한다. 선형 재생 세션 시작 시 프레젠테이션 매니페스트를 요청하는 데 사용된다.
A: 참조점 M을 통해 제공되지 않는 콘텐츠의 콘텐츠 호스팅 기능에서 HTTP(S) 획득한다.
콘텐츠 재생 기능에서 참조 지점 L의 범위를 벗어나 콘텐츠를 검색하는 데 사용된다.
콘텐츠 복구를 수행하기 위해 콘텐츠 호스팅 기능에서 콘텐츠를 검색하기 위해 유니캐스트 복구 서비스 기능이 일부 배포에서 사용한다.
U가 콘텐츠 복구를 수행할 수 없을 때 유니캐스트를 통해 콘텐츠 호스팅 기능에서 직접 콘텐츠를 검색하기 위해 멀티캐스트 게이트웨이에서도 사용된다.
M: 멀티캐스트 서버 기능에 의한 멀티캐스트 IP 콘텐츠 전송 및 멀티캐스트 게이트웨이 기능에 의한 수신 및 일부 배포에서는 유니캐스트 수리 서비스 기능에 의한 수신 등을 담당한다.
U: 멀티캐스트 게이트웨이의 유니캐스트 복구 클라이언트와 유니캐스트 복구 서비스 간의 유니캐스트 상호 작용을 담당한다. 이 인터페이스는 이러한 페이로드에 대한 요청 외에 콘텐츠 복구 기능에 사용되는 페이로드를 전달하는데 사용될 수 있다.
U': A를 통해 복구 콘텐츠를 가져오는 대신 유니캐스트 복구 서비스와 멀티캐스트 서버 간의 유니캐스트 상호 작용을 담당한다. 이 인터페이스는 이러한 페이로드에 대한 요청 외에 콘텐츠 복구 기능에 사용되는 페이로드를 운반하는 데 사용될 수 있다.
Pin: 콘텐츠 패키징 하위 기능에 의해 콘텐츠 호스팅 기능에 콘텐츠 게시를 하고, 이것은 푸시 인터페이스로 구현되거나 콘텐츠 패키징 기능에서 요청 시 콘텐츠를 가져올 수 있다.
Oin: 콘텐츠 호스팅 기능에서 멀티캐스트 서버 기능에 의한 콘텐츠 수집하고, 이것은 일반적으로 풀 인터페이스로 구현된다.
Pin': 콘텐츠 패키징 기능에서 직접 멀티캐스트 서버에 의한 콘텐츠 인제스트하고, 이것은 일반적으로 푸시 인터페이스로 구현된다.
제어 평면 기준점(CONTROL PLANE REFERENCE POINTS)
위의 architecture에서 control signaling 및 operational reporting 정보를 전송하기 위한 reference point는 다음과 같다.
CMS: 멀티캐스트 서버 기능 구성을 위한 제어 인터페이스.
CMR: 멀티캐스트 게이트웨이 기능 구성을 위한 제어 인터페이스.
CCP: 프로비저닝 기능 구성을 위한 제어 인터페이스.
RS: 서비스 보고 캡처 기능에 대한 멀티캐스트 게이트웨이 기능에 의한 서비스 보고.
RCP: 콘텐츠 제공자 메트릭 보고 캡처 기능에 대한 서비스 보고 캡처 하위 기능에 의한 서비스 보고.
RPM: 콘텐츠 재생 기능에 의해 콘텐츠 제공자 메트릭 보고 캡처 기능에 대한 재생 메트릭 보고.
도73은 실시예들에 따른 레퍼런스 구조를 나타낸다.
참조 아키텍처 다이어그램(REFERENCE ARCHITECTURE DIAGRAM):
도73은 reference architecture에 대한 구체적인 구조를 나타낸 것이다.
구조의 기능은 다음과 같다.
콘텐츠 준비(Content preparation)
콘텐츠 인코딩(Content encoding)
Content encoding function 은 bitrate 감소를 위해 source media stream 을 encoded media 로 변환 한다. 단일 source media stream 은 delivery 조건에 맞도록 복수의 서로 다른 encoded representation 으로 변환될 수 있다. Content playback function 이 delivery 조건에 따라 적응적으로 동작할 수 있도록, virtual segment boundary marker 가 encoded representation 에 포함될 수 있다.
Encoder의 출력은 encryption function 또는 packaging function 에 전달되기 적합하도록 포맷 된 cleartext stream 이 될 수 있다. 예를 들어, MPEG elementary stream, MPEG-2 TS, 또는 이와 유사한 목적을 가지는 intermediate format이 될 수 있다.
콘텐츠 암호화(Content encryption)
Content encryption function 은 cleartext stream 을 입력 받아 cipertext stream으로 암호화 한다. Encryption key 는 DRM licence management function으로 부터 획득될 수 있다.
콘텐츠 패키징(Content packaging)
Content packaging function은 하나 이상의 인코딩된 representation을 수집하고 원하는 packaging format에 따라 데이터를 구성한다. Dynamic adaptive streaming에서는 packager의 출력은 동일한 source media stream의 여러 representation에 걸쳐 정렬되어 있는 representation switching point 를 포함하는 packaged media segment의 시퀀스이다. Packaging format은 ISO Base Media File Format (MP4) 와 fragmented MPEG-2 TS 가 될 수 있다.
콘텐츠 호스팅(Content hosting)
Content hosting function은 다음과 같은 경우를 위해 prepared content를 사용가능하도록 준비할 수 있다.
Multicast server로 unicast delivery를 위해 - Oin을 통한 content ingest에 해당함.
Multicast gateway로 A 인터페이스를 통한 unicast repair service를 위해 - A 인터페이스를 통한 cash miss의 경우
Multicast receiver를 통해 연결되지 않은 content playback function을 위해 - B 인터페이스를 통한 전송
Content hosting function은 간단한 웹서버, origin cluster의 일부로 구현되거나, 분산 CDN 등으로 동작할 수 있다. 따라서, load balancing 및 request 분산 기술 (DNS round-robin, HTTP 302 redirect) 등을 사용하여 client를 적합한 content server로부터 content를 수신 할 수 있게 한다.
멀티캐스트 서버(Multicast server)
Multicast server는 content source로 부터 content를 수집한다. 즉, media stream이 Oin 인터페이스로 입력되는데, 일반적으로 media player에 탑재 되는 프로토콜이 사용될 수 있다. Multicast server에서는 수집된 media stream의 payload는 multicast transport protocol 의 delivery 단위로 encapsulation 되어 network를 통해 전송된다. 또한, M 인터페이스를 통해 IP multicast를 이용하여, 가입된 Multicast gateway client로 전송 된다. Network control function로 부터 CMS 인터페이스를 통해 구성정보를 수신 하여 구성될 수 있다.
콘텐츠 수집(Content ingest)
Multicast server에 서는 push 및 pull ingest 방법이 가능하다.
HTTP(S) Pull Ingest via interface Oin:
기존의 adaptive streaming media player 와 유사하며, presentation manifest에 기술된 사항을 바탕으로 packaged media segment를 content hosting function으로 부터 다운로드 한다. 이 경우, 인터페이스 Oin은 세부 operation 특성은 다를 수 있지만, 기능적으로 인터페이스 L 과 동일할 수 있다. Segment는 MPEG-DASH 또는 HLS로 package 될 수 있으며, presentation manifest에서 기술하는 하나 이상의 representation으로 부터 segment가 동시에 다운로드 될 수 있다. DVB-DASH, MPEG-DASH, HLS 등의 manifest format을 지원할 수 있다.
HTTP(S) Push Ingest via interface Pin′
WebDAV (Web Distributed Authoring and Versioning) 와 같은 HTTP(S) push 인터페이스를 제공할 수 있다. Content packaging subfunction은 media segment가 생성되는 즉시 content ingest function에 업로드 한다. Segment는 MPEG-DAH 또는 HLS와 같은 포맷으로 package 될 수 있다.
RTP Push Ingest via interface Pin′
RTP 기반 push ingest 메카니즘을 content packaging subfucntion 에 제공한다. Packager는 MPEG-2 TS 패킷을 RTP로 보낸다. Segment의 boundary는 virtual segment boundary marker를 이용해 표시 될 수 있다.
멀티캐스트 전송(Multicast transmission)
Content ingest subfunction에 의해 수신된 stream을 M 인터페이스를 통해 IP multicast packet의 payload로 전송한다.
유니캐스트 수리 서비스(Unicast repair service)
Unicast repair service는 U 레퍼런스 포인트를 통해 multicast gateway내부의 unicast repair client 로 payload repair function을 제공한다. 다음과 같은 repair mode를 고려할 수 있다.
Unicast repair service는 reference point M을 통해 전송되는 multicast content 를 수신 하며, Unicast repair client의 복구 요청을 충족시키기 위해 packet stream의 복사본을 로컬로 캐시 한다.
요청된 packet이 Unicast repair service의 cache로부터 만족되지 못하면, packet repair 요청은 U' 인터페이스를 통해 multicast server로 전달될 수 있다.
unicast repair service는 레퍼런스 포인트 A와 동일한 인터페이스를 이용해 packet repair 요청을 content hosting function에 대한 HTTP request로 변환될 수 있다.
여러 Multicast gateway로부터 동일한 repair 요청이 수신되는 경우 레퍼런스 포인트 M을 통해 repair packet 을 전송하는 것이 효율적일 수 있다.
멀티캐스트 게이트웨이(Multicast gateway)
Multicast Gateway의 주요한 목적은 패키징된 content segment를 Content Playback function에 전달하는 것이다. Multicast Gateway는 forward proxy 또는 reverse proxy를 포함하는 local origin으로 구현 될 수 있다. Multicast Gatewa는 홈 게이트웨이 장치 또는 IP 연결 set-top box (STB)와 같은 사용자의 구내 장비로 구체화 될 수 있다. 또한 사용자 구내 장비 대신 upstream network node에 위치 할 수 있다.
Content Playback function의 하나 이상의 instance로 부터 L인터페이스를 통해 content 요청이 수신되고, 요청되는 content 는 Asset storage subfunction에 cache 되어 있는 content가 직접 서비스 되거나, A 인터페이스를 통해 획득된 content가 간접적으로 서비스 된다. 이때 A 인터페이스를 통해 획득된 content는 선택적으로 Asset storage subfunction에 캐시 될 수 있다.
서비스 관리(Service management)
Service management subfunction은 M 인터페이스를 통해 수신 가능한 multicast content stream에 대한 서비스 구성 정보 및 Service reporting capture function의 위치 정보를 수집할 수 있다. 이러한 정보는 다음과 같이 수신 할 수 있다.
Network control function 으로 부터 CMR 인터페이스를 통해 직접 수신
Multicast reception subfunction 으로 부터 간접적으로 수신 (해당 정보가 M 인터페이스를 통해 전송된 경우)
Content hosting function 으로 부터 A 인터페이스를 통해 전달된 unicast response를 통해 수신
멀티캐스트 수신(Multicast reception)
Multicast reception subfunction은 M 인터페이스를 통해 end device 에서 요청 되었거나, end device를 위해 구성된 content stream을 전달받는다. 오류없이 정상적으로 수신 된 content는 추후 해당 content를 사용 할 수 있도록, Asset storage 내에 캐시 될 수 있다. 전송 도중 손상된 content는 Multicast gateway가 캐시 하기 전에 특정한 기법 (e.g. Forward Error Correction, unicast repair by the Unicast repair client via U or unicast retrieval via A) 을 사용하여 복구 될 수 있다. 복구되지 않은 content는 L 인터페이스를 통해 전달되지 않는다.
유니캐스트 복구 클라이언트(Unicast repair client)
Multicast packet loss 감지가 수행되고, M 인터페이스를 통해 수신된 Forward Error Correction 정보를 이용하거나, U 인터페이스를 통한 Unicast repair service (e.g. unicast packet retransmission or multicast segment loss signaling)를 이용하여 복구된다. 이러한 방법으로 복구되지 않은 packet의 경우 인터페이스 A를 통한 unicast 전송을 이용할 수 있다.
자산 저장(Asset storage)
Asset storage subfunction은 L 인터페이스를 통해 제공될 정보를 일시적으로 저장하는 기능을 제공한다. 저장 기능은 multicast gateway에 의해서만 수행된다.
Managed pre-positioned media content assets. 예를 들어, 다수의 user에 인기있는 content나 광고관련 정보의 전부 또는 일부를 실제 사용 되기 전 미리 저장할 수 있음.
Linear media content segment에 대한 임시 cache
서비스 보고(Service reporting)
Service-related metrics (e.g. telemetry and analytics data)은 Service reporting subfunction 에 의해 RS인터페이스를 통해 Service reporting capture subfunction에 report됨.
프로비저닝(Provisioning)
Provisioning function 의 목적은 다음과 같다
배포된 멀티캐스트 게이트웨이 인스턴스에서 중앙 집중식으로 서비스 보고 정보를 수집한다. 네트워크에서 리소스를 구성한다. 구성된 네트워크 리소스를 사용하도록 멀티캐스트 서버를 구성한다. 구성된 네트워크 리소스를 사용하도록 멀티캐스트 게이트웨이를 구성한다.
The Provisioning function 은 CCP 인터페이스를 통해 전달되는 정보를 바탕으로 Content Provider control function 와 연동될 수 있다.
서비스 보고 캡처(Service reporting capture)
Multicast gateway에서 수집된 Service reporting정보는 RS인터페이스를 통해 Service reporting capture function 에 제공될 수 있다. Report에는 metric과 서비스의 성능을 알려 주는 주요 indicator (e.g. cache hit-ratio, viewership)등이 포함될 수 있다. Metric은 어떤 channel 이 요청되었는지, 언제 channel이 설정되었는지, 얼마나 많은 segment가 캐시 되었는지에 따라 달라질 수 있다. Service reporting 정보는 서비스 성능 향상이나 multicast channel을 구성하는데 사용 될 수 있다.
Service reporting capture function은 RCP 인터페이스를 통해 Content Provider metrics reporting capture function으로 service reporting정보를 내보낼 수 있다. Multicast content와 bitrate 등의 정보가 해당 reporting 정보에 포함될 수 있다.
네트워크 제어(Network control)
Network control function은 network resource에 대한 제어, 구성, 할당 등의 기능을 수행할 수 있다. 여기에서는 M 인터페이스에서의 multicast 전송 및 U, A 인터페이스에서의 unicast operation에 대한 resource를 포함할 수 있다.
중앙집중식 시스템에서, Network control function은 전송 가능한 multicast stream 에 대한 configuration 정보를 Network 자원에 배포할 수 있으며, 추가로 이러한 configuration정보를 CMS 인터페이스를 통해 Multicast server로 보내거나 CMR 인터페이스를 통해 Multicast gateway로 보낼 수 있다. 전송 가능한 multicast stream 에 대한 configuration 정보는 Content Provider의 제어 정책 또는 client의 요청의 수에 따라 update 될 수 있다.
콘텐츠 제공자 제어(Content Provider control)
Content Provider control function은 CCP 인터페이스를 통해 Network control function이 multicast delivery path M을 통해 가능한 서비스에 대한 정보를 제공할 수 있도록 한다. 단일 Content Provider control function은 서로 다른 network provider가 운영하고 있는 복수의 Network Control function과 상호 동작할 수 있다.
콘텐츠 재생(Content playback)
Content playback function은 content의 요청, 수신, decryption, presentation 등을 관리하는 function이다. 인터페이스 L을 통해 unicast 전송만 지원 한다. Playback은 content가 전달되는 전송 경로와 무관하게 동작한다.
Content playback function은 스마트폰과 같은 end device에서 Multicast gateway 와 별도로 위치할 수 있다. 또는 set-top box나 connected TV 등에서 Multicast gateway와 결합될 수 있다.
Content playback function의 추가 기능은 다음과 같다.
인터페이스 B를 통해 linear service에 대한 presentation manifest를 검색
인터페이스 B를 통해 Multicast gateway를 통해 검색되지 않는 모든 contents에 대한 검색
콘텐츠 언패킹(Content unpackaging)
Content unpackaging subfunction은 획득된 transport object로 부터 elementary stream 데이터를 추출 하여 이를 Content decryption 및 Content decoding subfunction에 제공 할 수 있다. 예를 들어 ISO Base Media File Format 세그먼트의 경우 적절한 media data box를 추출하며, MPEG-2 TS의 경우 원하는 PID가 필터링 되고 재조합 된 PES 패킷의 페이로드가 추출된다.
콘텐츠 복호화(Content decryption)
만약 DRM (Digital Rights Management) 시스템이 동작중인 경우, Content decryption subfunction 은 적합한 DRM licence management function 으로 부터 decryption key를 얻고 encrypted elementary stream을 decryption한다.
콘텐츠 디코딩(Content decoding)
Content decoding subfunction은 elementary media stream의 contents를 읽고 해석하여 screen이나 loudspeaker에서의 재생을 위한 rendering이 가능하도록 한다.
재생 측정항목 보고(Playback metrics reporting)
Playback metrics reporting subfunction은 RPM 인터페이스를 통해 Content Provider metrics reporting capture function에 content playback 의 작동 및 품질과 관련한 정보등을 보고할 수 있다. Metric에는 HTTP request/response, 초기 재생 delay, 버퍼 레벨, presentation switching 이벤트, network throughput 등이 포함될 수 있다. 보고되는 playback metric은 end user의 QoE에 직접적으로 관련 있으며, Content Provider나 Network에서 품질을 최적화 하는데 사용 될 수 있다.
멀티캐스트 랑데부 서비스(Multicast rendezvous service)
Multicast rendezvous service는 복수의 Multicast gateway instance 에 대한 data 레코드를 관리한다 (현재 multicast gateway의 상태, multicast session의 상태 및 관련 data 등). Network control function은 이러한 관련 정보를 Multicast rendezvous service에 제공할 수 있다.
Multicast rendezvous service는 Content playback function 으로 부터 reference point B를 통해 오는 presentation manifest에 대한 초기 요청을 처리한다. Multicast rendezvous service는 요청된 presentation manifest 에 해당하는 linear service에 대한 active multicast session 이 있는지 결정한다. 또한, 해당 요청에 대해 Content playback function 의해 사용될 적합한 active Multicast gateway 가 있는지 결정한다.
만약 두번째 조건이 만족하면, Multicast rendezvous service는 해당 요청을 Multicast gateway에 redirection 할 수 있다. 그렇지 않으면, Multicast rendezvous service는 해당 요청을 Content hosting function으로 redirection 하게 되며, 이때, 해당 session은 unicast 로 동작하게 된다.
DRM 라이선스 관리(DRM licence management)
DRM licence management function 은 core content 보호를 위해, Content encryption function 에 의해 사용되는 적절한 encryption key를 제공하고, Content playback function 이 보호된 content를 decryption할 수 있도록 Content decryption subfunction 에 licence를 공급한다.
애플리케이션(Application)
Application은 Content playback function을 제어한다. 예를 들어, TV 나 set-top box 의 내장 control application (EPG application)또는 Content Provider가 제공하는 third-party application 이 될 수 있다. Application이 Content playback을 제어하는데 사용하는 인터페이스는 일반적으로 개별 linear service의 playback을 개시하기 위한 presentation manifest (e.g. MPEG DASH MPD의 URL) 의 참조점을 전달하는 것이 포함된다. Application은 존재하는 linear service를 발견하고 Multicast gateway에 의한 수신을 제어하기 위해 Multicast gateway의 Service management subfunction과 상호 동작할 수 있다. Application은 application-specific Service directory function과 개별적인 상호 동작을 통해 linear service의 존재를 발견 할 수도 있다.
서비스 디렉토리(Service directory)
Application은 사용 가능한 linear service를 찾기 위해 private service directory를 사용 할 수 있다. Service directory function은 Content provider control function에 의해 구성될 수 있다.
도74는 실시예들에 따른 멀티캐스트 게이트웨이 배포 모델을 나타낸다.
앞서 기술한 Multicast ABR architecture에서 Multicast gateway 의 기능은 network 내에서 다양한 node에 구현될 수 있다. 도74는 네트워크 에지 장치에 배포된 멀티캐스트 게이트웨이를 도시한다.
Multicast gateway가 network edge device 내에 구현 되는 경우, terminal device는 home network 로 부터 IP multicast 수신을 지원하지 않는다. Terminal device 에는 Content playback function이 포함되고, linear playback을 제어하는 Application이 설치 된다.
Multicast gateway 는 복수의 Home gateway device에 multicast-to-unicast conversion 기능을 제공한다. 따라서 network edge device 와 home gateway device 사이의 access network 에서의 traffic은 unicast가 된다.
도75는 실시예들에 따른 홈 게이트웨이 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
Multicast gateway는 ISP (Internet Service Provider)에 의해 주로 공급되는 router와 같은 home gateway device 내에 구현된다. 또한, Multicast gateway는 동일 home network 내 복수의 terminal device에 multicast-to-unicast conversion 기능을 제공한다. 이러한 terminal device는 각각 Content playback function 의 instance를 가지며, 이와 관련한 Application이 설치되어 있다.
도76은 실시예들에 따른 단말 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
Multicast gateway가 terminal device 내에 구현 되는 경우, terminal device는 home network 내에서 IP multicast 수신을 지원 한다. 각각의 terminal device는 Multicast gateway와 Content playback function 둘 다 포함하고, linear playback 을 제어하기 위한 Application이 설치 된다. 이러한 구현 모델에 대해서, Multicast gateway function은 해당 host terminal device에만 content service를 제공하여야 한다.
Home gateway device는 multicast group 가입과 관련 동작만 수행할 수 있다. 이러한 동작은 home network가 완전한 multicast delivery를 지원하지 않을 때, 예측 불가능한 품질 변화가 일어날 수 있다.
도77은 실시예들에 따른 하이브리드 방송 수신 장치를 나타낸다.
실시예들에 따른 수신 장치는 도77과 같이 표현될 수 있다. 실시예들에 따른 수신 장치의 각 구성요소는 하드웨어, 소프트웨어, 프로세서 및/또는 그것들의 조합에 대응할 수 있다.
각 약어의 정의는 다음과 같다: 5GC: 5G Core Network, 5GMS: 5G Media Streaming, 5GMSd: 5G Media Streaming downlink, 5GMSu: 5G Media Streaming uplink, 5GS: 5G Systems, AF: Application Function, ABR: Adaptive Bit Rate, AMF: Access and Mobility Function, API: Application Programming Interface, App: Application, AS: Application Server, CAPIF: Common API Framework, CDN: Content Delivery Network, DASH: Dynamic and Adaptive Streaming over HTTP, DN: Data Network, DNAI: Data Network Application Identifier, DNN: Data Network Name, DRM: Digital Rights Management, EPC: Evolved Packet Core, EPS: Evolved Packet System, EUTRAN: Evolved Universal Terrestrial Radio Access Network, FLUS: Framework for Live Uplink Streaming, FQDN: Fully-Qualified Domain Name, GPU: Graphics Processing Unit, GSM: Global System for Mobile communication, HPLMN: Home Public Land Mobile Network, HTTP: HyperText Transfer Protocol, HTTPS: HyperText Transfer Protocol Secure, LTE: Long-Term Evolution, MBMS: Multimedia Broadcast Multicast System, MNO: Mobile Network Operator, MPD: Media Presentation Description, MSISDN: Mobile Station International Subscriber Directory Number, NA: Network Assistance, NEF: Network Exposure Function, NR: New Radio, NSMF: Network Slice Management Function, NSSAI: Network Slice Selection Assistance Information, NSSP: Network Slice Selection Policy, OAM: Operations, Administration and Maintenance, OTT: Over-The-Top, PCC: Policy and Charging Control, PCF: Policy and Charging Function, PDU: Packet Data Unit, PSS: Packet-switched Streaming Service, RAN: Radio Access Network, SBA: Service based Architecture, SLA: Service Level Agreement, TCP: Transmission Control Protocol, URL: Unique Resource Identifier, URSP: UE Route Selection Policy, AAC: Advanced Audio Coding, ABR: Adaptive Bit Rate, API: Application Programmer's Interface, BMFF: Base Media File Format, CDN: Content Delivery(Distribution) Networ, CMAF: Common Media Application Format, CP: Content Provider, DASH: Dynamic Adaptive Streaming over HTTP, DNS: Domain Name System, DRM: Digital Rights Management, EPG: Electronic Programme Guide, IGMP: Internet Group Management Protocol. IP: Internet Protocol, ISO: International Organization for Standardization, HLS: HTTP Live Streaming, HTTP: HyperText Transfer Protocol, HTTPS: Secure HyperText Transfer Protocol, MBMS: Multimedia Broadcast Multicast Services (pertaining to 3GPP), MPD Media Presentation Description (pertaining to MPEG-DASH), MPEG: Moving Pictures Experts Group, OTT: Over The Top, PID: Packet Identifier (pertaining to MPEG-2 Transport Stream), RTCP: RTP Control Protocol, RTP: Real-time Transport Protocol, STB: Set-Top Box , TCP: Transmission Control Protocol, UDP: User Datagram Protocol, URL: Uniform Resource Locator (pertaining to HTTP).
도78은 실시예들에 따른 멀티캐스트 신호 처리 방법을 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 장치(컨텐트 플레이백부, 어플리케이션부, 단말 디바이스 등)은 다음과 같이 멀티캐스트 신호를 수신하고 멀티캐스트 미디어 데이터를 디코딩할 수 있다.
S7800, 실시예들에 따른 멀티캐스트 신호 처리 방법은 멀티캐스트 방식에 기반하여 미디어를 수신하는 단계를 포함할 수 있다.
실시예들에 따른 미디어 수신 동작은 도1-6, 도9-16, 도40-43, 도44-49, 도54-57, 도64-67 등의 동작을 포함할 수 있다.
S7801, 실시예들에 따른 멀티캐스트 신호 처리 방법은 미디어에 대한 시그널링 정보를 수신하는 단계를 더 포함할 수 있다.
실시예들에 따른 시그널링 정보 수신 동작은 도6-8, 도17-19, 도50-53, 도58-63 등의 동작을 포함할 수 있다.
S7802, 실시예들에 따른 멀티캐스트 신호 처리 방법은 미디어를 디코딩하는 단계를 더 포함할 수 있다.
실시예들에 따른 미디어 디코딩 동작은 도1-6, 도9-16, 도40-43, 도44-49, 도54-57, 도64-67 등의 동작을 포함할 수 있다.
도79는 실시예들에 따른 멀티캐스트 신호 처리 방법을 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 장치(컨텐트 프로바이더, 멀티캐스트 서버, 멀티캐스트 케이스웨이, 네트워크 제어부, 멀티캐스트 랑레부 서비스 제어부 등)은 다음과 같이 멀티캐스트 신호를 생성하고 전송할 수 있다.
S7900, 실시예들에 따른 따른 멀티캐스트 신호 처리 방법은 미디어에 대한 시그널링 정보를 생성하는 단계를 포함할 수 있다.
실시예들에 따른 시그널링 정보 생성 동작은 도5-76-8, 도14-3617-19, 도45-4850-53, 도51-5358-63 등의 동작을 포함할 수 있다.
S7901, 실시예들에 따른 따른 멀티캐스트 신호 처리 방법은 미디어 및 시그널링 정보를 멀티개스트 방식에 기반하여 전송하는 단계를 더 포함할 수 있다.
실시예들에 따른 미디어 및 시그널링 정보 전송 동작은 도1-6, 도9-16, 도40-43, 도44-49, 도54-57, 도64-67 등의 동작을 포함할 수 있다.
도1을 참조하면, 실시예들에 따른 멀티캐스트 신호 처리 장치는 메모리; 및 메모리에 연결된 프로세서; 를 포함하고, 프로세서는, 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 미디어 데이터를 수신하고, 멀티캐스트 미디어 데이터를 디코딩할 수 있다.
도10를 참조하면, 실시예들은 복수 네트워크 상 멀티캐스트를 제공할 수 있다. 제1네트워크 및 제2네트워크는 서로 다르고, 제1네트워크 또는 제2네트워크 중 적어도 하나는 통신 네트워크, 방송 네트워크, 양방향 네트워크, 또는 단방향 네트워크를 포함할 수 있다.
도17-19를 참조하면, 실시예들은 네트워크 변경, 랑데부, 리다이렉션, 미디어 수신 흐름도를 포함한다. 멀티캐새트 미디어 데이터는 제1네트워크를 통해 수신되고, 제1네트워크에서 제2네트워크로 변경되는 경우에 대응하여, 프로세서는, 제2네트워크를 통해 서비스 리스트 정보를 수신하고, 서비스 리스트 정보에 기반하여 멀티캐스트 랑데부 서비스 정보를 획득하고, 랑데부 서비스 정보에 기반하여, 프리젠테이션 마니페스트 정보를 수신하고, 프리젠테이션 마니페스트 정보에 기반하여, 리다이렉션 정보를 수신하고, 리다이렉션 정보에 기반하여, 프리젠테이션 마니페스트 정보를 수신하여, 멀티캐스트 미디어 데이터를 수신할 수 있다.
도17-19를 참조하면, 실시예들은 복수의 네트워크들의 흐름도를 포함하고, 도45를 참조하면, 실시예들은 서비스 리스트를 포함한다. 프로세서는, 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여, 서비스 리스트 정보를 수신하고, 제1네트워크를 위한 서비스 리스트 정보는 멀티캐스트 미디어 데이터를 위한 마니페스트 정보에 대한 주소 정보를 포함하고, 제2네트워크를 위한 서비스 리스트 정보는 멀티캐스트 미디어 데이터를 위한 마니페스트 정보에 대한 주소 정보를 포함하고, 제1네트워크를 위한 서비스 리스트 정보 및 제2네트워크를 위한 서비스 리스트 정보는 멀티캐스트 미디어 데이터를 위한 식별자 및 멀티캐스트 랑데부를 위한 주소 정보를 포함할 수 있다.
도49를 참조하면, 실시예들은 복수의 network를 위한 service list 및 presentation manifest (ex. MPD)를 포함한다. 프로세서는, 멀티캐스트 미디어 데이터에 대해 제1네트워크 및 제2네트워크 각각에 대한 프리젠테이션 마니페스트 정보를 관리할 수 있다.
도50를 참조하면, 실시예들은 서비스 리스트를 포함한다. 프로세서는 멀티캐스트 미디어 데이터를 위한 서비스 리스트 정보를 수신하고, 서비스 리스트 정보는 프리젠테이션 마니페스트 요청 정보를 포함하고, 프리젠테이션 마니페스트 요청 정보는 멀티캐스트 랑데부 서비스를 위한 네트워크의 타입 정보, 멀티캐스트 랑데부 서비스를 위한 호스트 주소 정보, 멀티캐스트 랑레부 서비스의 타입 정보를 포함할 수 있다.
도51를 참조하면, 실시예들은 멀티캐스트 세션을 지원한다. 프로세서는, 멀티캐스트 미디어 데이터를 위한 멀티캐스트 세션 정보를 수신하고, 멀티캐스트 세션 정보는 멀티캐스트 세션이 전송되는 네트워크에 대한 식별 정보를 포함할 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 방법은 프로세서에 의해 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 미디어 데이터를 수신하는 단계; 및 멀티캐스트 미디어 데이터를 디코딩하는 단계; 를 포함할 수 있다.
멀티캐스트 신호를 수신하는 방법은 멀티캐스트 신호를 전송하는 과정의 역과정을 포함할 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 장치는 신호 처리 방법을 수행할 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 방법은 멀티캐스트 미디어 데이터를 생성하는 단계; 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 생성하는 단계; 멀티캐스트 미디어 데이터를 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 방식으로 전송하는 단계; 및 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 전송하는 단계; 를 포함할 수 있다.
실시예들에 따른 멀티캐스트 신호 처리 장치는 메모리; 및 메모리에 연결된 프로세서; 를 포함하고, 프로세서는, 멀티캐스트 미디어 데이터를 생성하고, 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 생성하고, 멀티캐스트 미디어 데이터를 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 방식으로 전송하고, 및 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 전송할 수 있다.
상술한 실시예들에 따른 장치는 실시예들에 따른 동작/구성 및/또는 시그널링 정보에 기초하여, 방송 및 multicast 전송에 있어서 다양한 network 를 효율적으로 활용할 수 있는 효과가 있다.
나아가, 상술한 실시예들에 따른 방법/장치는 다양한 네트워크 및/또는 디바이스와 연계하여, 다양한 스트리밍 세션에서 네트워크의 부하를 감소시키고, 구현 비용을 감소시키고, ABR Multicast service를 효율적으로 제공할 수 있는 효과가 있다. 이러한 효과를 제공하기 위해서, 실시예들에 따른 architecture 및 flow가 요구된다.
실시예들은 방법 및/또는 장치 관점에서 설명되었으며, 방법의 설명 및 장치의 설명은 상호 보완하여 적용될 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 실시예들의 권리범위에 속한다. 실시예들에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다. 실시예들의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 실시예들은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 실시예들의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 실시예들의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
실시예들의 장치의 다양한 구성요소들은 하드웨어, 소프트웨어, 펌웨어 또는 그것들의 조합에 의해 수행될 수 있다. 실시예들의 다양한 구성요소들은 하나의 칩, 예를 들면 하나의 하드웨어 서킷으로 구현될 수 있다 실시예들에 따라, 실시예들에 따른 구성요소들은 각각 별도의 칩들로 구현될 수 있다. 실시예들에 따라, 실시예들에 따른 장치의 구성요소들 중 적어도 하나 이상은 하나 또는 그 이상의 프로그램들을 실행 할 수 있는 하나 또는 그 이상의 프로세서들로 구성될 수 있으며, 하나 또는 그 이상의 프로그램들은 실시예들에 따른 동작/방법들 중 어느 하나 또는 그 이상의 동작/방법들을 수행시키거나, 수행시키기 위한 인스트럭션들을 포함할 수 있다. 실시예들에 따른 장치의 방법/동작들을 수행하기 위한 실행 가능한 인스트럭션들은 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적이지 않은 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있거나, 하나 또는 그 이상의 프로세서들에 의해 실행되기 위해 구성된 일시적인 CRM 또는 다른 컴퓨터 프로그램 제품들에 저장될 수 있다. 또한 실시예들에 따른 메모리는 휘발성 메모리(예를 들면 RAM 등)뿐 만 아니라 비휘발성 메모리, 플래쉬 메모리, PROM등을 전부 포함하는 개념으로 사용될 수 있다. 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함될 수 있다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
이 문서에서 “/”와 “,”는 “및/또는”으로 해석된다. 예를 들어, “A/B”는 “A 및/또는 B”로 해석되고, “A, B”는 “A 및/또는 B”로 해석된다. 추가적으로, “A/B/C”는 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 또한, “A, B, C”도 “A, B 및/또는 C 중 적어도 하나”를 의미한다. 추가적으로, 이 문서에서 “또는”는 “및/또는”으로 해석된다. 예를 들어, “A 또는 B”은, 1) “A” 만을 의미하고, 2) “B” 만을 의미하거나, 3) “A 및 B”를 의미할 수 있다. 달리 표현하면, 본 문서의 “또는”은 “추가적으로 또는 대체적으로(additionally or alternatively)”를 의미할 수 있다.
제1, 제2 등과 같은 용어는 실시예들의 다양한 구성요소들을 설명하기 위해 사용될 수 있다. 하지만 실시예들에 따른 다양한 구성요소들은 위 용어들에 의해 해석이 제한되어서는 안된다. 이러한 용어는 하나의 구성요소를 다른 구성요소와 구별하기 위해 사욛외는 것에 불과하다. 것에 불과하다. 예를 들어, 제1 사용자 인풋 시그널은 제2사용자 인풋 시그널로 지칭될 수 있다. 이와 유사하게, 제2사용자 인풋 시그널은 제1사용자 인풋시그널로 지칭될 수 있다. 이러한 용어의 사용은 다양한 실시예들의 범위 내에서 벗어나지 않는 것으로 해석되어야만 한다. 제1사용자 인풋 시그널 및 제2사용자 인풋 시그널은 모두 사용자 인풋 시그널들이지만, 문맥 상 명확하게 나타내지 않는 한 동일한 사용자 인풋 시그널들을 의미하지 않는다.
실시예들을 설명하기 위해 사용된 용어는 특정 실시예들을 설명하기 위한 목적으로 사용되고, 실시예들을 제한하기 위해서 의도되지 않는다. 실시예들의 설명 및 청구항에서 사용된 바와 같이, 문맥 상 명확하게 지칭하지 않는 한 단수는 복수를 포함하는 것으로 의도된다. 및/또는 표현은 용어 간의 모든 가능한 결합을 포함하는 의미로 사용된다. 포함한다 표현은 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들이 존재하는 것을 설명하고, 추가적인 특징들, 수들, 단계들, 엘리먼트들, 및/또는 컴포넌트들을 포함하지 않는 것을 의미하지 않는다. 실시예들을 설명하기 위해 사용되는, ~인 경우, ~때 등의 조건 표현은 선택적인 경우로만 제한 해석되지 않는다. 특정 조건을 만족하는 때, 특정 조건에 대응하여 관련 동작을 수행하거나, 관련 정의가 해석되도록 의도되었다.
또한, 본 문서에서 설명하는 실시예들에 따른 동작은 실시예들에 따라서 메모리 및/또는 프로세서를 포함하는 송수신 장치에 의해 수행될 수 있다. 메모리는 실시예들에 따른 동작을 처리/제어하기 위한 프로그램들을 저장할 수 있고, 프로세서는 본 문서에서 설명한 다양한 동작을 제어할 수 있다. 프로세서는 컨트롤러 등으로 지칭가능하다. 실시예들에 동작들은 펌웨어, 소프트웨어, 및/또는 그것들의 조합에 의해 수행될 수 있고, 펌웨어, 소프트웨어, 및/또는 그것들의 조합은 프로세서에 저장되거나 메모리에 저장될 수 있다.
한편, 상술한 실시예들에 따른 동작은 실시예들 따른 송신 장치 및/또는 수신 장치에 의해서 수행될 수 있다. 송수신 장치는 미디어 데이터를 송수신하는 송수신부, 실시예들에 따른 프로세스에 대한 인스트럭션(프로그램 코드, 알고리즘, flowchart 및/또는 데이터)을 저장하는 메모리, 송/수신 장치의 동작들을 제어하는 프로세서를 포함할 수 있다.
프로세서는 컨트롤러 등으로 지칭될 수 있고, 예를 들어, 하드웨어, 소프트웨어, 및/또는 그것들의 조합에 대응할 수 있다. 상술한 실시예들에 따른 동작은 프로세서에 의해 수행될 수 있다. 또한, 프로세서는 상술한 실시예들의 동작을 위한 인코더/디코더 등으로 구현될 수 있다.
상술한 바와 같이, 실시예들을 실시하기 위한 최선의 형태에서 관련 내용을 설명하였다.
상술한 바와 같이, 실시예들은 포인트 클라우드 데이터 송수신 장치 및 시스템에 전체적 또는 부분적으로 적용될 수 있다.
당업자는 실시예들의 범위 내에서 실시예들을 다양하게 변경 또는 변형할 수 있다.
실시예들은 변경/변형들을 포함할 수 있고, 변경/변형은 청구항들 및 그 와 동일한 것들의 범위를 벗어나지 않는다.

Claims (16)

  1. 메모리; 및
    상기 메모리에 연결된 프로세서; 를 포함하고, 상기 프로세서는,
    제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 미디어 데이터를 수신하고,
    상기 멀티캐스트 미디어 데이터를 디코딩하는,
    멀티캐스트 신호 처리 장치.
  2. 제1항에 있어서,
    상기 제1네트워크 및 상기 제2네트워크는 서로 다르고,
    상기 제1네트워크 또는 상기 제2네트워크 중 적어도 하나는 통신 네트워크, 방송 네트워크, 양방향 네트워크, 또는 단방향 네트워크를 포함하는,
    멀티캐스트 신호 처리 장치.
  3. 제1항에 있어서,
    상기 멀티캐새트 미디어 데이터는 상기 제1네트워크를 통해 수신되고,
    상기 제1네트워크에서 상기 제2네트워크로 변경되는 경우에 대응하여,
    상기 프로세서는,
    상기 제2네트워크를 통해 서비스 리스트 정보를 수신하고,
    상기 서비스 리스트 정보에 기반하여 멀티캐스트 랑데부 서비스 정보를 획득하고,
    상기 랑데부 서비스 정보에 기반하여, 프리젠테이션 마니페스트 정보를 수신하고,
    상기 프리젠테이션 마니페스트 정보에 기반하여, 리다이렉션 정보를 수신하고,
    상기 리다이렉션 정보에 기반하여, 프리젠테이션 마니페스트 정보를 수신하여, 멀티캐스트 미디어 데이터를 수신하는,
    멀티캐스트 신호 처리 장치.
  4. 제1항에 있어서, 상기 프로세서는,
    상기 제1네트워크 또는 상기 제2네트워크 중 적어도 하나에 기반하여, 서비스 리스트 정보를 수신하고,
    상기 제1네트워크를 위한 상기 서비스 리스트 정보는 상기 멀티캐스트 미디어 데이터를 위한 마니페스트 정보에 대한 주소 정보를 포함하고,
    상기 제2네트워크를 위한 상기 서비스 리스트 정보는 상기 멀티캐스트 미디어 데이터를 위한 마니페스트 정보에 대한 주소 정보를 포함하고,
    상기 제1네트워크를 위한 상기 서비스 리스트 정보 및 상기 제2네트워크를 위한 상기 서비스 리스트 정보는 상기 멀티캐스트 미디어 데이터를 위한 식별자 및 멀티캐스트 랑데부를 위한 주소 정보를 포함하는,
    멀티캐스트 신호 처리 장치.
  5. 제1항에 있어서, 상기 프로세서는,
    상기 멀티캐스트 미디어 데이터에 대해 상기 제1네트워크 및 상기 제2네트워크 각각에 대한 프리젠테이션 마니페스트 정보를 관리하는,
    멀티캐스트 신호 처리 장치.
  6. 제1항에 있어서, 상기 프로세서는 상기 멀티캐스트 미디어 데이터를 위한 서비스 리스트 정보를 수신하고,
    상기 서비스 리스트 정보는 프리젠테이션 마니페스트 요청 정보를 포함하고,
    상기 프리젠테이션 마니페스트 요청 정보는 멀티캐스트 랑데부 서비스를 위한 네트워크의 타입 정보, 상기 멀티캐스트 랑데부 서비스를 위한 호스트 주소 정보, 상기 멀티캐스트 랑레부 서비스의 타입 정보를 포함하는,
    멀티캐스트 신호 처리 장치.
  7. 제1항에 있어서, 상기 프로세서는,
    상기 멀티캐스트 미디어 데이터를 위한 멀티캐스트 세션 정보를 수신하고,
    상기 멀티캐스트 세션 정보는 멀티캐스트 세션이 전송되는 네트워크에 대한 식별 정보를 포함하는,
    멀티캐스트 신호 처리 장치.
  8. 프로세서에 의해 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 미디어 데이터를 수신하는 단계; 및
    상기 멀티캐스트 미디어 데이터를 디코딩하는 단계; 를 포함하는,
    멀티캐스트 신호 처리 방법.
  9. 제8항에 있어서,
    상기 제1네트워크 및 상기 제2네트워크는 서로 다르고,
    상기 제1네트워크 또는 상기 제2네트워크 중 적어도 하나는 통신 네트워크, 방송 네트워크, 양방향 네트워크, 또는 단방향 네트워크를 포함하는,
    멀티캐스트 신호 처리 방법.
  10. 제8항에 있어서,
    상기 멀티캐새트 미디어 데이터는 상기 제1네트워크를 통해 수신되고,
    상기 제1네트워크에서 상기 제2네트워크로 변경되는 경우에 대응하여,
    상기 방법은,
    상기 제2네트워크를 통해 서비스 리스트 정보를 수신하고,
    상기 서비스 리스트 정보에 기반하여 멀티캐스트 랑데부 서비스 정보를 획득하고,
    상기 랑데부 서비스 정보에 기반하여, 프리젠테이션 마니페스트 정보를 수신하고,
    상기 프리젠테이션 마니페스트 정보에 기반하여, 리다이렉션 정보를 수신하고,
    상기 리다이렉션 정보에 기반하여, 프리젠테이션 마니페스트 정보를 수신하여, 멀티캐스트 미디어 데이터를 수신하는,
    멀티캐스트 신호 처리 방법.
  11. 제8항에 있어서, 상기 방법은,
    상기 제1네트워크 또는 상기 제2네트워크 중 적어도 하나에 기반하여, 서비스 리스트 정보를 수신하고,
    상기 제1네트워크를 위한 상기 서비스 리스트 정보는 상기 멀티캐스트 미디어 데이터를 위한 마니페스트 정보에 대한 주소 정보를 포함하고,
    상기 제2네트워크를 위한 상기 서비스 리스트 정보는 상기 멀티캐스트 미디어 데이터를 위한 마니페스트 정보에 대한 주소 정보를 포함하고,
    상기 제1네트워크를 위한 상기 서비스 리스트 정보 및 상기 제2네트워크를 위한 상기 서비스 리스트 정보는 상기 멀티캐스트 미디어 데이터를 위한 식별자 및 멀티캐스트 랑데부를 위한 주소 정보를 포함하는,
    멀티캐스트 신호 처리 방법.
  12. 제8항에 있어서, 상기 프로세서는,
    상기 멀티캐스트 미디어 데이터에 대해 상기 제1네트워크 및 상기 제2네트워크 각각에 대한 프리젠테이션 마니페스트 정보를 관리하는,
    멀티캐스트 신호 처리 방법.
  13. 제8항에 있어서, 상기 프로세서는 상기 멀티캐스트 미디어 데이터를 위한 서비스 리스트 정보를 수신하고,
    상기 서비스 리스트 정보는 프리젠테이션 마니페스트 요청 정보를 포함하고,
    상기 프리젠테이션 마니페스트 요청 정보는 멀티캐스트 랑데부 서비스를 위한 네트워크의 타입 정보, 상기 멀티캐스트 랑데부 서비스를 위한 호스트 주소 정보, 상기 멀티캐스트 랑레부 서비스의 타입 정보를 포함하는,
    멀티캐스트 신호 처리 방법.
  14. 제1항에 있어서, 상기 프로세서는,
    상기 멀티캐스트 미디어 데이터를 위한 멀티캐스트 세션 정보를 수신하고,
    상기 멀티캐스트 세션 정보는 멀티캐스트 세션이 전송되는 네트워크에 대한 식별 정보르 포함하는,
    멀티캐스트 신호 처리 방법.
  15. 멀티캐스트 미디어 데이터를 생성하는 단계;
    상기 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 생성하는 단계;
    상기 멀티캐스트 미디어 데이터를 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 방식으로 전송하는 단계; 및
    상기 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 전송하는 단계; 를 포함하는,
    멀티캐스트 신호 처리 방법.
  16. 메모리; 및
    상기 메모리에 연결된 프로세서; 를 포함하고, 상기 프로세서는,
    멀티캐스트 미디어 데이터를 생성하고,
    상기 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 생성하고,
    상기 멀티캐스트 미디어 데이터를 제1네트워크 또는 제2네트워크 중 적어도 하나에 기반하여 멀티캐스트 방식으로 전송하고, 및
    상기 멀티캐스트 미디어 데이터에 대한 시그널링 정보를 전송하는,
    멀티캐스트 신호 처리 장치.
PCT/KR2021/015747 2020-11-03 2021-11-03 멀티캐스트 신호 처리 방법 및 장치 WO2022098070A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21889535.7A EP4243429A4 (en) 2020-11-03 2021-11-03 Method and apparatus for processing multicast signal
US18/030,179 US12231704B2 (en) 2020-11-03 2021-11-03 Method and apparatus for processing multicast signal

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR20200145393 2020-11-03
KR10-2020-0145393 2020-11-03

Publications (1)

Publication Number Publication Date
WO2022098070A1 true WO2022098070A1 (ko) 2022-05-12

Family

ID=81458135

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2021/015747 WO2022098070A1 (ko) 2020-11-03 2021-11-03 멀티캐스트 신호 처리 방법 및 장치

Country Status (3)

Country Link
US (1) US12231704B2 (ko)
EP (1) EP4243429A4 (ko)
WO (1) WO2022098070A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4555740A1 (en) * 2022-07-13 2025-05-21 ARRIS Enterprises LLC Techniques for efficient content delivery in a multicast adaptive bit rate (mabr) system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7768913B1 (en) * 2002-10-09 2010-08-03 Juniper Networks, Inc. Delivering and receiving multicast content across a unicast network
KR20120085508A (ko) * 2011-01-24 2012-08-01 한국과학기술원 다중 소스 멀티캐스트 기반 콘텐츠 전송 방법 및 시스템
US20160173547A1 (en) * 2011-05-10 2016-06-16 At&T Intellectual Property I, Lp System and method for delivering content over a multicast network
US20200029101A1 (en) * 2009-09-15 2020-01-23 Comcast Cable Communications, Llc Control Plane Architecture for Multicast Cache-Fill

Family Cites Families (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100495380C (zh) * 2003-03-20 2009-06-03 汤姆森特许公司 用组播ip和以太网定位并分发卫星信号的系统和方法
US20060269225A1 (en) * 2003-05-14 2006-11-30 Kenichiro Tada Information recording device, information output device, information recording program, information output program, recording medium, and information recording medium
US20050071318A1 (en) * 2003-09-30 2005-03-31 International Business Machines Corporation Complex table rendering and navigation with highly constrained devices
EP1528808A3 (en) * 2003-10-27 2008-03-26 Matsushita Electric Industrial Co., Ltd. Apparatus for receiving a broadcast signal
US7661120B2 (en) * 2003-11-26 2010-02-09 Wegener Communications, Inc. Automated transport stream apparatus and method
FR2878397A1 (fr) * 2004-11-25 2006-05-26 Thomson Licensing Sa Appareil et methode de distribution sur un reseau local de services diffuses
EP1727060A1 (fr) * 2005-05-27 2006-11-29 France Telecom Procédé et dispositif de construction et d'utilisation d'une table de profils réduits de parangons, produit programme d'ordinateur correspondant
US7376646B2 (en) * 2005-06-17 2008-05-20 International Business Machines Corporation Cost-based subquery correlation and decorrelation
US7991866B2 (en) * 2006-08-18 2011-08-02 Control4 Corporation Systems and methods for updating a site
US8576858B2 (en) * 2006-12-13 2013-11-05 Viasat, Inc. Multiple transmission paths for hierarchical layers
KR100781918B1 (ko) * 2007-02-02 2007-12-04 가온미디어 주식회사 Ｍｄｕ 방송 신호 분배 시스템
US8434120B2 (en) * 2007-06-26 2013-04-30 Thomson Licensing System and method for grouping program identifiers into multicast groups
US20090025027A1 (en) * 2007-07-20 2009-01-22 Michael Craner Systems & methods for allocating bandwidth in switched digital video systems based on interest
US7802286B2 (en) * 2007-07-24 2010-09-21 Time Warner Cable Inc. Methods and apparatus for format selection for network optimization
US7733819B2 (en) * 2007-08-24 2010-06-08 Lg Electronics Inc. Digital broadcasting system and method of processing data in digital broadcasting system
US8099757B2 (en) * 2007-10-15 2012-01-17 Time Warner Cable Inc. Methods and apparatus for revenue-optimized delivery of content in a network
US8578432B2 (en) * 2007-12-07 2013-11-05 Cisco Technology, Inc. Policy control over switched delivery networks
US8126931B2 (en) * 2008-06-13 2012-02-28 Sap Ag Method and apparatus for displaying the composition of a data structure during runtime
US8112781B2 (en) * 2008-10-07 2012-02-07 General Instrument Corporation Content delivery system having an edge resource manager performing bandwidth reclamation
US8365007B2 (en) * 2009-09-10 2013-01-29 Time Warner Cable, Inc. System for controlling the state of a switched digital video system and method therefor
EP2534836A4 (en) * 2010-02-11 2014-10-01 Beaumaris Networks Inc D B A Bni Video BANDWIDTH ALLOCATION FOR MULTIPLE SERVICES
JP5569053B2 (ja) * 2010-03-11 2014-08-13 ソニー株式会社 コンテンツ配信装置、コンテンツ配信方法および送信サーバ
US8467412B2 (en) * 2010-04-14 2013-06-18 Ericsson Television Inc. Adaptive rate shifting for delivery of video services to service groups
KR20120084234A (ko) * 2011-01-19 2012-07-27 삼성전자주식회사 Ｍｐｅｇ ｍｅｄｉａ ｔｒａｎｓｐｏｒｔ（ｍｍｔ）에서 ｍｍｔ ａｕ를 전송하는 방법
US9197907B2 (en) * 2011-10-07 2015-11-24 Ericsson Ab Adaptive ads with advertising markers
WO2013090877A1 (en) * 2011-12-15 2013-06-20 Thomson Licensing System and method for inserting local content into satellite broadcast programs and epg on a network
EP2634961A1 (en) * 2012-03-01 2013-09-04 Thomson Licensing Management of the transmission of data streams over multiple networks
CN105339922B (zh) * 2013-02-12 2018-10-12 爱立信股份有限公司 个人过顶网络视频记录器
US9066153B2 (en) * 2013-03-15 2015-06-23 Time Warner Cable Enterprises Llc Apparatus and methods for multicast delivery of content in a content delivery network
US8869218B2 (en) * 2013-03-15 2014-10-21 Wowza Media Systems, LLC On the fly transcoding of video on demand content for adaptive streaming
US9402107B2 (en) * 2013-03-15 2016-07-26 Time Warner Cable Enterprises Llc Apparatus and methods for delivery of multicast and unicast content in a content delivery network
US8762564B1 (en) * 2013-07-10 2014-06-24 Mdialog Corporation Method and system for dynamically selecting, assembling and inserting content into stream media
US10057618B2 (en) * 2014-06-06 2018-08-21 Microsoft Technology Licensing, Llc System for filtering media manifests using manifest attributes
HUE047619T2 (hu) * 2014-10-20 2020-05-28 Guangdong Oppo Mobile Telecommunications Corp Ltd Rendszer és módszer a multicast tartalom adatok átviteli paraméterei beállítására
US9788302B2 (en) * 2014-12-01 2017-10-10 At&T Intellectual Property I, L.P. Method and apparatus for delivering media content and backup media content using multiple networks
US20180139476A1 (en) * 2015-05-06 2018-05-17 Sharp Kabushiki Kaisha Dynamic event signaling
US10708349B2 (en) * 2015-10-09 2020-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Offloading a distribution server task to a media gateway
CN108702256B (zh) * 2015-12-18 2021-10-08 巴伐利亚发动机制造厂股份有限公司 通过装置对装置通信接收/传输数据封包的方法
WO2018155798A1 (ko) * 2017-02-22 2018-08-30 엘지전자 주식회사 멀티캐스트 신호 송수신 방법 및 장치
DE112018002893T5 (de) * 2017-06-07 2020-02-20 Lg Electronics Inc. Verfahren zum Senden und Empfangen eines Rundsendungssignals und eine Vorrichtung hierfür
WO2021053375A1 (en) * 2019-09-19 2021-03-25 Naxos Finance Sa System for the reproduction of a multimedia content using an alternative network if poor quality in first network
US12088653B2 (en) * 2020-06-30 2024-09-10 Lg Electronics Inc. Method and apparatus for processing multicast signal

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7768913B1 (en) * 2002-10-09 2010-08-03 Juniper Networks, Inc. Delivering and receiving multicast content across a unicast network
US20200029101A1 (en) * 2009-09-15 2020-01-23 Comcast Cable Communications, Llc Control Plane Architecture for Multicast Cache-Fill
KR20120085508A (ko) * 2011-01-24 2012-08-01 한국과학기술원 다중 소스 멀티캐스트 기반 콘텐츠 전송 방법 및 시스템
US20160173547A1 (en) * 2011-05-10 2016-06-16 At&T Intellectual Property I, Lp System and method for delivering content over a multicast network

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Adaptive media streaming over IP multicast DVB Document A176 (Second edition)", DVB BLUEBOOK A176, DVB, 1 March 2020 (2020-03-01), pages 1 - 110, XP055931193, Retrieved from the Internet <URL:https://dvb.org/wp-content/uploads/2020/03/A176_Adaptive-Media-Streaming-over-IP-Multicast_Mar-2020.pdf> [retrieved on 20220614] *
See also references of EP4243429A4 *

Also Published As

Publication number Publication date
US20230379516A1 (en) 2023-11-23
EP4243429A4 (en) 2024-07-31
US12231704B2 (en) 2025-02-18
EP4243429A1 (en) 2023-09-13

Similar Documents

Publication Publication Date Title
WO2022177347A1 (en) Method and device for edge application server discovery
WO2022005102A1 (ko) 멀티캐스트 신호 처리 방법 및 장치
WO2016140477A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016140478A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016018042A1 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
WO2016140483A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2011034283A1 (en) Method of processing epg metadata in network device and the network device for controlling the same
WO2018052274A1 (en) Method for managing communication in mission critical data (mcdata) communication system
WO2017014586A1 (ko) 방송 신호 송수신 장치 및 방법
WO2020091573A1 (ko) 방송 송신 장치, 방송 송신 방법, 방송 수신 장치 및 방송 수신 방법
WO2015178690A1 (ko) 방송 신호 송/수신 처리 방법 및 장치
WO2016163772A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016144031A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016190662A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2022197169A1 (ko) 멀티캐스트 신호 처리 방법 및 장치
WO2016171518A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017209574A1 (ko) 미디어 콘텐츠 제공 방법 및 장치
WO2016178549A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016064150A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2019212318A1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2016171528A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017123044A1 (ko) 방송 신호 송수신 장치 및 방법
WO2017014553A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2022098070A1 (ko) 멀티캐스트 신호 처리 방법 및 장치
WO2016195412A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Legal Events

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

Ref document number: 21889535

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021889535

Country of ref document: EP

Effective date: 20230605