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

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

Info

Publication number
WO2022197169A1
WO2022197169A1 PCT/KR2022/095043 KR2022095043W WO2022197169A1 WO 2022197169 A1 WO2022197169 A1 WO 2022197169A1 KR 2022095043 W KR2022095043 W KR 2022095043W WO 2022197169 A1 WO2022197169 A1 WO 2022197169A1
Authority
WO
WIPO (PCT)
Prior art keywords
multicast
service
network
gateway
interface
Prior art date
Application number
PCT/KR2022/095043
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 KR1020237025946A priority Critical patent/KR20230129247A/ko
Priority to US18/277,187 priority patent/US20240121123A1/en
Priority to CN202280020660.9A priority patent/CN116941233A/zh
Publication of WO2022197169A1 publication Critical patent/WO2022197169A1/ko

Links

Images

Classifications

    • 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
    • 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
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1886—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with traffic restrictions for efficiency improvement, e.g. involving subnets or subdomains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/1026—Media gateways at the edge
    • 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/1033—Signalling gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1836—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture
    • H04L12/184—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with heterogeneous network architecture with heterogeneous receivers, e.g. layered multicast

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. Accordingly, 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.
  • An apparatus for receiving a multicast signal includes: a multicast gateway configured to receive a multicast signal based on an interface from a multicast server; and a content playback unit that plays a multicast service included in the multicast signal.
  • a method for receiving a multicast signal according to embodiments includes: receiving a multicast signal from a multicast server based on an interface; and playing a multicast service included in the multicast signal.
  • 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 several 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.
  • FIG. 5 shows a flow diagram of multicast-based media reception according to embodiments
  • FIG. 6 illustrates elements included in URLs according to embodiments.
  • FIG. 8 shows a multicast application method for 5G media streaming according to embodiments.
  • FIG. 9 shows a multitask streaming structure for both multicast network and communication network streaming according to embodiments.
  • FIG. 10 illustrates an architecture for wireless media transmission based on multicast and broadcast in a communication network according to embodiments.
  • FIG. 11 shows an example of a multicast server configuration in each network according to embodiments.
  • FIG. 12 shows an example of a multicast server configuration for all networks according to embodiments.
  • FIG 13 shows an example of multiple networks to which devices connect according to embodiments.
  • FIG. 15 shows an example in which a multicast server and a multicast gateway are configured in each network according to embodiments.
  • 16 shows a network change flow diagram according to embodiments.
  • FIG. 17 shows an example in which a multicast server and a multicast gateway are configured in each network according to the embodiments
  • FIG. 18 shows a network change flow diagram according to embodiments.
  • FIG. 19 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.
  • 21 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.
  • FIG. 22 shows a network change flow diagram according to embodiments.
  • FIG. 24 shows a network change flow diagram according to embodiments.
  • FIG. 25 shows an embodiment in which a device connects to various serviceable networks when a multicast server and a multicast gateway are configured in each network according to the embodiments.
  • 26 shows a structure in which a single multicast server provides a service for a plurality of heterogeneous networks, and a multicast gateway for this is configured in each network according to embodiments.
  • FIG. 27 shows a protocol configuration for ABR multicast according to embodiments.
  • FIG. 28 shows an embodiment of a protocol that can be configured in a receiving device to access a plurality of networks according to embodiments.
  • 29 shows a protocol according to embodiments.
  • FIG. 30 shows a configuration of services and service-related information according to embodiments.
  • 31 illustrates a method of generating and transmitting a service list and a presentation manifest for ABR multicast according to embodiments.
  • 35 shows an element included in a Request URL of an HTTP message according to embodiments.
  • 36 shows information included in a Redirect URL of a Location response header according to embodiments.
  • 40 shows a MABR network configuration for a unidirectional delivery ratio according to embodiments.
  • 41 shows a MABR network configuration for a unidirectional delivery ratio according to embodiments.
  • LCD 44 shows a link control data (LCD) configuration according to the embodiments.
  • NCD network control data
  • 49 shows a mABR IPv4 transport session descriptor according to embodiments.
  • 50 shows a 5G system service infrastructure structure according to embodiments.
  • 51 shows a 5G system structure in a reference point representation according to embodiments.
  • FIG. 52 shows a 5G system structure for multiple PDU sessions according to embodiments.
  • 53 shows a 5G system structure for coexisting access to two data networks according to embodiments.
  • 54 illustrates a user plane protocol stack according to embodiments.
  • UDM 55 illustrates Unified Data Management (UDM) according to embodiments.
  • 57 illustrates a Media Architecture for unicast downlink media streaming according to embodiments.
  • FIG. 58 shows a reference structure according to embodiments.
  • 59 shows a reference structure according to embodiments.
  • 60 illustrates a multicast gateway distribution model according to embodiments
  • 61 shows a structure of a multicast gateway distributed in a home gateway device according to embodiments.
  • FIG. 62 illustrates a structure of a multicast gateway distributed in a terminal device according to embodiments.
  • 63 shows a hybrid broadcast receiving apparatus according to embodiments.
  • 64 shows a multicast GSE layer structure according to embodiments.
  • FIG. 65 illustrates a DVB-GSE Robust Header Compression (ROHC) profile and a DVB-GSE header compressor according to embodiments.
  • ROHC Robust Header Compression
  • 67 shows a transmitting apparatus and a receiving apparatus according to the embodiments.
  • 68 shows a multicast transmission method according to embodiments.
  • 69 shows a multicast reception method according to embodiments.
  • the multicast signal processing method and apparatus may include a multicast signal transmission method, a reception method, a transmission apparatus, and a reception apparatus, and may be abbreviated as a method/apparatus according to the embodiments.
  • a method/apparatus relates to a method of transmitting media in a unidirectional transmission-based Adaptive Bitrate Multicast network (Method of Media Delivery in Adaptive Bitrate Multicast Network based on Unidirectional Delivery).
  • 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 Internet Protocol (IP)-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.
  • Method / apparatus to provide a multicast transport session mapping (Multicast Transport Session mapping) method for adaptive bitrate multicast media transmission in a unidirectional delivery network (Unidirectional Delivery Network).
  • Multicast Transport Session mapping Multicast Transport Session mapping
  • a multicast transport session may be mapped to a resource of a unidirectional delivery network.
  • the ABR multicast structure defined in DVB is mainly defined when the multicast network is a single network.
  • 5G network wireless network
  • the actual ABR multicast service may not be provided due to implementation difficulties and cost problems.
  • 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.
  • the method/device provides an interface for interworking a multicast transport session with a broadcast stream in order to transmit a media object of DVB ABR multicast in a unidirectional delivery network such as a terrestrial broadcast and a satellite broadcast link defined in the DVB standard. and signaling flow.
  • ABR adaptive bitrate
  • the multicast signal processing method/apparatus may transmit media contents in 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 multicast server (Multicast Server) to transmit multicast IP contents and multicast gateway (Multicast Gateway) to receive it.
  • Multicast Server Multicast Server
  • Multicast Gateway Multicast Gateway
  • 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 through 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 may 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 (decryption), 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.
  • a 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 through a reference point B first.
  • a 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 perform configuration for media reception through the following operation.
  • Multicast rendezvous service is implemented in the same device as Multicast gateway
  • 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 multicast session currently provisioned through a reference point CMR (reference point CMR) or 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 where they are co-located (Co-located deployment) 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 of the multicast session set currently provisioned through the reference point M can be applied to the multicast gateway.
  • the in-band multicast gateway configuration method may be used for each configuration.
  • FIG. 5 shows a flow diagram of multicast-based media reception according to embodiments
  • the 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 may 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 redirection message transmitted.
  • 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.
  • FIG. 6 illustrates elements included in URLs 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 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 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 the multicast gateway configuration instance document including the multicast session corresponding to the requested presentation manifest.
  • Multicast ABR may be connected to a 5G network (communication network).
  • 5G network communication network
  • FIG. 8 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 shown in 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 shown in 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.
  • Multicast protocol can use the protocol defined in M interface.
  • 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. 9 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. 9 corresponds to hardware, software, a processor, and/or a combination thereof.
  • 9 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. 10 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. 10 corresponds to hardware, software, a processor, and/or a combination thereof.
  • 5GMSd Application Provider may be the same as Multicast ABR Content Provider, 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 application of Multicast ABR 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 Multicast Gateway and 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.
  • FIGS. 1-6 and the like correspond to a method/apparatus for processing a multicast signal according to the embodiments shown in FIGS. 1-6 and the like.
  • FIG. 11 shows an example of a multicast server configuration in each network according to embodiments.
  • FIG. 11 shows 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 Fig. 11 corresponds to hardware, software, a processor, and/or a combination thereof.
  • ABR multicast When ABR multicast is serviced through a plurality of heterogeneous networks, the 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.
  • FIG. 12 shows an example of a multicast server configuration for all networks according to embodiments.
  • 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.
  • Each component in Fig. 12 corresponds to hardware, software, a processor, and/or a combination thereof.
  • ABR multicast When ABR multicast is serviced through a plurality of heterogeneous networks, the 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.
  • FIG 13 shows an example of multiple networks to which devices connect according to embodiments.
  • a multicast signal processing method/apparatus 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. 13 .
  • Each component in Fig. 13 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.
  • a service discovery interface may follow a method defined separately between a service provider and an application.
  • each network can support transmission and reception of data for the service discovery interface.
  • 11-13 shows an example in which the multicast signal processing apparatus according to the embodiments such as FIGS. 1-6 and 9-10 is configured according to the 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. 14 is a flowchart of a network change according to embodiments.
  • FIG. 14 The flowchart of Fig. 14 may be performed according to the embodiments shown in Figs. 1-5, 8-13, 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 the multicast session may be transmitted.
  • 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.
  • 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 may be requested through the manifest request and redirection information.
  • 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 can be performed through the manifest request and redirection information.
  • 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 corresponding 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.
  • 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 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 corresponding 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. 15 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. 13 and may include a network server and a gateway as shown in FIG. 15 .
  • 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. 15 .
  • Each component in Fig. 15 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.
  • a service discovery interface may follow a method defined separately between a service provider and an application.
  • each network can support transmission and reception of data for the service discovery interface.
  • 16 shows a network change flow diagram according to embodiments.
  • FIG. 16 The flowchart of Fig. 16 may be performed according to the embodiments shown in Figs. 1-5, 8-15, 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 multicast media for the architecture according to the embodiments.
  • the difference from FIG. 14 is that the network of FIG. 16 includes 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 along the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the corresponding 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 optionally 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.
  • 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 corresponding 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. 17 shows an example in which a multicast server and a multicast gateway are configured in each network according to 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.
  • a service discovery interface may follow a method defined separately between a service provider and an application.
  • each network can support transmission and reception of data for the service discovery interface.
  • FIG. 18 shows a network change flow diagram according to embodiments.
  • FIG. 18 The flowchart of Fig. 18 may be performed according to the embodiments shown in Figs. 1-5, 8-17, 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 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 optionally 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 corresponding 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.
  • 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 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 corresponding 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 of providing a network initial 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 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.
  • the multicast rendezvous service is required because the media transmission and reception is multicast, and the media is already watched by someone else.
  • FIG. 19 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. 19 .
  • Each component in Fig. 19 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.
  • a service discovery interface may follow a method defined separately between a service provider and an application.
  • each network can support transmission and reception of data for the service discovery interface.
  • FIG. 20 The flowchart of Fig. 20 may be performed according to the embodiments shown in Figs. 1-5, 8-19, 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 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 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 along the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the corresponding 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.
  • 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 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 corresponding 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.
  • 21 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.
  • a configuration of a service provider, network(s), and device according to embodiments is shown in FIG. 21 .
  • Each component in Fig. 21 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.
  • a service discovery interface may follow a method defined separately between a service provider and an application.
  • each network can support transmission and reception of data for the service discovery interface.
  • FIG. 22 shows a network change flow diagram according to embodiments.
  • FIG. 22 The flowchart of Fig. 22 may be performed according to the embodiments shown in Figs. 1-5, 8-21, 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 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 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 along the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the corresponding 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 optionally 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.
  • 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 corresponding 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.
  • 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.
  • a service discovery interface may follow a method defined separately between a service provider and an application.
  • each network can support transmission and reception of data for the service discovery interface.
  • FIG. 24 shows a network change flow diagram according to embodiments.
  • FIG. 24 The flowchart of Fig. 24 may be performed according to the embodiments shown in Figs. 1-5, 8-23, 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 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 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) may be delivered.
  • the following process can be optionally 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 corresponding 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.
  • 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 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 corresponding 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.
  • FIG. 25 shows an embodiment in which a device connects to 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 will be described later.
  • 26 shows a structure in which a single multicast server provides a service for 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 transmission/reception device 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.
  • FIG. 27 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.
  • a protocol for receiving HTTP-based adaptive media streaming from a multicast gateway, and a file format and media coded for the received adaptive streaming can be configured.
  • Layer 1 and Layer 2 protocols may be configured as optimal protocols for each network.
  • embodiments may include the following protocols.
  • FIG. 28 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 capable of receiving 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.
  • 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 capable of receiving 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.
  • 29 shows a protocol according to embodiments.
  • a multicast gateway is configured in network A in network A, and a multicast gateway is configured in a device in 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 capable of receiving 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 directly configured 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.
  • FIG. 30 shows a configuration of services and service-related information according to embodiments.
  • 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.
  • 31 illustrates a method of generating and transmitting a service list and a 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. 31 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 obtain multicast session configuration information for this purpose.
  • MPD presentation manifest
  • the receiving device may manage the service list and the presentation manifest as shown in FIG. 32 .
  • the service list and presentation manifest (ex. MPD) configured in the structure 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.
  • Service List - 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 where 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 - An element for a multicast transport session may be optionally transmitted when the device includes a multicast gateway. If the MulticastTransportSession element is not sent, information can be provided through multicast gateway configuration.
  • 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.
  • the elements included in the URL according to the embodiments are as shown in FIG. 35 .
  • 35 shows 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.
  • each multicast gateway is configured with a differential priority to receive multicast 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.
  • 36 shows information included in a Redirect URL of a Location response header according to embodiments.
  • 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 URL query string parameters.
  • 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.
  • a service discovery interface may follow a method defined separately between a service provider and an 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, 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.
  • a service discovery interface may follow a method defined separately between a service provider and an 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 about 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, 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 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 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 through the service directory in the application.
  • 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 along the redirection.
  • the presentation manifest is cached in the multicast gateway (A) in advance, the corresponding 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 corresponding 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.
  • 40 shows a MABR network configuration for a unidirectional delivery ratio according to embodiments.
  • the method/apparatus according to the embodiments may support unidirectional delivery, and an example of multicast transport session mapping for this will be described.
  • a multicast ABR service provider configures a multicast server for each network, and transmits multicast contents and configuration information to a multicast gateway and a multicast rendezvous service using a multicast interface (M).
  • M multicast interface
  • the M interface may be configured through a unidirectional network without an uplink channel, and the unidirectional network may consider a satellite (broadcast) network or a terrestrial broadcast network.
  • Multicast ABR contents and configuration information received from the multicast gateway and multicast rendezvous service can be delivered to the content playback function using HTTP, etc. provided by the L interface, and the multicast gateway can operate as a server of the Home Broadcasting (HB) network. have.
  • HB Home Broadcasting
  • L interface and B interface can be configured in the content playback function in the device or HB network.
  • Media streaming through multicast gateway can be received through L interface, and access information for initial multicast gateway can be received through B interface.
  • the L interface and the B interface can be replaced with the device internal interface.
  • the service list that can inform service access information (URI, etc.) is delivered from the content provider to the service list registry
  • the service list information managed by the service list registry can be delivered to the multicast service, and the multicast server M It can be transmitted to multicast gateway through interface.
  • 41 shows a MABR network configuration for a unidirectional delivery ratio according to embodiments.
  • a multicast ABR service provider configures a single multicast server, and transmits the same multicast contents and configuration information to a multicast gateway and a multicast rendezvous service using the same multicast interface (M).
  • M interface may be configured through a unidirectional network without an uplink channel, and the unidirectional network may consider a satellite (broadcast) network or a terrestrial broadcast network.
  • Multicast ABR contents and configuration information received from the multicast gateway and multicast rendezvous service can be delivered to the content playback function using HTTP, etc. provided by the L interface, and the multicast gateway can operate as a server of the Home Broadcasting (HB) network. have.
  • HB Home Broadcasting
  • L interface and B interface can be configured in the content playback function in the device or HB network.
  • Media streaming through multicast gateway can be received through L interface, and access information for initial multicast gateway can be received through B interface.
  • the L interface and the B interface can be replaced with the device internal interface.
  • the service list that can inform service access information (URI, etc.) is delivered from the content provider to the service list registry
  • the service list information managed by the service list registry can be delivered to the multicast service, and the multicast server M It can be transmitted to a multicast gateway through the interface.
  • the configuration of the M interface according to the embodiment shown in FIG. 41 and the like is as follows.
  • the method/device may perform unidirectional delivery.
  • unidirectional is composed of a satellite channel
  • the physical layer may be composed of DVB-S2 or DVB-S2X
  • the data link layer may be composed of DVB-GSE.
  • the multicast server transmits a multicast transport session to the multicast gateway through the protocol defined in the M interface, and the satellite transmitter receives it and transmits it to the satellite receiver through the satellite channel.
  • the satellite receiver delivers it back to the multicast gateway as it is with the protocol defined in the M interface.
  • a multicast transport session when transmitted to a satellite channel, it can be multiplexed into single signaling, and in order to de-multiplex the multicast transport session and deliver it to a multicast gateway, multicast transport corresponding to IP multicast transmitted through a satellite channel You can map sessions.
  • data link layer signaling may be used to map a multicast transport session.
  • the method/device may perform unidirectional delivery.
  • unidirectional is composed of a broadcast channel
  • the physical layer may be composed of DVB-T2
  • the data link layer may be composed of DVB-GSE.
  • the broadcast transmitter receives it and transmits it to the broadcast receiver through the broadcast channel.
  • the broadcast receiver delivers it back to the multicast gateway as it is with the protocol defined in the M interface.
  • a multicast transport session is transmitted over a broadcast channel, it can be multiplexed with single signaling, and in order to de-multiplex the multicast transport session and deliver it to the multicast gateway, multicast transport corresponding to IP multicast transmitted through the broadcast channel You can map sessions.
  • data link layer signaling may be used to map a multicast transport session.
  • a DVB-DASH based service according to ETSI TS 103 285 may be included in the DVB-I service list according to embodiments.
  • the DVB-DASH based service of DVB-NIP may be delivered using the DVB-MABR defined FLUTE/ROUTE protocol through the DVB broadcast network defined in ETSI TS 103 769.
  • DVB-DASH ETSI TS 103 285 Signaling and A/V services (using DVB-DASH ETSI TS 103 285) are delivered on broadcast RF channels via IP multicast.
  • a DVB-NIP IP multicast session is carried using the GSE-Lite profile defined in clause D.2 of ETSI TS 102 606-1 or multi-protocol encapsulation as defined in ETSI EN 301 192 at the data link layer.
  • DVB-S2X ETSI 302 307-1, ETSI 302 307-2
  • DVB-S2 ETSI 302 307-1
  • DVB-S2 ETSI 302 307-1
  • DVB-S2 ETSI 302 307-1
  • DVB-T2 ETSI TS 102 755
  • LCD 44 shows a link control data (LCD) configuration according to the embodiments.
  • the method/apparatus according to the embodiments may perform unidirectional delivery.
  • DVB-GSE LLC Logical Layer Control
  • DVB-GSE LLC consists of Link Control Data (LCD) and Network Control Data (NCD).
  • the syntax of the LCD may be configured as shown in FIG. 44 .
  • PHY_descriptors() Descriptor for modulation system of physical layer.
  • number_of_links Indicates the number of links or physical streams included in the modulation system of the physical layer.
  • link_id - An identifier for a physical link included in the modulation system of the physical layer.
  • link_association_descriptors() may be configured as follows.
  • modulation_system_type Indicates the type of broadcast modulation system. For example, it can be encoded as follows.
  • modulation_system_id A unique identifier for the modulation system.
  • PHY_stream_id - It can be encoded as follows according to modulation_system_type.
  • modulation_system_type 0x00 - Input Stream Identifier (ISI) of DVB-S2/S2X
  • modulation_system_type 0x01 - Physical layer pipe of DVB-T2
  • the NCD may be configured as follows.
  • NCD network control data
  • platform_descriptor(), target_descriptor(), and operational_descriptor can be defined for each signaling purpose.
  • target_descriptors() if the GSE has only IP address information, it can process multicast according to embodiments. Accordingly, target_descriptors( ) according to the embodiments may solve the problem by including information for multicast identification.
  • platform_descriptor(), target_descriptor(), and operational_descriptor can be defined for each signaling purpose.
  • the method/apparatus according to the embodiments may perform transport session mapping based on a multicast transport session.
  • a multicast transport session transmitted from the multicast server may be defined as shown in FIG. 47 .
  • a multicast transport session transmitted from the multicast server may be mapped to an IP multicast stream in a unidirectional delivery transmitter (satellite transmitter), and IP multicast stream information may be transmitted to a unidirectional delivery receiver (satellite receiver).
  • the descriptor shown in FIG. 48 may be included in the target descriptor.
  • descriptor_tag Corresponds to the identifier for the descriptor.
  • descriptor_length - indicates the length of the corresponding descriptor.
  • multicast_transport_session_id_length - indicates the length of the multicast_transport_session_id appearing after in byte unit.
  • multicast_transport_session_id A unique identifier for a multicast transport session, and has the same value as the id value included in the multicast ABR session configuration.
  • source_IPv6_address Indicates the source IP address for the current multicast transport session transmitted over IPv6.
  • destination_IPv6_address - indicates the group (destination) IP address for the current multicast transport session transmitted over IPv6.
  • source_UDP_port Indicates the source UDP port for the current multicast transport session.
  • destination_UDP_port Indicates the destination UDP port for the current multicast transport session.
  • the method/device according to the embodiments may support multicast.
  • transport session descriptor may be referred to as a multicast list descriptor, and may further include the following information.
  • num_multicasts This 16-bit field indicates the number of multicasts.
  • multicast_stream_id This 16-bit field uniquely identifies an IP/UDP multicast stream within the physical link identified by link_id.
  • source_ip_address This 32-bit field indicates the source IPv4 address of the multicast carried on the physical link identified by link_id.
  • destination_ip_address This 32-bit field indicates the destination IPv4 address of the multicast carried on the physical link identified by link_id.
  • source_port This 16-bit field indicates the source UDP port number of the multicast carried on the physical link identified by link_id.
  • destination_port This 16-bit field indicates the destination UDP port number of the multicast carried on the physical link identified by link_id.
  • header_compression_flag This 1-bit boolean field indicates whether header compression is applied to the multicast stream identified by multicast_stream_id. A value of 0 (zero) indicates that the multicast stream is delivered without header compression in the DVB-GSE layer. A value of 1 (one) indicates that header compression is applied to the multicast stream of the DVB-GSE layer. When the value of compressed_flag is equal to 1, the ROHC-U descriptor or ROHC-U_ multicast_descriptor is signaled.
  • reserved_for_future_use This 7-bit field is reserved for future use and all bits must be set to 0.
  • 49 shows a mABR IPv4 transport session descriptor according to embodiments.
  • the method/device according to the embodiments may include a descriptor as shown in FIG. 49 in a target descriptor when a multicast transport session is transmitted through IPv4.
  • descriptor_tag Corresponds to the identifier for the descriptor.
  • descriptor_length - indicates the length of the corresponding descriptor.
  • multicast_transport_session_id_length - indicates the length of the multicast_transport_session_id appearing after in byte unit.
  • multicast_transport_session_id A unique identifier for a multicast transport session, and has the same value as the id value included in the multicast ABR session configuration.
  • source_IPv6_address Indicates the source IP address for the current multicast transport session transmitted over IPv4.
  • destination_IPv6_address Indicates the group (destination) IP address for the current multicast transport session transmitted over IPv4.
  • source_UDP_port Indicates the source UDP port for the current multicast transport session.
  • destination_UDP_port Indicates the destination UDP port for the current multicast transport session.
  • a plurality of mABR_IPv6_transport_session_descriptor () or mABR_IPv4_transport_session_descriptor () may be included in the NCD loop.
  • the transport session descriptor may be referred to as a multicast list descriptor and may further include the following information.
  • num_multicasts This 16-bit field indicates the number of next multicasts.
  • multicast_stream_id This 16-bit field uniquely identifies an IP/UDP multicast stream within the physical link identified by link_id.
  • source_ip_address This 128-bit field indicates the source IPv6 address of the multicast carried on the physical link identified by link_id.
  • destination_ip_address This 128-bit field indicates the destination IPv6 address of the multicast carried on the physical link identified by link_id.
  • source_port This 16-bit field indicates the source UDP port number of the multicast carried on the physical link identified by link_id.
  • destination_port This 16-bit field indicates the destination UDP port number of the multicast carried on the physical link identified by link_id.
  • header_compression_flag This 1-bit boolean field indicates whether header compression is applied to the multicast stream identified by multicast_stream_id. A value of 0 (zero) indicates that the multicast stream is delivered without header compression in the DVB-GSE layer. A value of 1 (one) indicates that header compression is applied to multicast streams at the DVB-GSE layer. When the value of compressed_flag is equal to 1, the ROHC-U descriptor or ROHC-U_ multicast_descriptor is signaled.
  • reserved_for_future_use This 7-bit field is reserved for future use and all bits must be set to 0.
  • the multicast list descriptor carries a list of multicasts delivered in the physical link.
  • This descriptor delivers a list of IPv4 multicasts delivered in the physical link and provides information for processing UDP/IPv4 packets that deliver multicasts in the DVB-GSE layer.
  • this descriptor delivers a list of IPv6 multicasts delivered in the physical link, and provides information for processing UDP/IPv6 packets carrying multicasts in the DVB-GSE layer.
  • 50 shows a 5G system service infrastructure structure according to embodiments.
  • 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
  • the architecture for the non-roaming case of the 5G system is shown 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.
  • 51 shows a 5G system structure in a reference point representation according to embodiments.
  • 51 shows a 5G system architecture for a non-roaming case using a reference point indicating 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. Therefore, 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 can 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.
  • FIG. 52 shows a 5G system structure for multiple PDU sessions according to embodiments.
  • Figure 51 shows a network structure for supporting two DNs based on the 5G system architecture described above.
  • 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.
  • DNs Data Networks
  • 53 shows a 5G system structure for coexisting access to two data networks according to embodiments.
  • 53 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. 54 .
  • 54 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) over N3 (i.e. between AN and 5GC) or N9 (i.e. between different UPFs on 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 the PDU session anchor in the 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 transfer 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 points for Intra-/Inter-RAT mobility (if applicable).
  • PCF Policy function
  • the policy function may include the following functions.
  • UDR User Data Store
  • 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 55 illustrates Unified Data Management (UDM) according to embodiments.
  • Unified Data Management can be divided into application front end (FE) and User Data Repository (UDR).
  • FE application front end
  • UDR User Data Repository
  • 55 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 represented 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 features:
  • 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 change notifications 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 exposures, 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.
  • 56 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.
  • Other functions and interfaces are additionally described in Annex A.
  • 57 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 systems 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 is 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 outside 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.
  • FIG. 58 shows a reference structure according to embodiments.
  • 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 transmitting content in the above architecture is as follows.
  • interface L can be implemented as a local API.
  • HTTP(S) is obtained from the content hosting function of content not provided through reference point M.
  • 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 through A.
  • This interface can be used to carry payloads used for content recovery functions in addition to requests for these payloads.
  • 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.
  • 59 shows a reference structure according to embodiments.
  • 29 shows a detailed structure of a reference architecture.
  • 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 delivery 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 in 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.
  • 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 interfaces 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. Segment boundaries can be marked using virtual segment boundary markers.
  • 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 the upstream network node instead of the 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 error 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 multiple 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 M interface and unicast operation in 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. have.
  • 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.
  • Content decoding subfunction reads and interprets the contents of elementary media stream, and makes rendering for playback on screen or loudspeaker possible.
  • 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 supplies 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 individual interaction with an application-specific service directory function.
  • the service directory function may be configured by a content provider control function.
  • 60 illustrates a multicast gateway deployment model according to embodiments
  • the multicast gateway function can be implemented in various nodes within the network.
  • Fig. 60 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.
  • 61 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 that 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.
  • FIG. 62 illustrates 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.
  • 63 shows a hybrid broadcast receiving apparatus according to embodiments.
  • the receiving apparatus according to the embodiments may be represented as shown in FIG. 63 .
  • 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 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.
  • 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 in embodiments 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.
  • 64 shows a multicast GSE layer structure according to embodiments.
  • the method apparatus may process a multicast signal through a GSE layer structure for a native IP system.
  • a GSE layer structure may include an upper layer, a GSE layer, and a physical layer.
  • the upper layer can process the data and pass it to the GSE layer.
  • the GSE layer may receive an IP stream from an upper layer.
  • the GSE layer may generate a stream received from an upper layer as a GSE stream.
  • the GSE layer may generate a plurality of GSE streams.
  • the GSE stream generation process may include IP header compression, GSE-LLC descriptor generation, GSE-LLC encapsulation, header compressed ROHC stream encapsulation, header uncompressed IP stream encapsulation, and the like.
  • the IP header may be compressed, or the IP header may not be compressed.
  • the header may be compressed based on the ROHC method, and a ROHC-U descriptor related to header compression may be generated.
  • the ROHC-U descriptor may be encapsulated together with the GSE-LLC descriptor and delivered to the physical layer.
  • the ROHC compressed stream may have a CID of 0 to MAX.
  • IP header compression may be performed based on IP address information and/or port number.
  • the GSE stream may be delivered by the PLP of the physical layer.
  • the GSE stream is delivered by the PLP having the PLP ID.
  • 65 shows a DVB-GSE ROHC profile and a DVB-GSE header compressor according to embodiments.
  • the method/device according to the embodiments may perform ROHC compression according to the DVB Native IP (NIP) standard. Header compression considers using the protocol, and can use the ROUTE/FLUTE protocol over UDP/IP. RTP and ESP can be used. The method/apparatus according to the embodiments may minimize the type of protocol for efficient protocol use.
  • 65 shows a ROHC profile for DVB-GSE according to a profile identifier.
  • the method/apparatus according to the embodiments may support multiple IP streams.
  • the ROHC compressor may perform context re-initialization (CONTEXT_REINITIALIZATION).
  • CONTEXT_REINITIALIZATION A new value of CONTEXT ID (CID) may be assigned to the compressed IP stream.
  • the new CID value may be unique in the system. This unique value may not be used by other ROHC compressors in the system.
  • the ROCH compressor and decompressor according to DVB-GSE may be driven in a unidirectional mode.
  • the adaptation mode corresponds to an additional procedure after the ROHC compressor operation. It is possible to extract a static chain from an IR packet and convert the IR packet into an IR-DYN packet.
  • the signaling data may be delivered through the ROHC compression flow.
  • ROHC parameters may be generated.
  • the maximum value of the maximum CID value MAX_CID may be 127.
  • the number of ROHC streams may be limited.
  • the size of the CID field in the ROHC header may be 1 byte.
  • a method/apparatus may generate a multicast (GSE stream) mapping descriptor.
  • GSE stream multicast mapping descriptor
  • a new multicast mapping descriptor is required.
  • the conventional descriptor cannot support the method of identifying the UDP port for GSE-LLC.
  • a mapping between multicast-link IDs may be provided.
  • the ROHC-U descriptor is a ROHC-U descriptor for multiple streams and UDP, and may be generated as shown in FIG. 66 . Mapping between multicast-ROHC channel-context ID-context information may be indicated.
  • the ROHC-U descriptor may support multiple IP streams.
  • a link represents a virtual network interface on the receiver. It can be associated with exactly one IP flow. Since the same data stream is available on more than one modulation system stream, a link may be associated with a modulation system stream and a ROHC-U information instance specified by a modulation system type, a modulation system ID, and a physical stream ID. For example, it may be specified by a specific PLP in the DVB-T2 system. Because the same data is carried on the link, receivers are free to switch between instances of a particular link.
  • IP Flow A data stream can be delivered on a given link. Because the same data is available from various locations, an IP flow may be associated with one or more links. IP flow can be described by targeting parameters. For example, an IP source and/or destination address may be described. An IP flow may be described by operation parameters such as ROHC-U header compression parameters. A connection between an IP flow and a link can be established by a link ID.
  • the ROUC-U information for the NIP includes information on the number of PLPs for which the number of GSE streams can be known. Includes PLP ID related to ROHC channel ID. Includes CIDmax values and profiles per channel parameter of ROHC. IP stream address information per context ID is included, and ID stream address information includes source IP address, destination IP address, source port information, and destination port information. Context ID and IP stream address information are mapped to each other. Contains context information per context ID. The context information includes static chain length information and static chain byte information.
  • Embodiments may further include NIP specific link layer protocol, layer architecture, selection for ROHC use, bootstrapping procedure in link layer, and the like.
  • IP streams to which ROHC is not applied may be individually delivered. The delivery option may be identified through signaling information.
  • Bootstrapping may receive the GSE stream and filter the requested IP/UDP stream.
  • 67 shows a transmitting apparatus and a receiving apparatus according to the embodiments.
  • the apparatus may include a NIP transmitter and a MIP receiver as shown in FIG. 67 .
  • the NIP transmitter may receive the DVB-I service list from the DVB-I service list server.
  • the GSE stream may be transmitted by the PLP by encapsulating the IP stream including the IP packet.
  • LLC data including a descriptor including information on the GSE layer and a ROHC-U descriptor may be generated and transmitted by the PLP.
  • the NIP transmitter may receive IP multicasts from the multicast server based on the ROUTE session, and may receive an IP stream including multicast gateway configuration information.
  • a ROHC stream may be generated through IP header compression according to embodiments.
  • the NIP receiver may receive the GSE stream and parse the IP stream.
  • a DVB-I service list can be delivered to the DVB-I client. It can filter IP streams and forward IP multicast and multicast gateway configurations to the multicast gateway. Multicast configuration related operations may be processed based on the reference point M interface of MABR.
  • a NIP stream according to embodiments may be the same as a GSE-Lite stream or an MPE stream.
  • the NIP stream is interpreted as a term referring to a stream including IP multicast data delivered by the DVB-NIP broadcasting system.
  • Multicast data transmitted over a broadcast channel is mainly generated by a multicast server, but may also generate a NIP signaling server associated with each NIP stream. Every NIP stream can have only a single multicast server connected to it. Multicast Server can create multicast transport sessions, each consisting of one or more multicast streams.
  • 68 shows a multicast transmission method according to embodiments.
  • a multicast transmission method may include transmitting a multicast signal from a multicast server based on an interface.
  • the multicast transmission method according to the embodiments may further include generating information for multicast.
  • 69 shows a multicast reception method according to embodiments.
  • a multicast reception method may include receiving a multicast signal from a multicast server based on an interface.
  • the multicast reception method according to the embodiments may further include playing a multicast service included in the multicast signal.
  • the multicast processing method according to FIGS. 68-69 may be performed on the multicast ABR structure illustrated in FIGS. 1-4 and the like, based on the flowchart illustrated in FIG. 5 and information for multicast illustrated in FIGS. 6-7 and the like.
  • the multicast processing method according to FIGS. 68-69 may process a multicast signal based on the 5G network illustrated in FIGS. 8-10 and 54-63.
  • the multicast processing method according to FIGS. 68-69 may process a multicast signal based on the plurality of networks illustrated in FIGS. 11-26 and the like.
  • the multicast processing method according to FIGS. 68-69 may process a multicast signal based on a plurality of networks on the protocol and structure illustrated in FIGS. 27-32 and the like.
  • the multicast processing method according to FIGS. 68-69 generates and transmits information for multicast shown in FIGS. 33-36 and the like, and the receiver can receive and reproduce multicast media content based on the information for multicast.
  • the multicast processing method according to FIGS. 68-69 can generate, transmit, and process a multicast signal on the system shown in FIGS. 37-39 and the like.
  • the multicast processing method according to FIGS. 68-69 may include a mapping operation between a multicast transport session and a physical layer.
  • the protocol of FIGS. 42-43 is configured in the structure shown in FIGS. 40-41 and 47, and mapping information for multicast of FIGS. 44-46 and 48-49 is generated. to send and receive
  • the multicast processing method according to FIGS. 68-69 processes multicast through the GSE (link layer) structure of FIG. 64, compresses data of an upper layer as shown in FIGS. 65-66, and generates related link layer signaling information. can transmit
  • the multicast processing method according to Figs. 68-69 generates information indicating the relationship between the GSE and the PLP as shown in Fig. 67, so that the receiving device can receive the multicast signal and reproduce the multicast media data.
  • the interface according to the embodiments may constitute a DVB-NIP standard broadcasting system.
  • a multicast gateway for receiving a multicast signal based on the interface from the multicast server; and a content playback unit that plays a multicast service included in the multicast signal.
  • a multicast signal receiving apparatus comprising: may receive a multicast signal according to a native Internet protocol.
  • the interface of the embodiments is configured according to the DVB-NIP protocol.
  • the interface may include a protocol including a multicast transport session, a User Datagram Protocol/Internet Protocol (UDP/IP), a Generic Stream Encapsulation (GSE) layer, and a physical layer.
  • UDP/IP User Datagram Protocol/Internet Protocol
  • GSE Generic Stream Encapsulation
  • the embodiments may generate the following signaling information, and this information may be variously referred to as signaling information, metadata, ABR transport session descriptor, IP Multicast List descriptor, and the like.
  • Logical Layer Control (LLC) information in the GSE layer is transmitted, and the Logical Layer Control (LLC) information includes a multicast descriptor, and the multicast descriptor includes source address information, destination address information, and source UDP port. information, and may include destination UDP port information.
  • a GSE layer may be defined for DVB-NIP. Examples are GSE data in which IP header compressed IP data is encapsulated from the GSE layer, GSE data in which IP data is encapsulated without IP header compression, a descriptor for multicast, and ROHC (ROHC ( A Physical Layer Pipe (PLP) that delivers a GSE stream including a Robust Header Compression) descriptor may be received.
  • GSE data in which IP header compressed IP data is encapsulated from the GSE layer
  • GSE data in which IP data is encapsulated without IP header compression a descriptor for multicast
  • ROHC ROHC (ROHC ( A Physical Layer Pipe (PLP) that delivers a GSE stream including a Robust Header Compression) descriptor
  • an LLC table for DVB-NIP can be defined.
  • Embodiments receive logical link control (LLC) information from the GSE layer, and the logical link control information includes network control data (NCD) and link control data (LCD). can do.
  • the network control data (NCD) includes a descriptor for multicast
  • the link control data (LCD) includes a link identifier for a physical layer, indicating mapping between sessions and receiving multicast media.
  • embodiments provide a parser that parses Logical Link Control (LLC) information; and a decompressor for receiving a Robust Header Compression (ROHC) stream included in the GSE stream of the GSE layer and decompressing the IP header; may include.
  • LLC Logical Link Control
  • ROHC Robust Header Compression
  • a reception method may include receiving a multicast signal from a multicast server based on an interface; and playing a multicast service included in the multicast signal. may include.
  • a transmission method includes transmitting a multicast signal from a multicast server on the basis of an interface, the interface includes: a multicast transport session, User Datagram Protocol/Internet Protocol (UDP/IP), Generic Stream Encapsulation (GSE) ) layer, including a protocol including a physical layer, and generating a logical layer control (Logical Layer Control, LLC) information in the GSE layer; may include.
  • UDP/IP User Datagram Protocol/Internet Protocol
  • GSE Generic Stream Encapsulation
  • LLC logical layer control
  • 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 configured with one or more processors capable of executing one or more programs, and the one or more programs may execute 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 a volatile memory (eg, RAM, etc.) but also a non-volatile memory, a flash memory, a 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 to 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, the 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 in embodiments 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 wholly or partially applied to a point cloud data transmission/reception device and system.
  • Embodiments may include variations/modifications without departing from the scope of the claims and the like.

Landscapes

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

Abstract

실시예들에 따른 멀티캐스트 신호 수신 장치는 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함할 수 있다. 실시예들에 따른 멀티캐스트 신호 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함할 수 있다.

Description

멀티캐스트 신호 처리 방법 및 장치
본 발명은 멀티캐스트 신호를 처리하는 장치 및 방법에 관한 것이다.
디지털 기술 및 통신 기술의 발전으로 방송, 영화뿐만 아니라 인터넷 및 개인 미디어 등의 다양한 영역에서 오디오/비디오 중심의 멀티미디어 컨텐츠 보급 및 수요가 급속도로 확대되고 있다. 또한, 디스플레이 기술의 발전과 더불어 가정에서의 TV 화면이 대형화 됨에 따라 UHD (Ultra High Definition) 방송 서비스에 대한 논의가 증가되고 있는 추세이다.
방송 서비스와 관련하여, 복수의 사용자에게 동일한 컨텐츠를 전송하는 멀티캐스트 (multicast) 전송 방식은 유니캐스트 (unicast)와 브로드캐스트 (broadcast)의 장점을 모두 활용할 수 있으므로 효과적이다. 하지만, 기존의 멀티캐스트 전송 방식은 단일 네트워크 내에서만 가능했으며 이종망 간의 멀티캐스트 서비스가 불가능한 단점이 있었다. 이로 인해 멀티캐스트 수신 장치가 서로 다른 억세스 네트워크를 접속 및 접속해제하는 경우 기존 멀티캐스트 서비스가 종료된 후 새로운 멀티캐스트 서비스를 시작해야하는 문제점이 있었다. 또한 복수의 전송 프로토콜이 사용되는 경우 IP/UDP 또는 IP/TCP상에서 페이로드를 구성하는 프로토콜이 IANA에 등록되지 경우 포트 넘버를 이용하여 식별하는 것이 불가능하다. IP multicast의 경우 destination address및 port number는 멀티캐스트 에 할당된 값을 사용 하게 되므로, 모든 수신기에서 해당 패킷을 수신 하는데, 이때 알려지지 않은 프로토콜이 사용된 경우 해당 패킷에 대한 멀티캐스트를 처리할 수 없는 문제점이 있다.
본 발명의 목적은, 멀티캐스트 신호를 전송하는 방법 및 장치에 있어서 전송 효율을 높이는 것이다.
또한, 멀티플 네트워크들 간 멀티캐스트 서비스를 효울적으로 제공하는 것이다.
다만, 전술한 기술적 과제만으로 제한되는 것은 아니고, 기재된 전체 내용에 기초하여 당업자가 유추할 수 있는 다른 기술적 과제로 실시예들의 권리범위가 확장될 수 있다.
실시예들에 따른 멀티캐스트 신호 수신 장치는 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함할 수 있다. 실시예들에 따른 멀티캐스트 신호 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함할 수 있다.
본 발명의 실시예에 따르면, 멀티플 네트워크들 간 멀티캐스트 서비스를 제공할 수 있다.
실시예들에 따르면, 복수의 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은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
도7은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
도8은 실시예들에 따른 5G 미디어 스트리밍에 대한 멀티캐스트 적용 방안을 나타낸다.
도9는 실시예들에 따른 멀티캐스트 네트워크 및 통신 네트워크 스트리밍 모두를 위한 멀티태스트 스트리밍 구조를 나타낸다.
도10은 실시예들에 따른 통신 네트워크에서 멀티캐스트 및 브로드캐스트에 기초하여 무선 미디어 전송을 하는 아키텍쳐를 나타낸다.
도11은 실시예들에 따른 각 네트워크에서 멀티캐스트 서버 구성 예시를 나타낸다.
도12는 실시예들에 따른 모든 네트워크들에 대한 멀티캐스트 서버 구성 예시를 나타낸다.
도13은 실시예들에 따른 장치가 접속하는 멀티플 네트워크 예시를 나타내다.
도14는 실시예들에 따른 네트워크 변경에 관한 흐름도를 나타낸다.
도15는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다.
도16은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도17는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다
도18은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도19는 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타내다.
도20은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도21은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 를 구성하는 예시를 나타낸다.
도22는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도23은 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우, 모든 multicast rendezvous service가 co-located deployment 로 구성되는 예시를 나타내다.
도24는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도25는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 실시예를 나타낸다.
도26은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 제공하며, 이에 대한 multicast gateway가 각각의 network 에 구성되는 구조를 나타낸다.
도27은 실시예들에 따른 ABR 멀티캐스트를 위한 프로토콜 구성을 나타낸다.
도28은 실시예들에 따른 복수의 network에 접속하기 위해 수신 장치에 구성될 수 있는 protocol 에 대한 실시 예를 나타낸다.
도29는 실시예들에 따른 프로토콜을 나타낸다.
도30은 실시예들에 따른 서비스 및 서비스에 관한 정보의 구성을 나타낸다.
도31은 실시예들에 따른 ABR 멀티캐스트를 위한 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 전송하는 방법을 나타낸다.
도32는 실시예들에 따른 service list 및 presentation manifest 관리를 나타낸다.
도33은 실시예들에 따른 서비스 리스트를 나타낸다.
도34은 실시예들에 따른 멀티캐스트 세션을 나타낸다.
도35는 실시예들에 따른 HTTP message의 Request URL에 포함되는 엘리먼트를 나타낸다.
도36은 실시예들에 따른 Location response header 의 Redirect URL 에 포함되는 정보를 나타낸다.
도37은 실시예들에 따른 멀티플 컨텐츠 프로바이더를 나타낸다.
도38은 실시예들에 따른 멀티플 서비스 프로바이더를 나타낸다.
도39는 실시예들에 따른 서비스 프로바이더 변경 흐름도를 나타낸다.
도40은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.
도41은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.
도42는 실시예들에 따른 인터페이스 구성을 나타낸다.
도43은 실시예들에 따른 인터페이스 구성을 나타낸다.
도44는 실시예들에 따른 링크 컨트롤 데이터(LCD) 구성을 나타낸다.
도45는 실시예들에 따른 링크 관련 디스크립터를 나타낸다.
도46은 실시예들에 따른 네트워크 컨트롤 데이터(NCD)를 나타낸다.
도47은 실시예들에 따른 멀티캐스트 트랜스포트 세션을 나타낸다.
도48은 실시예들에 따른 mABR IPv6트랜스포트 세션 디스크립터를 나타낸다.
도49는 실시예들에 따른 mABR IPv4트랜스포트 세션 디스크립터를 나타낸다.
도50은 실시예들에 따른 5G 시스템 서비스 기반 구조를 나타낸다.
도51은 실시예들에 따른 레퍼런스 포인트 리프리젠테이션 내 5G 시스템 구조를 나타낸다.
도52는 실시예들에 따른 멀티플 PDU 세션을 위한 5G 시스템 구조를 나타낸다.
도53은 실시예들에 따른 두 가지 데이터 네트워크들에 공존하는 접속을 위한 5G 시스템 구조를 나타낸다.
도54는 실시예들에 따른 유저 플레인 프로토콜 스택을 나타낸다.
도55는 실시예들에 따른 Unified Data Management (UDM) 을 나타낸다.
도56은 실시예들에 따른 5G 미디어 스트리밍을 위한 구조를 나타낸다.
도57은 실시예들에 따른 유니캐스트 다운링크 미디어 스트리밍을 위한 미디어 아키텍처(Media Architecture for unicast downlink media streaming)를 나타낸다.
도58은 실시예들에 따른 레퍼런스 구조를 나타낸다.
도59은 실시예들에 따른 레퍼런스 구조를 나타낸다.
도60은 실시예들에 따른 멀티캐스트 게이트웨이 배포 모델을 나타낸다.
도61는 실시예들에 따른 홈 게이트웨이 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
도62는 실시예들에 따른 단말 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
도63은 실시예들에 따른 하이브리드 방송 수신 장치를 나타낸다.
도64는 실시예들에 따른 멀티캐스트 GSE 레이어 구조를 나타낸다.
도65는 실시예들에 따른 DVB-GSE ROHC(Robust Header Compression) 프로파일 및 DVB-GSE 헤더 컴프레서를 나타낸다.
도66은 실시예들에 따른 ROHC-U 정보를 나타낸다.
도67은 실시예들에 따른 송신 장치 및 수신 장치를 나타낸다.
도68은 실시예들에 따른 멀티캐스트 송신 방법을 나타낸다.
도69는 실시예들에 따른 멀티캐스트 수신 방법을 나타낸다.
실시예들의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 실시예들의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 실시예들의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 실시예들에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 실시예들이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
실시예들에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 실시예들은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
실시예들에 따른 멀티캐스트 신호 처리 방법 및 장치는 멀티캐스트 신호 송신 방법, 수신 방법, 송신 장치, 수신 장치를 포함할 수 있고, 실시예들에 따른 방법/장치로 줄여서 지칭될 수 있다.
실시예들에 따른 방법/장치는 단방향 전송 기반의 Adaptive Bitrate Multicast 네트워크에서 Media 전송 방법에 관한 것이다(Method of Media Delivery in Adaptive Bitrate Multicast Network based on Unidirectional Delivery).
실시예들에 따른 미디어는 미디어 신호, 미디어 데이터 등으로 지칭가능하고, 서비스 또는 서비스 데이터에 대응하거나 서비스를 포함하는 용어로 해석될 수 있다.
실시예들은 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 를 제공 할 수 있다.
실시예들에 따른 방법/장치는 단방향 딜리버리 네트워크(Unidirectional Delivery Network) 에서 적응형 비트레이트 멀티캐스트 미디어(Adaptive Bitrate Multicast media) 전송을 위한 멀티캐스트 트랜스포트 세션 맵핑(Multicast Transport Session mapping) 방법을 제공할 수 있다.
지상파 방송 또는 위성 방송과 같은 Unidirectional delivery network 에서, 기존 ISP network 에 적용을 목적으로 구성된 Adaptive Bitrate Multicast media 전송을 지원 하기 위해, Multicast transport session 을 unidirectional delivery network의 resource 에 mapping 할 수 있다.
Multicast Server 와 Multicast Gateway 사이의 interface에 unidirectional delivery network 가 적용 되어 있는 경우, transparent 한 전송을 지원 할 수 있다.
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 를 기술 한다.
또한, 실시예들에 따른 방법/장치는 DVB 표준에서 정의 하고 있는 지상파 방송 및 위성 방송 link 와 같은 unidirectional delivery network 에서 DVB ABR multicast의 media object를 전송하기 위해 multicast transport session을 broadcast stream 과 연동시키기 위한 interface 및 signaling 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는 실시예들에 따른 멀티캐스트 기반 미디어 수신의 흐름도를 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치(도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>]*]
도6은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
위URL에 포함되는엘리먼트(element)들은 도6과 같다.
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
도7은 실시예들에 따른 URL 에 포함되는 엘리먼트를 나타낸다.
위 URL에 포함되는 엘리먼트들은 도7과 같다.
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 네트워크(통신 네트워크)와 연결될 수 있다.
도8은 실시예들에 따른 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에 해당 할 수 있다.
도9는 실시예들에 따른 멀티캐스트 네트워크 및 통신 네트워크 스트리밍 모두를 위한 멀티태스트 스트리밍 구조를 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 Multicast streaming 이 DVB Multicast ABR network 와 5G Media streaming 에 동시에 서비스 되는 경우, 미디어 컨텐츠를 송수신하고 처리할 수 있다. 도9의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
Multicast streaming 이 서비스 되는 복수의 network 가 존재할 수 있으며, 5G network 가 그 중 하나라고 할 때, 실시예들에 따른 동일한 content provider 로 부터 5G mobile network 와 그 외의 IP network를 통해 동시에 multicast 서비스 되는 유즈 케이스(use case)를 고려할 수 있다. 도9는 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을 동일하게 유지할 수 있다.
도10은 실시예들에 따른 통신 네트워크에서 멀티캐스트 및 브로드캐스트에 기초하여 무선 미디어 전송을 하는 아키텍쳐를 나타낸다.
5G RAN 에서 multicast 및 broadcast 무선 전송이 지원 되는 경우, multicast gateway 가 5G UE 내부에 구성될 수 있다. 도10의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
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 의 적용 방안에 대해 기술한다. 실시예들에 따른 아키텍쳐에 포함된 각 구성요소는 하드웨어, 소프트웨어, 프로세서 및/또는 그것들의 조합에 대응할 수 있다.
도8-10은 도1-6등에 도시된 실시예들에 따른 멀티캐스트 신호 처리 방법/장치에 대응한다.
도11은 실시예들에 따른 각 네트워크에서 멀티캐스트 서버 구성 예시를 나타낸다.
도11은 multicast server 가 각각의 network 마다 구성되어 ABR multicast service를 제공하는 구조에 대한 실시예를 나타낸다. 주로 multicast service server가 network operator 에 의해 deployment 되어 있는 경우에 해당 한다. 실시예들에 따른 송수신 장치는 다음 그림의 멀티캐스트 서버 구조에 기반하여 ABR 멀티캐스트 서비스를 제공할 수 있다. 도11의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
복수의 이종 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이 구성될 수 있다.
도12는 실시예들에 따른 모든 네트워크들에 대한 멀티캐스트 서버 구성 예시를 나타낸다.
단일 Multicast server가 복수의 이종 network를 통해 ABR multicast service를 제공하는 구조에 대한 실시 예를 나타낸다. 주로 multicast service server가 content provider에 의해 deployment 되어 있는 경우에 해당 한다. 실시예들에 따른 송수신 장치는 다음 그림의 멀티캐스트 서버 구조에 기반하여 ABR 멀티캐스트 서비스를 제공할 수 있다.
도12의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
복수의 이종 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이 구성될 수 있다.
도13은 실시예들에 따른 장치가 접속하는 멀티플 네트워크 예시를 나타내다.
실시예들에 따른network 구조에서, 복수의 network 에 접속하여 동일한 multicast media service를 수신 할 수 있는 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 고려할 수 있다. 복수의 network 에 접속하여 동일한 multicast streaming service를 수신 할 수 있는 실시예들에 따른 멀티캐스트 신호 처리 방법/장치에 대한 architecture 및 ABR multicast interface에 대한 실시예에 대해 기술한다. 실시예들은 다양한 아키텍쳐들로 구현될 수 있다.
다음은 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 regular deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도13과 같다. 도13의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른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 의 송수신을 지원 할 수 있다.
도11-13은 도1-6, 도9-10 등 실시예들에 따른 멀티캐스트 신호 처리 장치가 실시예들에 따른 네트워크들 타입에 따라 구성되는 예시를 나타낸다.
다음은 이러한 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다.
실시예들에 따른 네트워크 변경은, 예를 들어, 네트워크A (WI-FI) 및 네트워크B (5G) 간 변경을 포함할 수 있다.
도14은 실시예들에 따른 네트워크 변경에 관한 흐름도를 나타낸다.
도14 흐름도는 도1-5, 8-13 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
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 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가 지속된다.
도15는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타낸다.
실시예들은 도13의 구성에서 더 나아가, 도15과 같이, 네트워크 서버 및 게이트웨이를 포함할 수 있다.
Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, Multicast rendezvous service가 regular deployment 및 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도15과 같다. 도15의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
상기 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 의 송수신을 지원 할 수 있다.
도16은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도16의 흐름도는 도1-5, 8-15 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 architecture에 대해 device가 manifest를 획득하고, multicast media 를 수신 하는 과정에 이어서, network 가 변경된 이후에도 동일한 service를 수신하는 과정에 대한 flow를 나타낸 것이다. 도14와 차이는 도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)에 전달한다.
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가 지속된다.
도17은 실시예들에 따른 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 의 송수신을 지원 할 수 있다.
도18은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도18의 흐름도는 도1-5, 8-17 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 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이 고정되어 있을 수 있다. 수신기가 네트워크 외부에 있을 경우, 단말이 처음 접속 시 미디어 수신을 위해서 접속했으니 미디어를 위한 주소를 단말에 리다이렉션한다. 단말은 리다이렉션 주소를 가지고 실제 미디어를 위한 메니페스트를 받을 수 있다. 멀티캐스트 랑데부 서비스는 미디어 송수신이 멀티캐스트 방식이라서 미디어가 이미 다른 누군가가 보고 있는 미디어라서, 이러한 서비스가 요구된다.
도19는 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 예시를 나타내다.
다음은 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, 모든 multicast rendezvous service가 regular deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도19와 같다. 도19의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른 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 의 송수신을 지원 할 수 있다.
도20은 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도20의 흐름도는 도1-5, 8-19 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 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가 지속된다.
도21은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 를 구성하는 예시를 나타낸다.
다음은 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, Multicast rendezvous service가 regular deployment 및 co-located deployment 로 구성 되어 있는 경우에 대한 실시예를 나타낸 것이다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 도21와 같다. 도21의 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른 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 의 송수신을 지원 할 수 있다.
도22는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도22의 흐름도는 도1-5, 8-21 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 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가 지속된다.
도23은 실시예들에 따른 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 의 송수신을 지원 할 수 있다.
도24는 실시예들에 따른 네트워크 변경 흐름도를 나타낸다.
도24의 흐름도는 도1-5, 8-23 등에 도시된 실시예들에 따라 수행될 수 있다. 실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 실시예들에 따른 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가 지속된다.
다음은 멀티플 네트워크들에 접속 가능한 실시예들에 따른 멀티캐스트 신호 처리 방법/장치를 더 설명한다.
각 네트워크 상에서 멀티캐스트 서버가 위치할 수 있다.
도25는 실시예들에 따른 Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 실시예를 나타낸다.
실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
다음은 앞서 기술한 바와 같이, 앞서 기술한 내용을 바탕으로, Multicast server 및 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 경우에 대한 실시예를 나타낸다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 후술하는 바와 같다.
도26은 실시예들에 따른 단일 multicast server 가 복수의 이종 network 에 대해 service 제공하며, 이에 대한 multicast gateway가 각각의 network 에 구성되는 구조를 나타낸다.
다음은 앞서 기술한 바와 같이, 단일 multicast server 가 복수의 이종 network 에 대해 service 되며, 이에 대한 multicast gateway가 각각의 network 에 구성되어 있는 경우에 대해서, device 가 service 가능한 다양한 network에 접속하는 경우에 대한 실시예를 나타낸다. 실시예들에 따른 시스템은 서비스 프로바이더, 네트워크(들), 디바이스를 포함할 수 있다. 실시예들에 따른 서비스 프로바이더, 네트워크(들), 디바이스의 구성은 다음과 같다.
실시예들을 구성하는 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응한다.
실시예들에 따른 송수신 장치는 실시예들에 따른 동작에 기반하여, DVB Multicast ABR 및 5G media streaming 를 다양한 네트워크 환경에서 효율적으로 제어하고, 제공할 수 있는 효과가 있다.
다음은 실시예들에 따른 수신 동작 및 수신 장치를 위한 동작을 설명한다.
전술한 실시예들에 따른 아키텍쳐들에 대하 다음과 같은 프로토콜이 구현될 수 있다..
실시예들에 따른 기술된 architecture 를 바탕으로, 복수의 전송 network 에 접속 하여 ABR multicast streaming을 수 있는 device를 위해 필요한 element 및 attribute 를 정의 한다.
실시예들에 따른 수신기는 송신기의 동작을 역과정을 수행할 수 있다. 실시예들에 따른 수신기는 이하의 동작에 기반하여 ABR multicast streaming을 수행할 수 있다. 실시예들에 따른 수신기는 이하의 네트워크 구조에 기반하여, ABR multicast streaming을 수행할 수 있다.
다음은 수신 장치들 내 프로토콜 스택들 예시이다.
도27은 실시예들에 따른 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로 구성될 수 있다.
복수의 네트워크들에 접속하기 위해서 실시예들은 다음과 같은 프로토콜들을 포함할 수 있다.
도28은 실시예들에 따른 복수의 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로 전달할 수 있다.
도28은 실시예들에 따른 프로토콜을 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 장치가 수신 장치로 구현될 때, 전술한 실시예들에 따른 아키텍쳐들 상 구현되는 프로토콜을 나타낸다.
실시예들에 따른, 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로 전달할 수 있다.
도29는 실시예들에 따른 프로토콜을 나타낸다.
실시예에서, 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 가 될 수 있다.
다음음 실시예들에 따른 서비스 리스트 및 프리젠테이션 마니페스트를 생성하고 송수신하는 동작을 설명한다.
도30은 실시예들에 따른 서비스 및 서비스에 관한 정보의 구성을 나타낸다.
DASH 기반의 ABR multicast service 에 대해서, 실시예들에 따른 서비스 프로바이더(service provider )는 service list와 함께, 다음과 같이 presentation manifest (ex. MPD)를 구성할 수 있다. Service 를 제공하는 측면에서는 동일한 contents 에 대한 service list 및 presentation manifest 에 대해서는 중복되지 않도록 구성될 수 있다.
도31은 실시예들에 따른 ABR 멀티캐스트를 위한 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 전송하는 방법을 나타낸다.
실시예들에 따른 멀티캐스트 신호 처리 방법/장치는 ABR 멀티캐스트를 지원하기 위해서, 도31과 같이 서비스 리스트 및 프리젠테이션 마니페스를 생성하고, 송수신할 수 있다.
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 정보를 획득할 수 있다.
도32는 실시예들에 따른 service list 및 presentation manifest 관리를 나타낸다.
실시예들에 따른 수신 장치에서 도32와 같이 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 과 같이 관리 될 수 있다.
도33은 실시예들에 따른 서비스 리스트를 나타낸다.
도33은 실시예들에 따른 서비스 리스트의 신택스를 나타낸다.
서비스 리스트(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을 통해 정보를 제공할 수 있다.
도34는 실시예들에 따른 멀티캐스트 세션을 나타낸다.
다음은 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들은 도35와 같다.
도35는 실시예들에 따른 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들은 다음과 같다.
도36은 실시예들에 따른 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는 실시예들에 따른 컨텐츠 프로바이더, 서비스 프로바이더, 네트워크, 디바이스 등을 포함할 수 있다. 각 구성요소는 하드웨어, 소프트웨어, 프로세서, 및/또는 그것들의 조합에 대응할 수 있다. 실시예들에 따른 프로세서는 실시예들에 따른 동작을 수행할 수 있고, 동작에 관한 정보를 저장하는 메모리와 연결될 수 있다.
도37은 실시예들에 따른 멀티플 컨텐츠 프로바이더를 나타낸다.
실시예들에 따른 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 로 대체할 수 있다.
도38은 실시예들에 따른 멀티플 서비스 프로바이더를 나타낸다.
실시예들에 따른 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 로 대체할 수 있다.
도39는 실시예들에 따른 서비스 프로바이더 변경 흐름도를 나타낸다.
다음은 실시예들에 따른 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가 지속된다.
도40은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.
전술한 실시예들에 따른 MABR 아키텍쳐의 네트워크를 통해, 실시예들에 따른 방법/장치는 단방향 딜리버리를 지원할 수 있고, 이를 위한 멀티캐스트 트랜스포트 세션 맵핑 예시를 설명한다.
실시예들에 따른architecture에서 Multicast ABR service provider 가 각각의 network 에 대해 multicast server를 구성하고, multicast gateway, multicast rendezvous service 에 Multicast interface (M) 을 이용하여 multicast contents 및 configuration 정보를 전송한다. 이때, M interface는 uplink channel이 없는 unidirectional network를 통해 구성될 수 있 있으며, 이러한 unidirectional network는 위성 (방송) 네트워크 또는 지상파 방송 네트워크를 고려할 수 있다.
Multicast gateway 및 multicast rendezvous service 에서 수신된 Multicast ABR contents 및 configuration 정보는 L interface에서 제공하는 HTTP 등을 이용하여 content playback function으로 전달될 수 있으며, multicast gateway 가 Home Broadcasting (HB) network 의 server로 동작할 수 있다.
Device 또는 HB network내의 content playback function에는 L interface 및 B interface 가 구성 될 수 있다. L interface 를 통해 multicast gateway 를 통한 media streaming 을 수신할 수 있으며, B interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway 와 multicast rendezvous service 가 동일한 장치 내에 구성 되는 경우에는 L interface 및 B interface는 device 내부 interface 로 대체할 수 있다.
Service 에 대한 접속 정보 (URI 등) 를 알려줄 수 있는 service list는 content provider로부터 service list registry에 전달된 후, service list registry에서는 관리하고 있는 service list 정보를 multicast service 로 전달 할 수 있으며, multicast server 는 M interface를 통해 multicast gateway로 전달할 수 있다.
도41은 실시예들에 따른 유니다이렉셔널 딜리러비를 위한 MABR 네트워크 구성을 나타낸다.
실시예들에 따른architecture에서는 Multicast ABR service provider 가 단일 multicast server를 구성하고, multicast gateway, multicast rendezvous service 에 동일한 Multicast interface (M) 을 이용하여 동일한 multicast contents 및 configuration 정보를 전송한다. 이때, M interface는 uplink channel이 없는 unidirectional network를 통해 구성될 수 있 있으며, 이러한 unidirectional network는 위성 (방송) 네트워크 또는 지상파 방송 네트워크를 고려할 수 있다.
Multicast gateway 및 multicast rendezvous service 에서 수신된 Multicast ABR contents 및 configuration 정보는 L interface에서 제공하는 HTTP 등을 이용하여 content playback function으로 전달될 수 있으며, multicast gateway 가 Home Broadcasting (HB) network 의 server로 동작할 수 있다.
Device 또는 HB network내의 content playback function에는 L interface 및 B interface 가 구성 될 수 있다. L interface 를 통해 multicast gateway 를 통한 media streaming 을 수신할 수 있으며, B interface를 통해 초기 multicast gateway 에 대한 접속 정보를 수신 할 수 있다. 여기에서, Multicast gateway 와 multicast rendezvous service 가 동일한 장치 내에 구성 되는 경우에는 L interface 및 B interface는 device 내부 interface 로 대체할 수 있다.
Service 에 대한 접속 정보 (URI 등) 를 알려줄 수 있는 service list는 content provider로부터 service list registry에 전달된 후, service list registry에서는 관리하고 있는 service list 정보를 multicast service 로 전달 할 수 있으며, multicast server 는 M interface를 통해 multicast gateway로 전달 할 수 있다.
도42는 실시예들에 따른 인터페이스 구성을 나타낸다.
도41 등 실시예들에 따른 M인터페이스 구성은 다음과 같다.
Unidirectional link 가 포함된 M interface 에 기반하여, 실시예들에 따른 방법/장치는 단방향 딜리버리를 수행할 수 있다. 이 경우, unidirectional 는 satellite channel로 구성되는 것을 고려할 수 있으며, physical layer는 DVB-S2 또는 DVB-S2X 로 구성될 수 있으며, data link layer는 DVB-GSE로 구성될 수 있다.
Multicast server 는 M interface에 정의된 protocol을 통해 multicast gateway 로 multicast transport session을 전송하면, satellite transmitter 가 이를 수신 하여 satellite channel을 통해 satellite receiver로 전송한다. Satellite receiver는 이를 다시 M interface에 정의 된 protocol 그대로 multicast gateway로 전달한다. 이때, multicast transport session 이 satellite channel로 전송될 때, 단일 signaling로 multiplexing 될 수 있으며, 해당 multicast transport session을 de-multiplexing 하여 multicast gateway로 전달 되기 위해서, satellite channel을 통해 전송되는 IP multicast에 해당하는 multicast transport session을 mapping 해 줄 수 있다. 이때, multicast transport session을 mapping 하기 위해 data link layer signaling 을 이용할 수 있다.
도43은 실시예들에 따른 인터페이스 구성을 나타낸다.
Unidirectional link 가 포함된 M interface 에 기반하여, 실시예들에 따른 방법/장치는 단방향 딜리버리를 수행할 수 있다. 이 경우, unidirectional 는 broadcast channel로 구성되는 것을 고려할 수 있으며, physical layer는 DVB-T2 로 구성될 수 있으며, data link layer는 DVB-GSE로 구성될 수 있다.
Multicast server 는 M interface에 정의된 protocol을 통해 multicast gateway 로 multicast transport session을 전송하면, broadcast transmitter 가 이를 수신 하여 broadcast channel을 통해 broadcast receiver로 전송한다. Broadcast receiver는 이를 다시 M interface에 정의 된 protocol 그대로 multicast gateway로 전달한다. 이때, multicast transport session 이 broadcast channel로 전송될 때, 단일 signaling로 multiplexing 될 수 있으며, 해당 multicast transport session을 de-multiplexing 하여 multicast gateway로 전달 되기 위해서, broadcast channel을 통해 전송되는 IP multicast에 해당하는 multicast transport session을 mapping 해 줄 수 있다. 이때, multicast transport session을 mapping 하기 위해 data link layer signaling 을 이용할 수 있다.
실시예들에 따른 DVB-I 서비스 리스트에 ETSI TS 103 285에 따른 DVB-DASH 기반 서비스가 포함될 수 있다. DVB-NIP의 DVB-DASH 기반 서비스는 ETSI TS 103 769에 정의된 DVB 방송 네트워크를 통해 DVB-MABR 정의 FLUTE/ROUTE 프로토콜을 사용하여 전달될 수 있다.
시그널링 및 A/V 서비스(DVB-DASH ETSI TS 103 285 사용)는 IP 멀티캐스트를 통해 브로드캐스트 RF 채널에서 전달된다. DVB-NIP IP 멀티캐스트 세션은 ETSI TS 102 606-1의 D.2 절에 정의된 GSE-Lite 프로파일 또는 데이터 링크 계층에서 ETSI EN 301 192에 정의된 다중 프로토콜 캡슐화를 사용하여 전달된다. 또한, DVB-S2X(ETSI 302 307-1, ETSI 302 307-2), DVB-S2(ETSI 302 307-1) 및 DVB-T2(ETSI TS 102 755) 물리 계층이 결합될 수 있다.
도44는 실시예들에 따른 링크 컨트롤 데이터(LCD) 구성을 나타낸다.
실시예들에 따른 멀티캐스트 트랜스포트 세션 맵핑을 위한 논리적 레이어 컨트롤 구조에 기반하여, 실시예들에 따른 방법/장치는 단방향 딜리버리를 수행할 수 있다.
GSE-LLC 구조
실시예들에 따른 M interface에 대한 구성에서, multicast transport session을 mapping 하기 위해 data link layer signaling을 이용하는 방법에 대한 실시 예로 DVB-GSE LLC (Logical Layer Control) 을 사용한다.
DVB-GSE LLC 는 Link Control Data (LCD)와 Network Control Data (NCD) 로 구성되 구성된다.
LCD 의 syntax는 도44와 같이 구성될 수 있다.
PHY_descriptors() - Physical layer의 modulation system 에 대한 descriptor이다.
number_of_links - Physical layer의 modulation system에 포함되는 link 또는 physical stream 의 개수를 나타낸다.
link_id - Physical layer의 modulation system에 포함되는 physical link 에 대한 식별자이다.
link_association_descriptors()는 다음과 같이 구성될 수 있다.
도45는 실시예들에 따른 링크 관련 디스크립터를 나타낸다.
modulation_system_type - broadcast modulation system의 type에 대해 나타낸다. 예를 들어, 다음과 같이 encoding 될 수 있다.
0x00 - DVB-S2/S2X
0x01 - DVB-T2
modulation_system_id - modulation system에 대한 고유의 식별자이다.
PHY_stream_id - modulation_system_type 에 따라 다음과 같이 encoding 될 수 있다.
modulation_system_type = 0x00 인 경우 - DVB-S2/S2X 의 Input Stream Identifier (ISI)
modulation_system_type = 0x01 - DVB-T2의 Physical layer pipe
NCD 는 다음과 같이 구성될 수 있다.
도46은 실시예들에 따른 네트워크 컨트롤 데이터(NCD)를 나타낸다.
NCD 구조에서, platform_descriptor(), target_descriptor(), operational_descriptor는 각각의 signaling 용도에 맞게 정의할 수 있다.
target_descriptors() 와 관련하여, GSE가 IP 어드레스정보만 있으면, 실시예들에 따른 멀티캐스트를 처리할 수 있다. 따라서, 실시예들에 따른 target_descriptors()은 멀티캐스트 식별을 위한 정보를 포함하여, 문제를 해결할 수 있다.
NCD 구조에서, platform_descriptor(), target_descriptor(), operational_descriptor는 각각의 signaling 용도에 맞게 정의할 수 있다.
도47은 실시예들에 따른 멀티캐스트 트랜스포트 세션을 나타낸다.
실시예들에 따른 방법/장치는 멀티캐스트 트랜스포트 세션에 기반하여 트랜스포트 세션 맵핑을 수행할 수 있다.
Multicast server에서 전송되는 multicast transport session은 도47과 같이 정의 될 수 있다.
Multicast server에서 전송되는 multicast transport session은 unidirectional delivery transmitter (satellite transmitter) 에서 IP multicast stream으로 mapping 되며, IP multicast stream 정보를 unidirectional delivery receiver (satellite receiver) 로 전송할 수 있다.
도48은 실시예들에 따른 mABR IPv6트랜스포트 세션 디스크립터를 나타낸다.
실시예들에 따른 방법/장치가 Multicast transport session를 IPv6를 통해 전송하는 경우 도48과 같은 descriptor 를 target descriptor에 포함시킬 수 있다.
descriptor_tag - descriptor 에 대한 식별자에 해당한다.
descriptor_length - 해당 descriptor에 대한 길이를 나타낸다.
multicast_transport_session_id_length - 뒤에 나타나는 multicast_transport_session_id에 대한 길이를 byte 단위로 나타낸다.
multicast_transport_session_id - multicast transport session에 대한 고유의 식별자로, Multicast ABR session configuration에 포함되어 있는 id 값과 동일한 값을 가진다.
source_IPv6_address - IPv6로 전송되는 현재 multicast transport session 에 대한 source IP address를 나타낸다.
destination_IPv6_address - IPv6로 전송되는 현재 multicast transport session 에 대한 group (desdination) IP address를 나타낸다.
source_UDP_port - 현재 multicast transport session에 대한 source UDP port를 나타낸다.
destination_UDP_port - 현재 multicast transport session에 대한 destination UDP port를 나타낸다.
GSE 관련 디스크립터에 source_UDP_port 및 destination_UDP_port를 추가로 정의함으로써, 실시예들에 따른 방법/장치는 멀티캐스트를 지원할 수 있다.
또한, 트랜스포트 세션 디스크립터는 멀티캐스트 리스트 디스크립터로 지칭될 수 있고, 다음 정보를 더 포함할 수 있다.
num_multicasts: 이 16비트 필드이고, 멀티캐스트의 개수를 나타낸다.
multicast_stream_id: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크 내에서 IP/UDP 멀티캐스트 스트림을 고유하게 식별한다.
source_ip_address: 이 32비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 IPv4 주소를 나타낸다.
destination_ip_address: 이 32비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 IPv4 주소를 나타낸다.
source_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 UDP 포트 번호를 나타낸다.
destination_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 UDP 포트 번호를 나타낸다.
header_compression_flag: 이 1비트 부울 필드는 헤더 압축이 multicast_stream_id에 의해 식별되는 멀티캐스트 스트림에 적용되는지 여부를 나타낸다. 값 0(영)은 멀티캐스트 스트림이 DVB-GSE 계층에서 헤더 압축 없이 전달됨을 나타낸다. 값 1(일)은 헤더 압축이 DVB-GSE 계층의 멀티캐스트 스트림에 적용됨을 나타낸다. compressed_flag의 값이 1과 같을 때 ROHC-U 디스크립터 또는 ROHC-U_ multicast_descriptor가 시그널링된다.
reserved_for_future_use: 이 7비트 필드는 향후 사용을 위해 예약되어 있으며 모든 비트는 0으로 설정되어야 한다.
도49는 실시예들에 따른 mABR IPv4트랜스포트 세션 디스크립터를 나타낸다.
실시예들에 따른 방법/장치는 Multicast transport session을 IPv4를 통해 전송하는 경우 도49과 같은 descriptor 를 target descriptor에 포함시킬 수 있다.
descriptor_tag - descriptor 에 대한 식별자에 해당한다.
descriptor_length - 해당 descriptor에 대한 길이를 나타낸다.
multicast_transport_session_id_length - 뒤에 나타나는 multicast_transport_session_id에 대한 길이를 byte 단위로 나타낸다.
multicast_transport_session_id - multicast transport session에 대한 고유의 식별자로, Multicast ABR session configuration에 포함되어 있는 id 값과 동일한 값을 가진다.
source_IPv6_address - IPv4로 전송되는 현재 multicast transport session 에 대한 source IP address를 나타낸다.
destination_IPv6_address - IPv4로 전송되는 현재 multicast transport session 에 대한 group (desdination) IP address를 나타낸다.
source_UDP_port - 현재 multicast transport session에 대한 source UDP port를 나타낸다.
destination_UDP_port - 현재 multicast transport session에 대한 destination UDP port를 나타낸다.
복수의 multicast transport session을 단일 link로 mapping 하는 경우에는 NCD loop 내에 복수의 mABR_IPv6_transport_session_descriptor () 또는 mABR_IPv4_transport_session_descriptor () 를 포함 시킬 수 있다.
트랜스포트 세션 디스크립터는 멀티캐스트 리스트 디스크립터로 지칭될 수 있고, 하기 정보를 더 포함할 수 있다.
num_multicasts: 이 16비트 필드는 다음 멀티캐스트의 개수를 나타낸다.
multicast_stream_id: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크 내에서 IP/UDP 멀티캐스트 스트림을 고유하게 식별한다.
source_ip_address: 이 128비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 IPv6 주소를 나타낸다.
destination_ip_address: 이 128비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 IPv6 주소를 나타낸다.
source_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 소스 UDP 포트 번호를 나타낸다.
destination_port: 이 16비트 필드는 link_id에 의해 식별되는 물리적 링크에서 운반되는 멀티캐스트의 목적지 UDP 포트 번호를 나타낸다.
header_compression_flag: 이 1비트 부울 필드는 헤더 압축이 multicast_stream_id에 의해 식별되는 멀티캐스트 스트림에 적용되는지 여부를 나타낸다. 값 0(영)은 멀티캐스트 스트림이 DVB-GSE 계층에서 헤더 압축 없이 전달됨을 나타낸다. 값 1(일)은 헤더 압축이 DVB-GSE 계층의 멀티캐스트 스트림에 적용됨을 나타냅니다. compressed_flag의 값이 1과 같을 때 ROHC-U 디스크립터 또는 ROHC-U_ multicast_descriptor가 시그널링된다.
reserved_for_future_use: 이 7비트 필드는 향후 사용을 위해 예약되어 있으며 모든 비트는 0으로 설정되어야 한다.
도48-49 멀티캐스트 리스트 디스크립터는 피지컬 링크 내 전달되는 멀티캐스트의 리스트를 전달한다. 이 디스트립터는 피지컬 링크 내 전달되는 IPv4 멀티캐스트의 리스트를 전달하고, DVB-GSE 레이어 내 멀티캐스트를 전달하는 UDP/IPv4 패킷들을 처리하기 위한 정보를 제공한다. 또한, 이 디스크립터는 피지컬 링크 내 전달되는 IPv6 멀티캐스트의 리스트를 전달하고, DVB-GSE 레이어 내 멀티캐스트를 전달하는 UDP/IPv6 패킷들을 처리하기 위한 정보를 제공한다.
도50은 실시예들에 따른 5G 시스템 서비스 기반 구조를 나타낸다.
실시예들에 따른 방법/장치는 다음과 같이 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).
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.
도51은 실시예들에 따른 레퍼런스 포인트 리프리젠테이션 내 5G 시스템 구조를 나타낸다.
도51은 여러 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를 식별 할 수 있다.
도52는 실시예들에 따른 멀티플 PDU 세션을 위한 5G 시스템 구조를 나타낸다.
도51는 앞서 기술한 5G system architecture를 기반으로, 두개의 DN을 지원 하기 위한 network 구조를 나타낸다. 하나의 DN이 접속되기 위해서는 해당 DN에 대한 UPF 및 SMF 가 별도로 구성될 수 있고, 이 function은 또한 각각 control plane function과 해당 reference point를 통해 연결될 수 있다. 따라서, 각각의 DN은 별도의 PDU session을 제공하게 되고 SMF가 해당 session을 제어할 수 있다.
도52에서는 동시에 두 개의 DN (Data Network) 에 접속 되는 것을 나타내고 있으나 network 구성에 따라 두개 이상의 DN과 접속될 수 있다.
도53은 실시예들에 따른 두 가지 데이터 네트워크들에 공존하는 접속을 위한 5G 시스템 구조를 나타낸다.
도53은 하나의 PDU 세션 옵션을 따를 수 있다.
도53은 두 개의 DN에 접속되어 있는 구조에서 단일 SMF를 이용하여 각각의 DN에서 제공하는 PDU session이 단일 session으로 동작할 수 있게 구성된 network architecture 이다.
이러한 network 구조에 대해, 하나의 PDU session에 대한 User Plane Protocol stack 은 도54와 같이 정의 될 수 있다.
도54는 실시예들에 따른 유저 플레인 프로토콜 스택을 나타낸다.
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 인스턴스 및 지원 서비스에 대한 정보를 유지 관리한다.
도55는 실시예들에 따른 Unified Data Management (UDM) 을 나타낸다.
Unified Data Management (UDM)는 application front end (FE) 와User Data Repository (UDR)로 나눌 수 있다.
도55는 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를 통해 외부 노출 프레임워크를 사용해야 한다.
도56은 실시예들에 따른 5G 미디어 스트리밍을 위한 구조를 나타낸다.
5G 시스템 내 5G 다운링크 미디어 스트리밍(5G Downlink Media Streaming within the 5G System)
도56은 5G network내에 downlink media streaming을 위한 function이 구성되어 있는 구조를 나타낸다.
5670 구조에서, 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에 추가로 기술되어 있다.
도57은 실시예들에 따른 유니캐스트 다운링크 미디어 스트리밍을 위한 미디어 아키텍처(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와 연계될 수 있다.
도58은 실시예들에 따른 레퍼런스 구조를 나타낸다.
참조 포인트(REFERENCE POINTS):
도58의 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: 콘텐츠 재생 기능에 의해 콘텐츠 제공자 메트릭 보고 캡처 기능에 대한 재생 메트릭 보고.
도59은 실시예들에 따른 레퍼런스 구조를 나타낸다.
참조 아키텍처 다이어그램(REFERENCE ARCHITECTURE DIAGRAM):
도29는 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에 의해 구성될 수 있다.
도60은 실시예들에 따른 멀티캐스트 게이트웨이 배치 모델을 나타낸다.
앞서 기술한 Multicast ABR architecture에서 Multicast gateway 의 기능은 network 내에서 다양한 node에 구현될 수 있다. 도60은 네트워크 에지 장치에 배포된 멀티캐스트 게이트웨이를 도시한다.
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가 된다.
도61는 실시예들에 따른 홈 게이트웨이 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
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이 설치되어 있다.
도62는 실시예들에 따른 단말 장치에 배포된 멀티캐스트 게이트웨이 구조를 나타낸다.
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를 지원하지 않을 때, 예측 불가능한 품질 변화가 일어날 수 있다.
도63은 실시예들에 따른 하이브리드 방송 수신 장치를 나타낸다.
실시예들에 따른 수신 장치는 도63과 같이 표현될 수 있다. 실시예들에 따른 수신 장치의 각 구성요소는 하드웨어, 소프트웨어, 프로세서 및/또는 그것들의 조합에 대응할 수 있다.
각 약어의 정의는 다음과 같다: 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).
상술한 실시예들에 따른 장치는 실시예들에 따른 동작/구성 및/또는 시그널링 정보에 기초하여, 방송 및 multicast 전송에 있어서 다양한 network 를 효율적으로 활용할 수 있는 효과가 있다.
나아가, 상술한 실시예들에 따른 방법/장치는 다양한 네트워크 및/또는 디바이스와 연계하여, 다양한 스트리밍 세션에서 네트워크의 부하를 감소시키고, 구현 비용을 감소시키고, ABR Multicast service를 효율적으로 제공할 수 있는 효과가 있다. 이러한 효과를 제공하기 위해서, 실시예들에 따른 architecture 및 flow가 요구된다.
한편, 본 문서에서 설명하는 실시예들에 따른 동작은 실시예들에 따라서 메모리 및/또는 프로세서를 포함하는 송수신 장치에 의해 수행될 수 있다. 메모리는 실시예들에 따른 동작을 처리/제어하기 위한 프로그램들을 저장할 수 있고, 프로세서는 본 문서에서 설명한 다양한 동작을 제어할 수 있다. 프로세서는 컨트롤러 등으로 지칭 가능하다. 실시예들에 동작들은 펌웨어, 소프트웨어, 및/또는 그것들의 조합에 의해 수행될 수 있고, 펌웨어, 소프트웨어, 및/또는 그것들의 조합은 프로세서에 저장되거나 메모리에 저장될 수 있다.
도64는 실시예들에 따른 멀티캐스트 GSE 레이어 구조를 나타낸다.
실시예들에 따른 방법 장치는 네이티브 IP 시스템을 위한 GSE 레이어 구조를 통해 멀티캐스트 신호를 처리할 수 있다.
실시예들에 따른 GSE 레이어 구조는 상위 레이어(upper layer), GSE layer, 피지컬 레이어를 포함할 수 있다.
상위 레이어는 데이터를 처리하여 GSE 레이어로 전달할 수 있다. GSE레이어는 상위 레이어로부터 IP 스트림을 수신할 수 있다.
GSE레이어는 상위 레이어로부터 수신한 스트림을 GSE 스트림으로 생성할 수 있다. GSE레이어는 복수의 GSE스트림들을 생성할 수 있다. GSE 스트림 생성 과정은 IP헤더 컴프레션, GSE-LLC 디스크립터 생성, GSE-LLC 인캡슐레이션, 헤더 압축된 ROHC 스트림의 인캡슐레이션, 헤더 압축되지 않은 IP스트림의 인캡슐레이션 등을 포함할 수 있다.
상위 레이어로부터 IP데이터를 수신하여, IP 헤더를 압축할 수 있고, IP헤더를 압축하지 않을 수 있다. IP헤더를 압축하는 경우 ROHC 방식에 기초하여 헤더를 압축하고, 헤더 압축에 관한 ROHC-U 디스크립터를 생성할 수 있다. ROHC-U 디스크립터는 GSE-LLC 디스크립터와 함께 인캡슐레이션되어 피지컬 레이어로 전달될 수 있다. ROHC압축된 스트림은 CID 0내지 MAX값을 가질 수 있다. IP헤더 압축은 IP어드레스 정보 및/또는 포트 넘버에 기반하여 수행될 수 있다.
GSE스트림은 피지컬 레이어의 PLP에 의해 전달될 수 있다. PLP ID를 가지는 PLP에 의해 GSE스트림이 전달된다.
도65는 실시예들에 따른 DVB-GSE ROHC 프로파일 및 DVB-GSE 헤더 컴프레서를 나타낸다.
GSE-ROHC(102 606-3)
실시예들에 따른 방법/장치는 NIP (DVB Native IP) 규격에 따른 ROHC 압축을 수행할 수 있다. 헤더 컴프레션은 프로토톨 사용을 재고려하고, UDP/IP 상 ROUTE/FLUTE 프로토톨을 이용할 수 있다. RTP 및 ESP를 사용할 수 있다. 실시예들에 따른 방법/장치는 효율적은 프로토콜 사용을 위해 프로토콜의 타입을 최소화할 수 있다. 도65는 프로파일 식별자에 따라, DVB-GSE를 위한 ROHC 프로파일을 나타낸다.
실시예들에 따른 방법/장치는 멀티플IP스트림을 지원할 수 있다. 수신한 IP스트림의 스태틱 필드 내 변화가 ROHC 컴프레서에 의해 감지되는 경우, ROHC 컴프레서는 컨텍스트 리-이니셜라이제이션)(CONTEXT_REINITIALIZATION)을 수행할 수 있다. CONTEXT ID(CID)의 새로운 값이 압축된 IP스트림에 할당될 수 있다. 새로운 CID값은 시스템에서 유니크할 수 있다. 이 유니크한 값은 시스템 내 다른 ROHC 컴프레서에서 사용되지 않을 수 있다.
DVB-GSE에 따른 ROCH컴프레서 및 디컴프레서는 단방향(unidirectional) 모드 내에서 구동될 수 있다.
도65를 참조하면, 어댑테이션 모드는 ROHC 컴프레서 동작 이후 추가적인 절차에 해당한다. IR패킷으로부터 스태틱 체인을 추출하고, IR패킷을 IR-DYN 패킷으로 변환활 수 있다. 시그널링 데이터는 ROHC 컴프레션 플로우를 통해 전달될 수 있다.
어댑테이션 모드를 적용할지 여부를 선택할 수 있다. 시그널링 데이터의 에러에 강한 전송으로 인해서컨텍스트 정보의 개별적 전송은 멀티플 PLP 구조 내에서 유용할 수 있다. 어댑테이션 모드를 사용하는 것이 유익하지 않은 경우도 있다. 컨텍스트 데이터 및 대응하는 ROHC플로우가 동일한 PLP에 의해 전송되는 경우이다.
ROHC파라미터들이 생성될 수 있다. CID최대값(MAX_CID)의 최대 값은 127일 수 있다. ROHC스트림의 개수가 제한될 수 있다. ROHC헤더 내 CID필드의 사이즈는 1바이트일 수 있다.
도66은 실시예들에 따른 ROHC-U 정보를 나타낸다.
GSE-LLC(102 606-2)
실시예들에 따른 방법/장치는 멀티캐스트 (GSE 스트림) 매핑 디스트립터를 생성할 수 있다. 멀티캐스트 맵핑 디스크립터가 새롭게 요구된다. 종래 디스크립터는 GSE-LLC 에 대해 UDP 포트를 식별하는 방안을 지원할 수 없다. 멀티캐스트-링크ID(GSE스트림ID) 간 맵핑을 제공할 수 있다.
ROHC-U디스크립터는 멀티플 스트림 및 UDP 를 위한 ROHC-U 디스크립터다 도66과 같이 생성될 수 있다. 멀티캐스트-ROHC채널-컨텍스트ID-컨탠스트정보 간 맵핑을 나타낼 수 있다.
실시예들에 따른 ROHC-U디스크립터는 멀티플 IP스트림을 지원할 수 있다.
링크는 수신기 상 가상 네트워크 인터페이스를 나타낸다. 이는 정확히 하나의 IP플로우와 연관될 수 있다. 동일한 데이터 스트림이 하나 이상의 모듈레이션 시스템 스트림 상 이용가능하기 때문에, 링크는 모듈레이션 시스템 타입, 모듈레이션 시스템 ID, 피지컬 스트림ID에 의해 특정되는 모듈레이션 시스템 스트림과 ROHC-U 정보 인스턴스가 연관될 수 있다. 예를 들어, DVB-T2시스템 내 특정 PLP 에 의해 특정될 수 있다. 링크 상 동일한 데이터가 전달되기 때문에, 수신기들은 특정 링크의 인스턴스 간 자유롭게 스위칭을 수행할 수 있다.
IP플로우: 주어진 링크 상 데이터 스트림이 전달도리 수 있다. 동일한 데이터가 다양한 위치로부터 이용 가능하기 때문에, IP플로우는 하나 이상의 링크들과 연관될 수 있다. IP플로우는 파라미터들을 타겟팅하여 기술될 수 있다. 예를 들어, IP 소스 및/또는 목적 어드레스를 기술할 수 있다. ROHC-U 헤더 컴프레션 파라미터들과 같은 오퍼레이션 파라미터들에 의해 IP플로우가 기술될 수 있다. IP플로우 및 링크 간 연결은 링크 아이디에 의해서 성립될 수 있다.
NIP를 위한 ROUC-U정보는 GSE스트림들의 개수를 알 수 있는 PLP개수 정보를 포함한다. ROHC채널 ID에 관련된 PLP ID를 포함한다. ROHC의 채널 파라미터 당 CID맥스 값 및 프로파일을 포함한다. 컨텍스트 ID당 IP스트림 어드레스 정보를 포함하고, ID 스트림 어드레스 정보는 소스 IP어드레스, 목적지 IP어드레스, 소스 포트 정보, 목적지 포트 정보를 포함한다. 컨텍스트 ID 및 IP스트림 어드레스 정보는 서로 매핑된다. 컨텍스트ID당 컨텍스트 정보를 포함한다. 컨텍스트 정보는 스태틱 체인 길이 정보 및 스태틱 체인 바이트 정보를 포함한다.
실시예들은 NIP 특정 링크 레이어 프로토콜, 레이어 아키텍쳐, ROHC 사용을 위한 선택, 링크 레이어 내 부트스트랩핑 절차 등을 더 포함할 수 있다. ROHC가 적용되지 않은 IP스트림은 개별적으로 전달될 수 있다. 전달 옵션은 시그널링 정보를 통해 식별할 수 있다. 부트스트랩핑은 GSE스트림을 수신하고, 요청된 IP/UDP스트림을 필터링할 수 있다.
도67은 실시예들에 따른 송신 장치 및 수신 장치를 나타낸다.
실시예들에 따른 장치는 도67과 같이 NIP트랜스미터 및 MIP리시버 등을 포함할 수 있다.
NIP트랜스미터는 DVB-I 서비스 리스트 서버로부터 DVB-I 서비스 리스트를 수신할 수 있다. IP 패킷을 포함하는 IP스트림을 인캡슐레이션하여 GSE스트림을 PLP에 의해 전송할 수 있다. GSE레이어에 대한 정보를 포함하는 디스크립터 및 ROHC-U 디스크립터 등을 포함하는 LLC 데이터를 생성하여 PLP에 의해 전송할 수 있다.
NIP트랜스미터는 멀티캐스트 서버로부터 ROUTE 세션에 기반하여 IP멀티캐스트들을 수신할 수 있고, 멀티캐스트 게이트웨이 구성 정보를 포함하는 IP스트림을 수신할 수 있다. 실시예들에 따른 IP헤더 압축을 통해 ROHC스트림을 생성할 수 있다.
NIP리시버는 GSE스트림을 수신하고, IP스트림을 파싱할 수 있다. DVB-I클라이언트에 DVB-I서비스 리스트를 전달할 수 있다. IP 스트림을 필터링하고, IP 멀티캐스트, 멀티캐스트 게이트웨이 구성들을 멀티캐스트 게이트웨이에 전달할 수 있다. 멀티캐스트 구성 관련 동작은 MABR의 참조 포인트M 인터페이스에 기반하여 처리될 수 있다.
실시예들에 따른 NIP 스트림은 GSE-Lite 스트림 또는 MPE 스트림과 동일할 수 있다. NIP 스트림은 DVB-NIP 방송 시스템이 전달하는 IP멀티캐스트 데이터를 포함하는 스트림을 지칭하는 용어로 해석된다.
브로드캐스트 채널을 통해 전송되는 멀티캐스트 데이터는 주로 멀티캐스트 서버에 의해 생성되지만 각 NIP 스트림과 관련된 NIP 신호 서버도 생성할 수 있다. 모든 NIP 스트림에는 연결된 단일 멀티캐스트 서버만 있을 수 있다. Multicast Server는 각각 하나 이상의 멀티캐스트 스트림으로 구성된 멀티캐스트 전송 세션을 생성할 수 있다.
도68은 실시예들에 따른 멀티캐스트 송신 방법을 나타낸다.
S6800, 실시예들에 따른 멀티캐스트 송신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여 멀티캐스트 신호를 송신하는 단계를 포함할 수 있다.
S6810, 실시예들에 따른 멀티캐스트 송신 방법은 멀티캐스트를 위한 정보를 생성하는 단계를 더 포함할 수 있다.
도69는 실시예들에 따른 멀티캐스트 수신 방법을 나타낸다.
S6900, 실시예들에 따른 멀티캐스트 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계를 포함할 수 있다.
S6910, 실시예들에 따른 멀티캐스트 수신 방법은 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계를 더 포함할 수 있다.
도68-69에 따른 멀티캐스트 처리 방법은 도1-4 등 도시된 멀티캐스트 ABR 구조 상에서 도5등 도시된 흐름도, 도6-7 등 도시된 멀티캐스트를 위한 정보 등에 기초하여 수행될 수 있다.
도68-69에 따른 멀티캐스트 처리 방법은 도8-10, 54-63 등 도시된 5G 네트워크에 기반하여 멀티캐스트 신호를 처리할 수 있다.
도68-69에 따른 멀티캐스트 처리 방법은 도11- 26등 도시된 복수의 네트워크들에 기반하여 멀티캐스트 신호를 처리할 수 있다.
도68-69에 따른 멀티캐스트 처리 방법은 도27- 32등 도시된 프로토콜 및 구조 상에서 복수의 네트워크들에 기초하여 멀티캐스트 신호를 처리할 수 있다.
도68-69에 따른 멀티캐스트 처리 방법은 도33-36 등 도시된 멀티캐스트를 위한 정보를 생성하여 전달하고, 수신기는 멀티캐스트를 위한 정보에 기반하여 멀티캐스트 미디어 컨텐트를 수신하고 재생할 수 있다.
도68-69에 따른 멀티캐스트 처리 방법은 도37-39 등 도시된 시스템 상에서 멀티캐스트 신호를 생성하여 전달하고 처리할 수 있다.
도68-69에 따른 멀티캐스트 처리 방법은 멀티캐스트 트랜스 포트 세션 내지 피지컬 레이어 간 맵핑 동작을 포함할 수 있다. 이러한 세션 간 맵핑을 통해 멀티캐스트 신호를 처리하기 위해서 도40-41, 47 등 도시된 구조 상 도42-43 프로토콜을 구성하고, 도44-46, 48-49 멀티캐스트를 위한 맵핑 정보 등을 생성하여 송수신한다.
도68-69에 따른 멀티캐스트 처리 방법은 도64의 GSE(링크 레이어) 구조를 통해 멀티캐스트를 처리하고, 도65-66과 같이 상위 레이어의 데이터를 압축하고, 관련된 링크 레이어 시그널링 정보를 생성하여 전달할 수 있다. 또한, 도68-69에 따른 멀티캐스트 처리 방법은 도67과 같이 GSE와 PLP간 관계를 나타내는 정보를 생성하여, 수신 장치가 멀티캐스트 신호를 수신하고 멀티캐스트 미디어 데이터를 재생할 수 있게 한다.
도41 관련하여, 실시예들에 따른 인터페이스는 DVB-NIP 규격의 방송 시스템을 구성할 수 있다. 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함하는, 멀티캐스트 신호 수신 장치는 네이티브 인터넷 프로토콜에 따라 멀티캐스트 신호를 수신할 수 있다.
도42 관련하여, 실시예들의 인터페이스는 DVB-NIP 프로토콜에 따라 구성된다. 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함할 수 있다.
도48 관련하여, 실시예들은 다음과 같은 시그널링 정보를 생성할 수 있고, 이 정보는 시그널링 정보, 메타데이터, ABR transport session descriptor, IP Multicast List descriptor 등 다양하게 지칭하는 가능하다. GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보가 전달되고, 로지컬 레이어 컨트롤(LLC) 정보는, 멀티캐스트 디스크립터를 포함하고, 멀티캐스트 디스크립터는 소스 어드레스 정보, 데스티네이션 어드레스 정보, 소스 UDP 포트 정보, 데스티네이션 UDP 포트 정보를 포함할 수 있다.
도64 관련하여, GSE 레이어는 DVB-NIP를 위해 정의될 수 있다. 실시예들은 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신할 수 있다.
도44 관련하여, DVB-NIP를 위한 LLC 테이블을 정의할 수 있다. 실시예들은GSE레이어로부터 로지컬 링크 컨트롤(Logical Link Control, LLC) 정보를 수신하고, 로지컬 링크 컨트롤 정보는, 네트워크 컨트롤 데이터(Network Control Data, NCD) 및 링크 컨트롤 데이터(Link Control Data, LCD)를 포함할 수 있다. 또한, 네트워크 컨트롤 데이터(NCD)는 멀티캐스트를 위한 디스크립터를 포함하고, 링크 컨트롤 데이터(LCD)는 피지컬 레이어를 위한 링크 식별자를 포함하여, 세션 간 맵핑을 나타내고 멀티캐스트 미디어를 수신할 수 있다.
도67 관련하여, 실시예들은 로지컬 링크 컨트롤(LLC) 정보를 파싱하는 파서; 및 GSE 레이어의 GSE스트림에 포함된 ROHC(Robust Header Compression) 스트림을 수신하고, IP헤더를 디컴프레스하는 디컴프레서; 를 포함할 수 있다.
실시예들에 따른 수신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함할 수 있다.
실시예들에 따른 송신 방법은 멀티캐스트 서버로부터 인터페이스에 기초하여 멀티캐스트 신호를 송신하는 단계, 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함하고, GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보를 생성하는 단계; 를 포함할 수 있다.
이로 인하여, 지상파 방송 및 위성 방송 간 링크 기술이 부재하였고, 멀티캐스트 미디어 전송을 위한 세션 정보 및 인터페이스 구성이 부재한 문제점을 해결할 수 있다. 즉, DVB 표준에서 정의 하고 있는 지상파 방송 및 위성 방송 간 링크와 같은 unidirectional delivery network 에서 DVB ABR multicast의 media object를 전송하기 위해 multicast transport session을 broadcast stream 과 연동시키기 위한 interface 및 signaling 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 (13)

  1. 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 멀티캐스트 게이트웨이; 및
    상기 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 컨텐트 플레이백부; 를 포함하는,
    멀티캐스트 신호 수신 장치.
  2. 제1항에 있어서,
    상기 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함하는,
    멀티캐스트 신호 수신 장치.
  3. 제2항에 있어서, 상기 GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보가 전달되고,
    상기 로지컬 레이어 컨트롤(LLC) 정보는, 멀티캐스트 디스크립터를 포함하고,
    상기 멀티캐스트 디스크립터는 소스 어드레스 정보, 데스티네이션 어드레스 정보, 소스 UDP 포트 정보, 데스티네이션 UDP 포트 정보를 포함하는,
    멀티캐스트 신호 수신 장치.
  4. 제2항에 있어서, 상기 장치는,
    상기 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신하는,
    멀티캐스트 신호 수신 장치.
  5. 제2항에 있어서, 상기 장치는,
    상기 GSE레이어로부터 로지컬 링크 컨트롤(Logical Link Control, LLC) 정보를 수신하고,
    상기 로지컬 링크 컨트롤 정보는, 네트워크 컨트롤 데이터(Network Control Data, NCD) 및 링크 컨트롤 데이터(Link Control Data, LCD)를 포함하고,
    상기 네트워크 컨트롤 데이터(NCD)는 멀티캐스트를 위한 디스크립터를 포함하고,
    상기 링크 컨트롤 데이터(LCD)는 피지컬 레이어를 위한 링크 식별자를 포함하는,
    멀티캐스트 신호 수신 장치.
  6. 제5항에 있어서, 상기 장치는,
    상기 로지컬 링크 컨트롤(LLC) 정보를 파싱하는 파서; 및
    상기 GSE 레이어의 GSE스트림에 포함된 ROHC(Robust Header Compression) 스트림을 수신하고, IP헤더를 디컴프레스하는 디컴프레서; 를 포함하는,
    멀티캐스트 신호 수신 장치.
  7. 멀티캐스트 서버로부터 인터페이스에 기초하여, 멀티캐스트 신호를 수신하는 단계; 및
    상기 멀티캐스트 신호에 포함된 멀티캐스트 서비스를 플레이하는 단계; 를 포함하는,
    멀티캐스트 신호 수신 방법.
  8. 제7항에 있어서,
    상기 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함하는,
    멀티캐스트 신호 수신 방법.
  9. 제8항에 있어서, 상기 GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보가 전달되고,
    상기 로지컬 레이어 컨트롤(LLC) 정보는, 멀티캐스트 디스크립터를 포함하고,
    상기 멀티캐스트 디스크립터는 소스 어드레스 정보, 데스티네이션 어드레스 정보, 소스 UDP 포트 정보, 데스티네이션 UDP 포트 정보를 포함하는,
    멀티캐스트 신호 수신 방법.
  10. 제8항에 있어서, 상기 방법은,
    상기 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신하는,
    멀티캐스트 신호 수신 방법.
  11. 제9항에 있어서, 상기 방법은
    상기 GSE레이어로부터 IP헤더 압축된 IP데이터가 인캡슐레이팅된 GSE데이터, IP헤더가 압축되지 않은 IP데이터가 인캡슐레이팅된 GSE데이터, 멀티캐스트에 대한 디스크립터, 및 IP헤더 압축에 관련된 ROHC(Robust Header Compression) 디스크립터를 포함하는 GSE스트림을 전달하는 PLP(Physical Layer Pipe)를 수신하는,
    멀티캐스트 신호 수신 방법.
  12. 제11항에 있어서, 상기 방법은,
    상기 로지컬 링크 컨트롤(LLC) 정보를 파싱하는 단계; 및
    상기 GSE 레이어의 GSE스트림에 포함된 ROHC(Robust Header Compression) 스트림을 수신하고, IP헤더를 디컴프레스하는 단계; 를 포함하는,
    멀티캐스트 신호 수신 방법.
  13. 멀티캐스트 서버로부터 인터페이스에 기초하여 멀티캐스트 신호를 송신하는 단계,
    상기 인터페이스는, 멀티캐스트 트렌스포트 세션, UDP/IP(User Datagram Protocol/Internet Protocol), GSE(Generic Stream Encapsulation) 레이어, 피지컬 레이어를 포함하는 프로토콜을 포함함; 및
    상기 GSE 레이어 내 로지컬 레이어 컨트롤(Logical Layer Control, LLC) 정보를 생성하는 단계; 를 포함하는
    멀티캐스트 신호 송신 방법.
PCT/KR2022/095043 2021-03-16 2022-02-28 멀티캐스트 신호 처리 방법 및 장치 WO2022197169A1 (ko)

Priority Applications (3)

Application Number Priority Date Filing Date Title
KR1020237025946A KR20230129247A (ko) 2021-03-16 2022-02-28 멀티캐스트 신호 처리 방법 및 장치
US18/277,187 US20240121123A1 (en) 2021-03-16 2022-02-28 Multicast signal processing method and device
CN202280020660.9A CN116941233A (zh) 2021-03-16 2022-02-28 多播信号处理方法和设备

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR10-2021-0034137 2021-03-16
KR20210034137 2021-03-16
KR10-2021-0079486 2021-06-18
KR20210079486 2021-06-18

Publications (1)

Publication Number Publication Date
WO2022197169A1 true WO2022197169A1 (ko) 2022-09-22

Family

ID=80785239

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/095043 WO2022197169A1 (ko) 2021-03-16 2022-02-28 멀티캐스트 신호 처리 방법 및 장치

Country Status (4)

Country Link
US (1) US20240121123A1 (ko)
EP (1) EP4060964B1 (ko)
KR (1) KR20230129247A (ko)
WO (1) WO2022197169A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024085635A1 (ko) * 2022-10-18 2024-04-25 엘지전자 주식회사 멀티캐스트 신호 송신 방법, 멀티캐스트 신호 송신 장치, 멀티캐스트 신호 수신 방법, 및 멀티캐스트 신호 수신 방법

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220321627A1 (en) * 2021-03-31 2022-10-06 Tencent America LLC Methods and apparatus for just-in-time content preparation in 5g networks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180234187A1 (en) * 2017-02-10 2018-08-16 Beijing Jishi Huitong Technology Co.,Ltd. Multimedia network data processing system
KR101995314B1 (ko) * 2013-04-22 2019-07-02 삼성전자주식회사 Ｄｖｂ 지상파 방송 시스템에서 ｍｐｅｇ ｍｍｔ를 위한 시그널링 정보를 송수신하는 장치 및 방법

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017183939A1 (ko) * 2016-04-22 2017-10-26 엘지전자 주식회사 Dash 기반 시스템에서 고품질 미디어 제공을 위한 방송 신호 송수신 방법 및 장치
US20200021867A1 (en) * 2017-03-22 2020-01-16 Lg Electronics Inc. Broadcast signal transmitting and receiving method and device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101995314B1 (ko) * 2013-04-22 2019-07-02 삼성전자주식회사 Ｄｖｂ 지상파 방송 시스템에서 ｍｐｅｇ ｍｍｔ를 위한 시그널링 정보를 송수신하는 장치 및 방법
US20180234187A1 (en) * 2017-02-10 2018-08-16 Beijing Jishi Huitong Technology Co.,Ltd. Multimedia network data processing system

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 1: Protocol", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, vol. BROADCAS, no. V1.2.1, 1 July 2014 (2014-07-01), 650, route des Lucioles ; F-06921 Sophia-Antipolis ; France , XP014214603 *
"Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 3: Robust Header Compression (ROHC) for IP", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, vol. BROADCAS, no. V1.1.1, 1 July 2014 (2014-07-01), 650, route des Lucioles ; F-06921 Sophia-Antipolis ; France , XP014214605 *
ANONYMOUS: "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE); Part 2: Logical Link Control (LLC)", ETSI TS 102 606-2 V1.2.1, 21 December 2016 (2016-12-21), XP055967240, Retrieved from the Internet <URL:https://www.etsi.org/deliver/etsi_ts/102600_102699/10260602/01.02.01_60/ts_10260602v010201p.pdf> *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024085635A1 (ko) * 2022-10-18 2024-04-25 엘지전자 주식회사 멀티캐스트 신호 송신 방법, 멀티캐스트 신호 송신 장치, 멀티캐스트 신호 수신 방법, 및 멀티캐스트 신호 수신 방법

Also Published As

Publication number Publication date
US20240121123A1 (en) 2024-04-11
EP4060964B1 (en) 2024-05-22
EP4060964A1 (en) 2022-09-21
KR20230129247A (ko) 2023-09-07

Similar Documents

Publication Publication Date Title
WO2016140478A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016140477A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016018042A1 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
WO2016140483A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016093586A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2017014586A1 (ko) 방송 신호 송수신 장치 및 방법
WO2016089095A1 (ko) 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2022005102A1 (ko) 멀티캐스트 신호 처리 방법 및 장치
WO2022197169A1 (ko) 멀티캐스트 신호 처리 방법 및 장치
WO2016186407A1 (ko) 방송 신호 송수신 장치 및 방법
WO2011034283A1 (en) Method of processing epg metadata in network device and the network device for controlling the same
WO2016144031A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2020091573A1 (ko) 방송 송신 장치, 방송 송신 방법, 방송 수신 장치 및 방송 수신 방법
WO2016190662A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016064150A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2019093829A1 (ko) 방송 송신 장치, 방송 송신 방법, 방송 수신 장치 및 방송 수신 방법
WO2016153241A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016163772A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016171518A2 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016108606A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016108610A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016178549A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2018101566A1 (ko) 방송 신호 송수신 장치 및 방법
WO2019212318A1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 방법 및 방송 신호 수신 장치
WO2016108607A1 (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: 22771835

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20237025946

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 18277187

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 202280020660.9

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 22771835

Country of ref document: EP

Kind code of ref document: A1