Multicast signal processing method and apparatus

Abstract

A multicast signal receiving apparatus according to an embodiment can include a multicast gateway that receives a multicast signal from a multicast server based on an interface, and a content playback unit that plays back a multicast service included in the multicast signal. A multicast signal receiving method according to an embodiment can include receiving a multicast signal from a multicast server based on an interface, and playing back a multicast service included in the multicast signal.

Description

Technical Field

[0001] This disclosure relates to apparatus and methods for processing multicast signals. Background Technology

[0002] With the development of digital and communication technologies, the distribution and demand for audio / video-oriented multimedia content are rapidly expanding in various fields such as broadcasting, film, the Internet, and personal media. Furthermore, as home television screen sizes increase with the advancement of display technology, ultra-high-definition (UHD) broadcasting services are being discussed more and more frequently.

[0003] Regarding broadcast services, multicast transmission schemes are effective for transmitting the same content to multiple users because they can utilize both unicast and broadcast. However, conventional multicast transmission schemes are available within a single network and cannot support multicast services between heterogeneous networks. As a result, when a multicast receiver establishes and terminates connections with different access networks, a new multicast service needs to be started after terminating the existing one. Additionally, when multiple delivery protocols are used, the protocol constituting the payload over IP / UDP or IP / TCP cannot be identified by a port number if it is not registered with IANA. In the case of IP multicast, the value assigned for multicast is used as the destination address and port number, so all receivers receive the corresponding packets. If an unknown protocol is used at this time, multicast packets may not be processed. Summary of the Invention

[0004] Technical issues

[0005] The purpose of this disclosure is to provide a method and apparatus for transmitting multicast signals that can improve transmission efficiency.

[0006] The purpose of this disclosure is to provide multicast services efficiently across multiple networks.

[0007] The technical scope of the implementation is not limited to the above-described technical objectives, but can be extended to other technical objectives that can be inferred by those skilled in the art based on the full content disclosed herein.

[0008] Technical solution

[0009] According to an embodiment, an apparatus for receiving multicast signals may include: a multicast gateway configured to receive multicast signals from a multicast server via an interface; and a content playback function configured to display multicast services in the multicast signals. According to an embodiment, a method for receiving multicast signals may include the following steps: receiving multicast signals from a multicast server via an interface, and displaying multicast services in the multicast signals.

[0010] Beneficial effects

[0011] According to embodiments of this disclosure, multicast services can be provided between multiple networks.

[0012] According to the implementation method, a media architecture for multicast media streaming over multiple networks can be provided, thereby enabling the same level of media services on multiple networks where a DVB multicast ABR structure can be applied.

[0013] According to the implementation method, multicast content can be received through various access methods, regardless of the network to which the receiving device is connected during multicast streaming.

[0014] According to the implementation method, the same level of ABR multicast service can be provided even when various devices are connected to separate networks. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this disclosure and are incorporated into and constitute a part of this application, illustrate embodiments of the disclosure and, together with the description in the specification, serve to explain the principles of the disclosure. For a better understanding of the various embodiments described below, reference should be made to the following description of embodiments in conjunction with the accompanying drawings. Throughout the drawings, the same reference numerals will be used to refer to the same or similar parts. In the drawings:

[0016] Figure 1 An example of a multicast adaptive bit rate (ABR) structure according to an implementation method is shown;

[0017] Figure 2 An example of a presentation list acquisition process based on a multicast rendezvous service according to an implementation method is illustrated;

[0018] Figure 3 A structure for a multicast rendezvous service according to an embodiment is shown;

[0019] Figure 4 A structure for a multicast rendezvous service according to an embodiment is shown;

[0020] Figure 5 shows a flowchart of multicast-based media reception according to an implementation method;

[0021] Figure 6 The elements included in the URL according to the implementation method are shown;

[0022] Figure 7 The elements included in the URL according to the implementation method are shown;

[0023] Figure 8 A multicast application scheme for 5G media streaming transmission according to an embodiment is shown;

[0024] Figure 9A multicast streaming structure for both multicast network streaming and communication network streaming is shown according to an embodiment.

[0025] Figure 10 An architecture for wireless media transmission based on multicast and broadcast in a communication network, according to an embodiment, is shown.

[0026] Figure 11 illustrates an example of a multicast server configuration in each network according to the implementation method;

[0027] Figure 12 illustrates an example of a multicast server configuration for all networks according to an implementation method;

[0028] Figure 13 Examples of multiple networks to which a device according to an implementation method is connected are illustrated;

[0029] Figure 14 is a flowchart of network changes according to the implementation method;

[0030] Figure 15 Examples of configuring a multicast server and a multicast gateway in each network according to an implementation method are illustrated;

[0031] Figure 16 is a flowchart of network changes according to the implementation method;

[0032] Figure 17 Examples of configuring a multicast server and a multicast gateway in each network according to an implementation method are illustrated;

[0033] Figure 18 is a flowchart of network changes according to the implementation method;

[0034] Figure 19 An example is illustrated of providing a single multicast server service for multiple heterogeneous networks according to an embodiment, and configuring a multicast gateway for the single multicast server in each network;

[0035] Figure 20 shows a flowchart of network changes according to an implementation method;

[0036] Figure 21 An example is illustrated in which a single multicast server is provided for multiple heterogeneous networks according to an implementation method, and a multicast gateway is configured for each network for the single multicast server.

[0037] Figure 22 is a flowchart of network changes according to the implementation method;

[0038] Figure 23 An example is illustrated where, according to an implementation, all multicast rendezvous services are configured to be deployed in tandem when a multicast server and a multicast gateway are configured in each network.

[0039] Figure 24 is a flowchart of network changes according to the implementation method;

[0040] Figure 25 illustrates an implementation of a device accessing various serviceable networks when a multicast server and a multicast gateway are configured in each network, according to an embodiment.

[0041] Figure 26 illustrates a structure in which a single multicast server provides services to multiple heterogeneous networks according to an embodiment, and a multicast gateway for the single multicast server is configured in each network.

[0042] Figure 27 The protocol configuration of ABR multicast according to the implementation method is illustrated;

[0043] Figure 28 An embodiment of a protocol that can be configured in a receiving device to access multiple networks is illustrated according to the embodiment.

[0044] Figure 29 An example of a protocol according to an implementation method is shown;

[0045] Figure 30 The configuration of services and service-related information according to the implementation method is illustrated;

[0046] Figure 31 A method for generating and transmitting a service list and presentation list for ABR multicast according to an implementation method is illustrated;

[0047] Figure 32 This illustrates the service list and presentation list management according to the implementation method;

[0048] Figure 33 A list of services according to the implementation method is shown;

[0049] Figure 34 A multicast session according to an implementation method is shown;

[0050] Figure 35 The illustration shows elements included in the request URL of an HTTP message according to an embodiment;

[0051] Figure 36 The information included in the redirect URL in the location response header according to the implementation is shown;

[0052] Figure 37 illustrates several content providers according to the implementation method;

[0053] Figure 38 illustrates multiple service providers according to the implementation method;

[0054] Figure 39 is a flowchart showing the changes made by the service provider according to the implementation method;

[0055] Figure 40An example of an MABR network configuration for one-way delivery according to an embodiment is shown;

[0056] Figure 41 An example of an MABR network configuration for one-way delivery according to an embodiment is shown;

[0057] Figure 42 The interface configuration according to the implementation method is illustrated;

[0058] Figure 43 The interface configuration according to the implementation method is illustrated;

[0059] Figure 44 An example of a link control data (LCD) configuration according to an implementation method is shown;

[0060] Figure 45 Link-related descriptors according to the implementation method are illustrated;

[0061] Figure 46 Network control data (NCD) according to an implementation method is illustrated;

[0062] Figure 47 A multicast transmission session according to an implementation method is illustrated;

[0063] Figure 48 An example of an mABR IPv6 transport session descriptor according to an implementation method is shown;

[0064] Figure 49 An example of an mABR IPv4 transport session descriptor according to an implementation method is shown;

[0065] Figure 50 An example of a structure for a 5G-based system service according to an implementation method is shown;

[0066] Figure 51 An example of a 5G system architecture in a reference point representation according to an implementation method is shown;

[0067] Figure 52 An example of a 5G system architecture for multiple PDU sessions according to an implementation method is illustrated;

[0068] Figure 53 An example of a 5G system architecture for access coexisting in two data networks, according to an embodiment, is illustrated.

[0069] Figure 54 An example of a user plane protocol stack according to an implementation method is shown;

[0070] Figure 55 An example of unified data management (UDM) according to an implementation method is shown;

[0071] Figure 56An architecture for 5G media streaming transmission according to an implementation method is illustrated;

[0072] Figure 57 A media architecture for unicast downlink media stream transmission according to an embodiment is illustrated;

[0073] Figure 58 A reference architecture according to an implementation is shown;

[0074] Figure 59 A reference architecture according to an implementation is shown;

[0075] Figure 60 An example of a multicast gateway deployment model according to an implementation method is shown;

[0076] Figure 61 An example of a multicast gateway structure deployed in a home gateway device according to an embodiment is shown;

[0077] Figure 62 An example of a multicast gateway structure deployed in a terminal device according to an embodiment is shown;

[0078] Figure 63 An example of a hybrid broadcast receiving device according to an embodiment is shown;

[0079] Figure 64 illustrates the multicast GSE layer structure according to an implementation method;

[0080] Figure 65 An example of a DVB-GSE Robust Header Compression (ROHC) profile and a DVB-GSE header compressor according to an embodiment is shown;

[0081] Figure 66 The ROHC-U information according to the implementation method is illustrated;

[0082] Figure 67 illustrates the transmitting device and receiving device according to an embodiment;

[0083] Figure 68 An example of a multicast transmission method according to an embodiment is illustrated; and

[0084] Figure 69 A multicast receiving method according to an implementation method is illustrated. Detailed Implementation

[0085] Reference will now be made in detail to preferred embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. The detailed description given below with reference to the accompanying drawings is intended to explain exemplary embodiments of the present disclosure, and not to show only embodiments that can be implemented according to the present disclosure. The following detailed description includes specific details to provide a thorough understanding of the present disclosure. However, those skilled in the art will understand that the present disclosure can be practiced without these specific details.

[0086] Although most of the terms used in this disclosure are selected from those widely used in the art, the applicant has arbitrarily chosen some terms and explained their meanings in detail in the following description as needed. Therefore, this disclosure should be understood based on the intended meaning of the terms rather than their simple names or meanings.

[0087] The multicast signal processing method and apparatus according to the embodiments may include a multicast signal transmitting method, a multicast signal receiving method, a multicast signal transmitting device, and a multicast signal receiving device, and may be simply referred to as the method / apparatus according to the embodiments.

[0088] The method / apparatus according to the embodiments relates to a method for media delivery in an adaptive bit rate multicast network based on one-way delivery.

[0089] The media according to the implementation method may be referred to as media signal, media data, etc., and may be interpreted as a term corresponding to or including a service or service data.

[0090] The implementation presents an architecture for media streaming in an Internet Protocol (IP)-based media delivery system.

[0091] The implementation proposes a media streaming architecture for multicast applications in IP-based media delivery systems configured with multiple networks.

[0092] The implementation proposes an ABR multicast method for use when an IP-based media delivery system is configured with multiple networks.

[0093] The implementation describes the operation of a service list receiving method (process) and apparatus (multicast signal processing device according to the implementation) when an IP-based media delivery system is configured with multiple networks.

[0094] The implementation provides signaling information required for receiving (devices) on multiple networks.

[0095] The implementation proposes a multicast ABR architecture based on the configuration of the content provider and the service provider corresponding to the multicast signal processing equipment.

[0096] The implementation provides a media architecture for multicast media streaming over multiple networks. Therefore, a DVB multicast ABR structure can be applied, and the same level of media service is available across multiple networks. Specifically, during multicast streaming, multicast content can be received via various access methods, regardless of the network to which the receiving device is connected.

[0097] Therefore, when various devices are connected to a separate network, the same level of ABR multicast service can be provided.

[0098] The method / apparatus according to the embodiments can provide a multicast transport session mapping method for adaptive bit rate multicast media delivery in a one-way delivery network.

[0099] In one-way delivery networks such as terrestrial broadcasting or satellite broadcasting, multicast transport sessions can be mapped to resources of the one-way delivery network in order to support adaptive bit-rate multicast media delivery configured for use with existing ISP networks.

[0100] When a one-way delivery network is used as an interface between a multicast server and a multicast gateway, transparent transmission can be supported.

[0101] With network diversity, media streaming needs to be provided to various devices and multiple users when different devices access the network. In such an environment, if only unicast transmission is performed for all streaming sessions, the quality of media streaming services and other services using the network may degrade due to increased network load. Therefore, efficient multicast streaming is required. Currently, the ABR multicast architecture defined in DVB is primarily defined when the multicast provider network is a single network. To provide the same service across various networks, including 5G networks (wireless networks), devices need to operate smoothly on each network. This may require updating interfaces and architectures. Furthermore, if excessive network changes are made to existing service providers to support ABR multicast, practical ABR multicast services may not be available due to implementation difficulties and cost issues.

[0102] Multicast technology provides services in a variety of network environments used for general media streaming and can be transmitted in most IP-based networks. However, to provide ABR multicast services using the same functionality across multiple heterogeneous networks, it is necessary to adapt to the capabilities and architecture of each network. When providing ABR multicast services across multiple networks, it is necessary to define the service list and its management plan for transmission to ensure service continuity from the user's perspective.

[0103] This disclosure provides a description of an architecture that allows DVB ABR multicast structures to be provided over various networks and their interfaces. Furthermore, methods for providing service lists over multiple networks and interfaces, as well as a description of the procedures for processing service lists within the apparatus, are provided.

[0104] Additionally, the method / apparatus according to the implementation can provide an interface and signaling stream for linking multicast transmission sessions to broadcast streams to transmit media objects of DVB ABR multicast in a one-way delivery network (such as terrestrial broadcast and satellite broadcast links as defined in the DVB standard).

[0105] Figure 1An example of a multicast adaptive bit rate (ABR) structure according to an implementation method is shown.

[0106] The multicast signal processing method / device according to the implementation method can be based on Figure 1 The structure shown transmits media content via multicast. This media content can be referred to as multicast media, multicast media data, service data, etc. Figure 1 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0107] Figure 1 The interface in the code can be defined as follows.

[0108] L: Unicast HTTP interface between the content playback function and the multicast gateway.

[0109] B: A unicast HTTP interface for guiding content playback and multicast guidance. It can be used to request the initial presentation manifest.

[0110] M: The interface for the multicast server to send multicast IP content and for the multicast gateway to receive content.

[0111] U: The content playback function is an interface that receives media content directly from the content provider via unicast.

[0112] Ingestion: An interface used to provide media content to multicast servers.

[0113] CMS: The control interface used to configure the multicast server.

[0114] CMR: Control interface used to configure multicast gateways.

[0115] Configuration: A control interface used to exchange configuration information between content providers, supply and multicast bootstrap functions.

[0116] Figure 1 The modules in the system can be defined as follows. Each module can correspond to hardware, software, processor, and / or a combination thereof.

[0117] Content providers create or store media content and deliver it to users over a network. They can use transport schemes such as multicast and unicast to send media content to users and provide media content data and control information to multicast servers via an ingestion interface for multicast transmission. Media content data can be encapsulated in formats such as DASH or HLS, and the presentation manifest can be configured according to the encapsulation format.

[0118] Multicast server: Receives media content from the content provider and sends it to the multicast gateway via interface M using an IP multicast transmission scheme. In this case, control information can also be sent. Suitable multicast protocols include ROUTE, FLUTE, QUIC, and RTP.

[0119] Multicast Gateway: Receives encapsulated content segments sent via multicast and provides these segments to the content playback function via interface L using methods such as HTTP. For this purpose, the content segments are cached. Content segments can represent segmented media data. Segmented media data can be stored (cached).

[0120] Provision (Network Control): Provides configuration information about the network and multicast streaming sessions to the multicast server and multicast gateway.

[0121] Multicast routing: This can target and process address information (url or address) for the content playback function, initially accessing it via interface B. It handles initial requests for the presentation manifest received from the content playback function via reference point B. In the case of multicast, it provides redirection information for receiving the manifest via interface L. In the case of unicast, it provides redirection information for receiving the manifest via interface U. Multicast rendezvous service functionality can be implemented within the DVB ABR multicast architecture.

[0122] Content playback: The content playback function manages content requests, reception, decoding, and presentation. Unicast transmission via interface L could be considered.

[0123] Application: The application controls content playback functionality based on user input. For example, it could be a built-in control application (EPG application) on a TV or set-top box, or a third-party application provided by the content provider. The interface used by the application to control content playback can be implemented as a separate API, etc., depending on the device.

[0124] The multicast signal processing method / apparatus according to the embodiments may include a multicast server and a multicast gateway, and further includes a content provider, provisioning and multicast guidance functions in terms of media transmission operations.

[0125] The multicast signal processing method / apparatus according to the embodiments may include content playback function and application in terms of operating the received media.

[0126] Figure 2 An example of a presentation list acquisition process based on a multicast rendezvous service according to an implementation method is provided.

[0127] according to Figure 1 The multicast signal processing method / apparatus of the embodiments can perform, for example Figure 2 The multicast conferencing service shown. Figure 2Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0128] When receiving multicast, the content playback function requests content from the multicast gateway. In the case of unicast reception, the content playback function receives content from the content hosting service. To do this, in order to obtain a presentation list for receiving media content, the initial content playback function can first access the multicast rendezvous service via reference point B. The multicast rendezvous service can provide the content playback function with a URL that allows it to obtain the presentation list appropriately based on multicast and unicast.

[0129] Figure 3 A structure for a multicast rendezvous service according to an embodiment is shown.

[0130] exist Figure 1 and Figure 2 In the structure, the multicast method / device according to the implementation method can perform, as follows: Figure 3 The meeting service shown. Figure 3 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0131] Deployment of multicast rendezvous service:

[0132] Depending on whether HTTP and one-way transmission are supported, multicast rendezvous services can be divided into rule-based deployment and peer-to-peer deployment.

[0133] According to the implementation method, the content playback function of the multicast signal processing device can obtain the list URL information and perform configuration for media reception by performing the following operations.

[0134] Rule Deployment: The multicast rendezvous service is configured in the network and managed by the system operator.

[0135] Co-location deployment: Implement multicast convergence service in the same device as the multicast gateway.

[0136] Rule Deployment

[0137] refer to Figure 3 Multicast rendezvous service corresponds to the element located in the network and managed and controlled by the system operator.

[0138] The content playback function can obtain the list URL information for receiving content from the multicast rendezvous service via reference point B during the initial access to the content to be received. The following configuration can be implemented for this purpose.

[0139] Configurations for a basic set of parameters (e.g., the endpoint addresses for transport sessions configured on a multicast gateway) can be applied to the multicast gateway. For this configuration, the in-band multicast gateway configuration method can be used.

[0140] The configuration for the currently supplied set of multicast sessions can be applied to the multicast gateway via reference point CMR or reference point CMS and M. For this configuration, out-of-band push configuration, out-of-band pull configuration, and on-the-fly configuration methods, as well as in-band multicast gateway configuration methods, can be applied.

[0141] Figure 4 A structure for a multicast rendezvous service according to an embodiment is shown.

[0142] Figure 4 Examples Figure 3 The same deployment in the middle.

[0143] Co-location:

[0144] like Figure 4 As shown, the multicast rendezvous service can be configured in the same device as the multicast gateway (the multicast processing device according to the embodiment). It is primarily used when the multicast ABR network is configured for unidirectional deployment. Figure 4 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0145] The content playback function can obtain the list URL information for receiving content from the multicast rendezvous service via reference point B during the initial access to the content to be received. The following configuration can be implemented for this purpose.

[0146] Configurations for basic parameter sets (e.g., endpoint addresses for transport sessions configured in a multicast gateway) can be applied to multicast rendezvous services.

[0147] The configuration for the currently supplied set of multicast sessions can be applied to the multicast gateway via reference point M.

[0148] In this case, an in-band multicast gateway configuration method can be used for each configuration.

[0149] Figure 5 shows a flowchart of multicast-based media reception according to an implementation method.

[0150] Multicast signal processing method / apparatus according to the implementation method Figures 1 to 4 Multicast media can be received based on the following flowchart.

[0151] Multicast operation according to the implementation method:

[0152] When a user or multicast signal processing device selects the multicast content to receive, the application can obtain the URL (5000) used to request the initial presentation list through the service catalog, etc. Here, the URL indicates the multicast rendezvous service.

[0153] The application controls the content playback function to begin operations related to content reception. In this case, it can deliver a URL used for multicast rendezvous services.

[0154] The content playback function uses the URL obtained from the application to request the presentation list (5001) from the multicast rendezvous service via reference point B.

[0155] The multicast rendezvous service checks the status of the multicast gateway and, if a service for the requested presentation manifest is defined in the multicast configuration, sends a redirect URL (5002) to the content playback function for the multicast gateway. In this case, the multicast session configuration can be included in the redirect message sent.

[0156] Upon receiving the redirect message, the content playback function requests the presentation list (5003) from the multicast gateway based on the redirection.

[0157] When a multicast gateway has a pre-cached presentation list, it sends the presentation list to the content playback function (5004).

[0158] When the multicast gateway does not have a cached presentation list, it can obtain the presentation list from the content hosting function via reference point A and send the presentation list to the content playback function.

[0159] The content playback function can receive media segments for the content via a multicast gateway based on the received presentation list.

[0160] In this operation, the syntax of the HTTP message request URL sent by the content playback function to the multicast rendezvous service is configured as follows:

[0161] http: / / <host> / <manifestpath> [？ <field> ＝ <value> [& <field> ＝ <value>]*]

[0162] Figure 6 The elements included in the URL according to the implementation method are shown.

[0163] Elements included in the URL Figure 6 As shown in the image.

[0164] Host: The FQDN (or IP address) of the multicast rendezvous service and an optional port number.

[0165] ManifestPath: The resource path used to retrieve the rendering manifest from the specified host.

[0166] AToken: If required by the system operator, this value is an authentication token authorizing access to the multicast rendezvous service. This may have already been included in the original presentation manifest URL, or it may have been added by a third-party CDN proxy as part of an earlier HTTP redirect URL, or it may be generated locally by the application.

[0167] MGstatus: This value represents the current status of the multicast gateway: 0 = inactive; 1 = active.

[0168] MGid: This value is the port number of the multicast gateway, optionally preceded by an IP address. The format is [IP address]:port.

[0169] MGhost: This value is the multicast gateway hostname.

[0170] Ori: This value is the original target host's hostname (FQDN).

[0171] Applications can use the local multicast rendezvous service hostname or address instead of the original target hostname (FQDN). Furthermore, when relying on a third-party CDN proxy, the proxy can specify the original target hostname (FQDN) here before redirecting requests to the multicast rendezvous service.

[0172] When the multicast rendezvous service receives this request URL, it can send a 307 temporary redirect response. The syntax for the redirect URL in the location response header is configured as follows:

[0173] http: / / <host>[ / session ID] / <manifestpath>[?conf= <multicastsession

[0174] Figure 7 The elements included in the URL according to the implementation method are shown.

[0175] Elements included in the URL Figure 7 As shown in the image.

[0176] Host: The IP address or FQDN of the multicast gateway and an optional port number (e.g., "router.example:8088" or "192.0.2.1:8088").

[0177] Session ID: A unique presentation session identifier transmitted and possibly generated by a multicast rendezvous service that includes one or more URL path elements.

[0178] ManifestPath: The resource path used to retrieve the rendering manifest from the specified host.

[0179] conf: The multicast session parameters will be in the form of a multicast gateway configuration instance document that includes a multicast session.

[0180] Documents can be compressed using Gzip and base64url encoding before being included as parameters in a URL query string.

[0181] When the presentation manifest is associated with a multicast session in the multicast session configuration (the service can be sent via multicast), the multicast rendezvous service can redirect the request to the multicast gateway as follows:

[0182] HTTP / 1.1 307 Temporary Redirect

[0183] server:<Multicast gateway>

[0184] Location: http[s]: / / <Multicast gateway> / <manifestpath>

[0185] The URL corresponding to the location field in the HTTP header may include query parameters for carrying a multicast gateway configuration instance document that includes a session identifier and a multicast session corresponding to the requested presentation manifest.

[0186] According to the implementation method, the multicast ABR can be connected to a 5G network (communication network).

[0187] Figure 8 A multicast application scheme for 5G media streaming transmission according to an embodiment is shown.

[0188] The multicast signal processing method / device according to the implementation method can support multicast in 5G media stream transmission architecture (multicast ABR architecture). Figure 9 This illustrates an implementation of a 5G media streaming architecture using a multicast ABR architecture. In other words, the 5G architecture and the DVB architecture can be combined with each other.

[0189] 5G application providers (5GMSd application providers) can cooperate with Figures 1 to 6 The content provider shown in the multicast ABR is the same as, or can be part of, the content provider. Applications used to receive 5G media streams (i.e., 5GMSd-aware applications) can be... Figures 1 to 6 The multicast ABR application is the same as, or can be part of, the application. The client (5GMSd client) can be with... Figure 1 The content playback functionality of the multicast ABR up to 5 is the same, or may be part of the content playback functionality. The controller (5GMSd AF) may include provisioning functionality, which includes... Figures 1 to 6 The network control sub-functions of the multicast ABR and the multicast routing function, including multicast rendezvous service, are shown.

[0190] Access information (presentation manifest URL) used for initial multicast transmission can be requested and received by the 5GMSd client via interface M5d, which can correspond to... Figures 1 to 6 Interface B of the multicast ABR is shown.

[0191] Unicast streams can be sent from the 5GMSd AS to the media player via the M4d interface. HTTP can be used in this operation.

[0192] Multicast servers and multicast gateways can be configured for multicast transmission between the 5G MSd AS and the media player. Since data is transmitted between the multicast gateway and the media player via the 5G RAN, unicast alone may be supported.

[0193] For multicast transmission, interfaces M4d_M and M4d_L can be defined as follows.

[0194] Multicast stream transmission via interface M4d_M can be sent from the 5GMSd AS to the multicast server, and interface M defined in the multicast ABR can be used between the multicast server and the multicast gateway. Alternatively, the multicast server functionality can be included within the 5GMS AS. In this case, interface M4d_M can be omitted. The protocol defined in interface M can be used as the multicast protocol.

[0195] The M4d_L-M4d_L interface can be used between a multicast gateway and a media player. Here, M4d_M and M4d_L can use an HTTP-based protocol. From the perspective of the DVB multicast ABR, M4d_M corresponds to the ingestion interface, and M4d_L corresponds to interface L.

[0196] Figure 9 A multicast streaming structure for both multicast network streaming and communication network streaming, according to an embodiment, is shown.

[0197] The multicast signal processing method / device according to the implementation method can send / receive and process media content when multicast streaming is provided simultaneously in DVB multicast ABR network and 5G media streaming. Figure 9 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0198] Multiple networks can exist that provide multicast streaming. When a 5G network is one of these networks, use cases can be considered that provide multicast services from the same content provider simultaneously via a 5G mobile network and another IP network. Figure 9 An implementation method is illustrated that provides multicast stream transmission simultaneously via a 5G network and a DVB multicast ABR network.

[0199] Provisioning for multicast sessions can be defined individually based on the characteristics of each network. The multicast interface M through which media is delivered from the multicast server to the multicast gateway can be configured in the same way.

[0200] In this scenario, the interfaces M2d and M4d_M defined in the 5G network can be the same as the ingestion interface. Therefore, content providers can maintain the same protocols used for transmission across each network.

[0201] Figure 10 An architecture for wireless media transmission based on multicast and broadcast in a communication network, according to an embodiment, is shown.

[0202] When wireless multicast and broadcast transmission are supported in the 5G RAN, a multicast gateway can be configured inside the 5G UE. Figure 10 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0203] The 5GMSd application provider can be the same as, or part of, the content provider for the multicast ABR. The 5GMSd awareness application for receiving 5G media streams can be the same as, or part of, the multicast ABR application. The 5GMSd client can be the same as, or part of, the content playback function of the multicast ABR. The 5GMSd AF can include: provisioning functions including network control sub-functions of the multicast ABR and multicast guidance functions including multicast rendezvous services.

[0204] Access information (presentation list URL) used for initial multicast transmission can be requested and received by the 5GMSd client via interface M5d, which can correspond to interface B of the multicast ABR.

[0205] Unicast streams can be sent from the 5GMSd AS to the media player via the M4d interface. HTTP can be used in this operation.

[0206] Multicast servers and multicast gateways can be configured for multicast transmission between the 5GMSd AS and the media player. In this case, the interface M4d_L between the multicast gateway and the media player can be implemented as an internal interface of the UE.

[0207] The interface M4d_M between the multicast server and the multicast gateway can be defined as the same interface M defined in the multicast ABR. Therefore, the protocol defined in interface M can be used as the multicast protocol.

[0208] The method / apparatus / processor (multicast signal processing method / apparatus) according to the embodiments can perform the above-described network control operations and provide a media architecture for multicast media stream transmission based on relevant signaling information on a 5G network. Using the operations according to the embodiments, multicast content can be received through various access methods, regardless of the network to which the receiving device is connected during multicast stream transmission. Furthermore, by presenting a multicast transmission structure, network resources can be efficiently used to send the same content to multiple receivers.

[0209] Implementation methods include a MABR architecture based on multiple IP networks.

[0210] The multiple IP networks according to the implementation method may include various networks, such as communication and broadcast networks.

[0211] To apply the ABR multicast architecture and interface according to the implementation to each network for practical deployment, additional architectural configurations and application methods for the corresponding interfaces will be described. Each component included in the architecture according to the implementation may correspond to hardware, software, processors, and / or combinations thereof.

[0212] Figures 8 to 10 Corresponding to according to Figures 1 to 6 The multicast signal processing method / apparatus shown in the embodiments.

[0213] Figure 11 illustrates an example of a multicast server configuration in each network according to an implementation method.

[0214] Figure 11 illustrates an implementation of a structure in which a multicast server is configured for each network to provide ABR multicast services. This implementation corresponds to a scenario where the multicast service server is primarily deployed by the network operator. The transmitting / receiving apparatus according to this implementation can provide ABR multicast services based on the multicast server structure shown in the figure. Each component in Figure 11 corresponds to hardware, software, a processor, and / or a combination thereof.

[0215] When providing ABR multicast services through multiple heterogeneous networks, a separate deployment of a multicast gateway to receive ABR multicast can be implemented.

[0216] Multicast Gateway (A) - When a multicast gateway is configured for ABR multicast services in an ISP network, it can be configured within a router or home gateway provided by the ISP operator.

[0217] Multicast Gateway (B) - When a multicast gateway is configured for ABR multicast services in a mobile network such as a 5G system, the multicast gateway can be configured within the edge of the mobile network.

[0218] Multicast Gateway (C) - When a multicast gateway is configured for ABR multicast services in a satellite broadcast network, the multicast gateway can be configured within an STB capable of receiving satellite broadcasts.

[0219] Multicast Gateway (D) - When a multicast gateway is configured for ABR multicast services in a terrestrial broadcast network, the multicast gateway can be configured within a broadcast receiver.

[0220] Even when providing ABR multicast services on multiple heterogeneous networks, ABR multicast functionality can be configured independently for each network.

[0221] Figure 12 illustrates an example of a multicast server configuration for all networks according to an implementation method.

[0222] This diagram illustrates an implementation of an ABR multicast service structure where a single multicast server provides ABR multicast services over multiple heterogeneous networks. This implementation corresponds to a scenario where the multicast service server is primarily deployed by the content provider. The transmitting / receiving apparatus according to this implementation can provide ABR multicast services based on the multicast server structure shown in the diagram.

[0223] Each component in Figure 12 corresponds to hardware, software, processor, and / or a combination thereof.

[0224] When providing ABR multicast services through multiple heterogeneous networks, a separate deployment of a multicast gateway to receive ABR multicast can be implemented.

[0225] Multicast Gateway (A) - When a multicast gateway is configured for ABR multicast services in an ISP network, it can be configured within a router or home gateway provided by the ISP operator.

[0226] Multicast Gateway (B) - When a multicast gateway is configured for ABR multicast services in a mobile network such as a 5G system, the multicast gateway can be configured within the edge of the mobile network.

[0227] Multicast Gateway (C) - When a multicast gateway is configured for ABR multicast services in a satellite broadcast network, the multicast gateway can be configured within an STB capable of receiving satellite broadcasts.

[0228] Multicast Gateway (D) - When a multicast gateway is configured for ABR multicast services in a terrestrial broadcast network, it can be configured within a broadcast receiver.

[0229] Even when providing ABR multicast services on multiple heterogeneous networks, ABR multicast functionality can be configured independently for each network.

[0230] Figure 13 Examples of multiple networks to which a device according to an implementation is connected are illustrated.

[0231] In the network architecture according to the embodiments, a multicast signal processing method / apparatus for receiving the same multicast media service by accessing multiple networks can be considered. An implementation of the architecture and ABR multicast interface of the multicast signal processing method / apparatus for receiving the same multicast stream transmission service by accessing multiple networks will be described. The implementation can be carried out in various architectures.

[0232] This diagram illustrates an implementation where all multicast convergence services are deployed according to rules when a multicast server and multicast gateway are configured in the corresponding network. The system according to this implementation may include a service provider, a network, and devices. The service provider, network, and devices are as follows: Figure 13 The configuration shown is correct. Figure 13 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0233] In the architecture of this implementation, a multicast server, multicast gateway, and multicast rendezvous service for each network provide services to content playback functions connected to the corresponding network. For example, the device can access a mobile network and simultaneously access Wi-Fi through an ISP network.

[0234] The content playback function in the device can be composed of two L interfaces, L1 and L2, and two B interfaces, B1 and B2. Media streams can be received via multicast gateway (A) through interface L1, and initial access information about the initial multicast gateway (A) can be received via interface B1. Media streams can be received via multicast gateway (B) through interface L2, and initial access information about the multicast gateway (B) can be received via interface B2.

[0235] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0236] Figure 11 to Figure 13 The following is illustrated: configuration according to network type based on implementation method, as shown in the example. Figures 1 to 6 , Figure 9 and Figure 10 An example of a multicast signal processing device according to the embodiments shown.

[0237] This diagram illustrates the process of receiving the same service even after network changes, following the process of obtaining the inventory and receiving multicast media by the device for the aforementioned architecture.

[0238] Network changes according to the implementation may include, for example, changes between network A (Wi-Fi) and network B (5G).

[0239] Figure 14 is a flowchart of network changes according to the implementation method.

[0240] The flowchart in Figure 14 can be based on... Figure 1 To Figure 5, Figures 8 to 13 The implementation shall be carried out as shown in the embodiments. Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0241] The process related to the multicast server is as follows.

[0242] Each function is deployed according to the architecture, and the configuration for the multicast service is applied to the multicast server, multicast gateway, and multicast rendezvous service.

[0243] The provisioning function delivers configuration information about the current provisioning multicast session to multicast servers (A) and (B) via network control.

[0244] Configuration information about multicast sessions can be delivered through the multicast session element.

[0245] When a multicast session begins, media segments are ingested from the content provider into multicast servers (A) and (B), and multicast transmission commences. Furthermore, any multicast gateways capable of receiving media segments are activated for reception.

[0246] When the device is connected to network A, it can operate as follows.

[0247] Applications can receive a service list from a service provider via network A. To receive the service list, a service list retrieval method defined in network A can be used. For example, when a service catalog is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service catalog, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0248] A list of services can be delivered via the service list element.

[0249] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog, etc. In this case, the URL points to the multicast rendezvous service (A).

[0250] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (A).

[0251] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (A) via reference point B1.

[0252] A manifest can be requested using manifest requests and redirection information.

[0253] The multicast rendezvous service (A) checks the status of the multicast gateway (A) configured in the same network. When a service for the requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (A) sends a redirect URL for the multicast gateway (A) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0254] Redirection can be performed using manifest requests and redirection information.

[0255] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (A) via reference point L1 based on the redirection.

[0256] You can request to see the list.

[0257] When the multicast gateway (A) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0258] The content playback function requests media segments of the content based on the received presentation list.

[0259] The multicast stream is transmitted from the multicast server (A) to the multicast gateway (A) via interface M1.

[0260] The content playback function can receive and play requested media segments via a multicast gateway (A). Media playback continues when no separate control is available.

[0261] In this state, when the device changes its access from network A to network B, it can operate as follows.

[0262] Applications can receive a service list from a service provider via network B. To receive the service list, the service list retrieval method defined in network B can be used. To continuously receive multicast sessions received via network A, session information associated with service IDs can be exchanged. The received service list may include URLs used to request presentation manifests mapped to service IDs.

[0263] For the service being received, the application can obtain the URL used to request the presentation manifest. In this case, the URL points to the multicast rendezvous service (B).

[0264] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (B).

[0265] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (B) via reference point B2.

[0266] The multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network. When a service for a requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (B) sends a redirect URL for the multicast gateway (B) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0267] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (B) via reference point L2 based on the redirection.

[0268] When the multicast gateway (B) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0269] The content playback function requests media segments of the content based on the received presentation list.

[0270] The multicast stream is transmitted from the multicast server (B) to the multicast gateway (B) via interface M2.

[0271] The content playback function can receive and play requested media segments via a multicast gateway (B). Media playback continues when no separate control is available.

[0272] Figure 15 Examples of configuring multicast servers and multicast gateways in each network according to the implementation method are illustrated.

[0273] Apart from Figure 13 In addition to the configuration, the implementation method may also include, for example: Figure 15 The network server and gateway shown.

[0274] This diagram illustrates implementations of multicast rendezvous service configurations based on rules and co-location when configuring a multicast server and multicast gateway in a corresponding network. The system according to this implementation may include a service provider, a network, and devices. The service provider, network, and devices are as follows... Figure 15 The configuration shown is correct. Figure 15 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0275] In the above architecture, for each network, a multicast server, multicast gateway, and multicast rendezvous service provide services to the content playback function connected to the corresponding network. For example, the device can access a set-top box through a satellite broadcast network and simultaneously access Wi-Fi through an ISP network.

[0276] The content playback function in the device can be composed of two L interfaces, L1 and L2, and two B interfaces, B1 and B2. Media streams can be received via multicast gateway (A) through interface L1, and initial access information about the initial multicast gateway (A) can be received via interface B1. Media streams can be received via multicast gateway (B) through interface L2, and initial access information about the multicast gateway (B) can be received via interface B2.

[0277] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0278] Figure 16 is a flowchart of network changes according to the implementation method.

[0279] The flowchart in Figure 16 can be based on... Figure 1 To Figure 5, Figures 8 to 15 The implementation shall be carried out as shown in the embodiments. Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0280] This diagram illustrates the process of receiving the same service even after a network change, following the process of obtaining a list and receiving multicast media by a device for an architecture according to the implementation. The difference from Figure 14 is that the network in Figure 16 includes a case where the network is not bidirectional.

[0281] The process related to the multicast server is as follows.

[0282] Each function is deployed according to the architecture, and the configuration for the multicast service is applied to the multicast server, multicast gateway, and multicast rendezvous service.

[0283] The provisioning function delivers configuration information about the current provisioning multicast session to multicast servers (A) and (B) via network control.

[0284] When a multicast session begins, media segments are ingested from the content provider into multicast servers (A) and (B), and multicast transmission commences. Furthermore, any multicast gateways capable of receiving media segments are activated for reception.

[0285] When the device is connected to network A, it can operate as follows.

[0286] Applications can receive a service list from a service provider via network A. To receive the service list, a service list retrieval method defined in network A can be used. For example, when a service catalog is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service catalog, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0287] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog, etc. In this case, the URL points to the multicast rendezvous service (A).

[0288] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (A).

[0289] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (A) via reference point B1.

[0290] The multicast rendezvous service (A) checks the status of the multicast gateway (A) configured in the same network. When a service for the requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (A) sends a redirect URL for the multicast gateway (A) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0291] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (A) via reference point L1 based on the redirection.

[0292] When the multicast gateway (A) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0293] The content playback function requests media segments of the content based on the received presentation list.

[0294] The multicast stream is transmitted from the multicast server (A) to the multicast gateway (A) via interface M1.

[0295] The content playback function can receive and play requested media segments via a multicast gateway (A). Media playback continues when no separate control is available.

[0296] In this state, when the device changes its access from network A to network B, it can operate as follows.

[0297] Applications can receive a service list from a service provider via network B. To receive the service list, the service list retrieval method defined in network B can be used. To continuously receive multicast sessions received via network A, session information associated with service IDs can be exchanged. The received service list may include URLs used to request presentation manifests mapped to service IDs.

[0298] For the service being received, the application can obtain the URL used to request the presentation manifest. In this case, the URL indicates the multicast gateway (B) and the rendezvous service (B).

[0299] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog or similar means. In this case, the URL indicates either a multicast gateway (B) or a multicast rendezvous service (B).

[0300] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast gateway (B) or multicast rendezvous service (B).

[0301] Since the multicast gateway and multicast rendezvous service are configured in the same device (co-located deployment), the following procedure can be performed optionally.

[0302] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (B) via reference point B2.

[0303] The multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network. When a service for a requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (B) sends a redirect URL for the multicast gateway (B) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0304] The playback function that receives the redirect message follows this redirection.

[0305] Using the obtained URL, a request for the presentation manifest is made to the multicast gateway (B) via reference point L2.

[0306] When the multicast gateway (B) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0307] The content playback function requests media segments of the content based on the received presentation list.

[0308] The multicast stream is transmitted from the multicast server (B) to the multicast gateway (B) via interface M2.

[0309] The content playback function can receive and play requested media segments via a multicast gateway (B). Media playback continues when no separate control is available.

[0310] Figure 17 Examples of configuring multicast servers and multicast gateways in each network according to the implementation method are illustrated.

[0311] This diagram illustrates an implementation where all multicast convergence services are configured in a co-location manner when a multicast server and multicast gateway are configured in the corresponding network. The system according to this implementation may include a service provider, a network, and devices. The service provider, network, and devices are configured as shown in Figure 24. Each component in Figure 24 corresponds to hardware, software, a processor, and / or a combination thereof.

[0312] In the architecture of this implementation, a multicast server, multicast gateway, and multicast rendezvous service for each network provide services to content playback functions connected to the corresponding network. For example, the device can receive broadcasts via a terrestrial broadcast network and simultaneously access a set-top box via a satellite broadcast network. The types of networks can vary depending on the implementation. Both networks can be unidirectional.

[0313] The content playback function in the device can be composed of two L interfaces, L1 and L2, and two B interfaces, B1 and B2. Media stream transmission can be received via interface L1 through a multicast gateway (A), and initial access information about the initial multicast gateway (A) can be received via interface B1. Media stream transmission can be received via interface L2 through a multicast gateway (B), and initial access information about the multicast gateway (B) can be received via interface B2. Here, the device is configured with a multicast gateway (B) and a multicast rendezvous service (B), therefore interfaces L2 and B2 can be replaced by the device's internal interfaces.

[0314] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0315] Figure 18 is a flowchart of network changes according to the implementation method.

[0316] The flowchart in Figure 18 can be based on... Figure 1 To Figure 5, Figures 8 to 17 The implementation shall be carried out as shown in the embodiments. Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0317] This diagram illustrates the process of receiving the same service even after network changes, following the process of obtaining a list and receiving multicast media by a device for an architecture according to the implementation.

[0318] The process related to the multicast server is as follows.

[0319] Each function is deployed according to the architecture, and the configuration for the multicast service is applied to the multicast server, multicast gateway, and multicast rendezvous service.

[0320] The provisioning function delivers configuration information about the current provisioning multicast session to multicast servers (A) and (B) via network control.

[0321] When a multicast session begins, media segments are ingested from the content provider into multicast servers (A) and (B), and multicast transmission commences. Furthermore, any multicast gateways capable of receiving media segments are activated for reception.

[0322] When the device is connected to network A, it can operate as follows.

[0323] Applications can receive a service list from a service provider via network A. To receive the service list, a service list retrieval method defined in network A can be used. For example, when a service catalog is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service catalog, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0324] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog or similar means. In this case, the URL indicates either the multicast gateway (A) or the multicast rendezvous service (A).

[0325] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast gateway (A) or the multicast rendezvous service (A).

[0326] Since the multicast gateway and multicast rendezvous service are configured in the same device (co-located deployment), the following procedure can be performed optionally.

[0327] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (A) via reference point B1.

[0328] The multicast rendezvous service (A) checks the status of the multicast gateway (A) configured in the same network. When a service for the requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (A) sends a redirect URL for the multicast gateway (A) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0329] The playback function that receives the redirect message follows this redirection.

[0330] Using the obtained URL, a request for the presentation manifest is made to the multicast gateway (A) via reference point L1.

[0331] When the multicast gateway (A) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0332] The content playback function requests media segments of the content based on the received presentation list.

[0333] The multicast stream is transmitted from the multicast server (A) to the multicast gateway (A) via interface M1.

[0334] The content playback function can receive and play requested media segments via a multicast gateway (A). Media playback continues when no separate control is available.

[0335] In this state, when the device changes its access from network A to network B, it can operate as follows.

[0336] Applications can receive a service list from a service provider via network B. To receive the service list, the service list retrieval method defined in network B can be used. To continuously receive multicast sessions received via network A, session information associated with service IDs can be exchanged. The received service list may include URLs used to request presentation manifests mapped to service IDs.

[0337] Since the multicast gateway and multicast rendezvous service are configured in the device, operations related to interfaces L2 and B2 can be performed optionally.

[0338] For the service being received, the application can obtain the URL used to request the presentation manifest. In this case, the URL points to the multicast rendezvous service (B).

[0339] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (B).

[0340] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (B) via reference point B2.

[0341] The multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network. When a service for a requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (B) sends a redirect URL for the multicast gateway (B) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0342] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (B) via reference point L2 based on the redirection.

[0343] When the multicast gateway (B) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0344] The content playback function requests media segments of the content based on the received presentation list.

[0345] The multicast stream is transmitted from the multicast server (B) to the multicast gateway (B) via interface M2.

[0346] The content playback function can receive and play requested media segments via a multicast gateway (B). Media playback continues when no separate control is available.

[0347] The following provides a further description of a multicast signal processing method / apparatus capable of accessing multiple networks. In the network structure described according to the embodiments, an apparatus capable of receiving the same multicast media service by accessing multiple networks can be considered. The architecture of the apparatus capable of receiving the same multicast stream transmission service by accessing multiple networks and an implementation of the ABR multicast interface will be described.

[0348] The multicast rendezvous service, as implemented, differs from broadcast guidance. The rendezvous procedure in the network is the process of providing the user equipment (UE) with an initial network address when the UE intends to access the network.

[0349] The rendezvous function can be performed by the network according to the implementation method. Guidance can be performed by the UE. The rendezvous service can have a fixed address or a URL. When the receiver is outside the network, the media's address is redirected to the UE because the UE is connected during initial access to receive the media. The UE can utilize the redirected address to receive a list of the actual media. Since media transmission and reception are based on a multicast scheme, multicast rendezvous service is required if the media has already been viewed by others.

[0350] Figure 19 An example is illustrated of providing a single multicast server service for multiple heterogeneous networks according to an implementation method, and configuring a multicast gateway for the single multicast server in each network.

[0351] This diagram illustrates an implementation where a single multicast server is provided to multiple heterogeneous networks, and a multicast gateway for that single multicast server is configured in each network, with all multicast convergence services deployed according to rules. The system according to this implementation may include a service provider, a network, and devices. The service provider, network, and devices are as follows... Figure 19 The configuration shown is correct. Figure 19 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0352] In the architecture of this implementation, a multicast server, multicast gateway, and multicast rendezvous service for each network provide services to content playback functions connected to the corresponding network. For example, the device can access a mobile network and simultaneously access Wi-Fi through an ISP network.

[0353] The content playback function in the device can be composed of two L interfaces, L1 and L2, and two B interfaces, B1 and B2. Media streams can be received via multicast gateway (A) through interface L1, and initial access information about the initial multicast gateway (A) can be received via interface B1. Media streams can be received via multicast gateway (B) through interface L2, and initial access information about the multicast gateway (B) can be received via interface B2.

[0354] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0355] Figure 20 shows a flowchart of network changes according to an implementation method.

[0356] The flowchart in Figure 20 can be based on... Figure 1 To Figure 5, Figures 8 to 19 The implementation shall be carried out as shown in the embodiments. Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0357] This diagram illustrates the process of receiving the same service even after network changes, following the process of obtaining a list and receiving multicast media by a device for an architecture according to the implementation.

[0358] The process related to the multicast server is as follows.

[0359] Each function is deployed according to the architecture, and the configuration for the multicast service is applied to the multicast server, multicast gateway, and multicast rendezvous service.

[0360] The provisioning function delivers configuration information about the current provisioning multicast session to the multicast server via network control.

[0361] When a multicast session begins, media segments are ingested from the content provider into the multicast server, and multicast transmission commences. Furthermore, any multicast gateways capable of receiving media segments are activated for reception.

[0362] When the device is connected to network A, it can operate as follows.

[0363] Applications can receive a service list from a service provider via network A. To receive the service list, a service list retrieval method defined in network A can be used. For example, when a service catalog is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service catalog, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0364] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog, etc. In this case, the URL points to the multicast rendezvous service (A).

[0365] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (A).

[0366] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (A) via reference point B1.

[0367] The multicast rendezvous service (A) checks the status of the multicast gateway (A) configured in the same network. When a service for the requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (A) sends a redirect URL for the multicast gateway (A) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0368] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (A) via reference point L1 based on the redirection.

[0369] When the multicast gateway (A) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0370] The content playback function requests media segments of the content based on the received presentation list.

[0371] The multicast stream is transmitted from the multicast server to the multicast gateway (A) via interface M1.

[0372] The content playback function can receive and play requested media segments via a multicast gateway (A). Media playback continues when no separate control is available.

[0373] In this state, when the device changes its access from network A to network B, it can operate as follows.

[0374] Applications can receive a service list from a service provider via network B. To receive the service list, the service list retrieval method defined in network B can be used. To continuously receive multicast sessions received via network A, session information associated with service IDs can be exchanged. The received service list may include URLs used to request presentation manifests mapped to service IDs.

[0375] For the service being received, the application can obtain the URL used to request the presentation manifest. In this case, the URL points to the multicast rendezvous service (B).

[0376] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (B).

[0377] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (B) via reference point B2.

[0378] The multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network. When a service for a requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (B) sends a redirect URL for the multicast gateway (B) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0379] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (B) via reference point L2 based on the redirection.

[0380] When the multicast gateway (B) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0381] The content playback function requests media segments of the content based on the received presentation list.

[0382] The multicast stream is transmitted from the multicast server to the multicast gateway (B) via interface M2.

[0383] The content playback function can receive and play requested media segments via a multicast gateway (B). Media playback continues when no separate control is available.

[0384] Figure 21 An example is illustrated of providing services for a single multicast server to multiple heterogeneous networks according to an implementation method, and configuring a multicast gateway for each network for the single multicast server.

[0385] This diagram illustrates an implementation of rule-based and co-location multicast rendezvous service configuration when providing service to multiple heterogeneous networks using a single multicast server and configuring a multicast gateway for the single multicast server in each network. The system according to this implementation may include a service provider, a network, and devices. The service provider, network, and devices are as follows... Figure 21 The configuration shown is correct. Figure 21 Each component in the document corresponds to hardware, software, processor, and / or a combination thereof.

[0386] In the architecture of this implementation, a multicast server, multicast gateway, and multicast rendezvous service for each network provide services to content playback functions connected to the corresponding network. For example, the device can access a set-top box via a satellite broadcast network and simultaneously access Wi-Fi via an ISP network.

[0387] The content playback function in the device can be composed of two L interfaces, L1 and L2, and two B interfaces, B1 and B2. Media streams can be received via multicast gateway (A) through interface L1, and initial access information about the initial multicast gateway (A) can be received via interface B1. Media streams can be received via multicast gateway (B) through interface L2, and initial access information about the multicast gateway (B) can be received via interface B2.

[0388] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0389] Figure 22 is a flowchart of network changes according to the implementation method.

[0390] The flowchart in Figure 22 can be based on... Figure 1 To Figure 5, Figures 8 to 21 The implementation shall be carried out as shown in the embodiments. Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0391] This diagram illustrates the process of receiving the same service even after network changes, following the process of obtaining a list and receiving multicast media by a device for an architecture according to the implementation.

[0392] The process related to the multicast server is as follows.

[0393] Each function is deployed according to the architecture, and the configuration for the multicast service is applied to the multicast server, multicast gateway, and multicast rendezvous service.

[0394] The provisioning function delivers configuration information about the current provisioning multicast session to the multicast server via network control.

[0395] When a multicast session begins, media segments are ingested from the content provider into the multicast server, and multicast transmission commences. Furthermore, any multicast gateways capable of receiving media segments are activated for reception.

[0396] When the device is connected to network A, it can operate as follows.

[0397] Applications can receive a service list from a service provider via network A. To receive the service list, a service list retrieval method defined in network A can be used. For example, when a service catalog is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service catalog, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0398] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog, etc. In this case, the URL points to the multicast rendezvous service (A).

[0399] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (A).

[0400] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (A) via reference point B1.

[0401] The multicast rendezvous service (A) checks the status of the multicast gateway (A) configured in the same network. When a service for the requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (A) sends a redirect URL for the multicast gateway (A) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0402] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (A) via reference point L1 based on the redirection.

[0403] When the multicast gateway (A) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0404] The content playback function requests media segments of the content based on the received presentation list.

[0405] The multicast stream is transmitted from the multicast server to the multicast gateway (A) via interface M1.

[0406] The content playback function can receive and play requested media segments via a multicast gateway (A). Media playback continues when no separate control is available.

[0407] In this state, when the device changes its access from network A to network B, it can operate as follows.

[0408] Applications can receive a service list from a service provider via network B. To receive the service list, the service list retrieval method defined in network B can be used. To continuously receive multicast sessions received via network A, session information associated with service IDs can be exchanged. The received service list may include URLs used to request presentation manifests mapped to service IDs.

[0409] For the service being received, the application can obtain the URL used to request the presentation manifest. In this case, the URL indicates the multicast gateway (B) and the rendezvous service (B).

[0410] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog or similar means. In this case, the URL indicates either a multicast gateway (B) or a multicast rendezvous service (B).

[0411] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast gateway (B) or multicast rendezvous service (B).

[0412] Since the multicast gateway and multicast rendezvous service are configured in the same device (co-located deployment), the following procedure can be performed optionally.

[0413] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (B) via reference point B2.

[0414] The multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network. When a service for a requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (B) sends a redirect URL for the multicast gateway (B) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0415] The playback function that receives the redirect message follows this redirection.

[0416] Using the obtained URL, a request for the presentation manifest is made to the multicast gateway (B) via reference point L2.

[0417] When the multicast gateway (B) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0418] The content playback function requests media segments of the content based on the received presentation list.

[0419] The multicast stream is transmitted from the multicast server to the multicast gateway (B) via interface M2.

[0420] The content playback function can receive and play requested media segments via a multicast gateway (B). Media playback continues when no separate control is available.

[0421] Figure 23 An example is illustrated where, according to an implementation, all multicast rendezvous services are configured to be deployed in a co-location manner when a multicast server and a multicast gateway are configured in each network.

[0422] This diagram illustrates an implementation where all multicast rendezvous services are configured in a co-location manner when a multicast server and a multicast gateway are configured in each network. The system according to this implementation may include service providers, networks, and devices. Service providers, networks, and devices are as follows... Figure 36 The configuration shown is correct. Figure 36 Each component in the system corresponds to hardware, software, processor, and / or a combination thereof. The server can be located outside the network.

[0423] In the architecture of this implementation, a multicast server, multicast gateway, and multicast rendezvous service for each network provide services to content playback functions connected to the corresponding network. For example, the device can receive broadcasts via a terrestrial broadcast network and simultaneously access a set-top box via a satellite broadcast network.

[0424] The content playback function in the device can be composed of two L interfaces, L1 and L2, and two B interfaces, B1 and B2. Media stream transmission can be received via multicast gateway (A) through interface L1, and initial access information about the initial multicast gateway (A) can be received via interface B1. Media stream transmission can be received via multicast gateway (B) through interface L2, and initial access information about the multicast gateway (B) can be received via interface B2. Here, the device is configured with multicast gateway (B) and multicast rendezvous service (B), therefore interfaces L2 and B2 can be replaced by interfaces within the device.

[0425] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0426] Figure 24 is a flowchart of network changes according to the implementation method.

[0427] The flowchart in Figure 24 can be based on... Figure 1 To Figure 5, Figures 8 to 23 The implementation shall be carried out as shown in the embodiments. Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0428] This diagram illustrates the process of receiving the same service even after network changes, following the process of obtaining a list and receiving multicast media by a device for an architecture according to the implementation.

[0429] The process related to the multicast server is as follows.

[0430] Each function is deployed according to the architecture, and the configuration for the multicast service is applied to the multicast server, multicast gateway, and multicast rendezvous service.

[0431] The provisioning function delivers configuration information about the current provisioning multicast session to the multicast server via network control.

[0432] When a multicast session begins, media segments are ingested from the content provider into the multicast server, and multicast transmission commences. Furthermore, any multicast gateways capable of receiving media segments are activated for reception.

[0433] When the device is connected to network A, it can operate as follows.

[0434] Applications can receive a service list from a service provider via network A. To receive the service list, a service list retrieval method defined in network A can be used. For example, when a service catalog is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service catalog, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0435] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog or similar means. In this case, the URL indicates either the multicast gateway (A) or the multicast rendezvous service (A).

[0436] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast gateway (A) or the multicast rendezvous service (A).

[0437] Since the multicast gateway and multicast rendezvous service are configured in the same device (co-located deployment), the following procedure can be performed optionally.

[0438] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (A) via reference point B1.

[0439] The multicast rendezvous service (A) checks the status of the multicast gateway (A) configured in the same network. When a service for the requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (A) sends a redirect URL for the multicast gateway (A) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0440] The playback function that receives the redirect message follows this redirection.

[0441] Using the obtained URL, a request for the presentation manifest is made to the multicast gateway (A) via reference point L1.

[0442] When the multicast gateway (A) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0443] The content playback function requests media segments of the content based on the received presentation list.

[0444] The multicast stream is transmitted from the multicast server to the multicast gateway (A) via interface M1.

[0445] The content playback function can receive and play requested media segments via a multicast gateway (A). Media playback continues when no separate control is available.

[0446] In this state, when the device changes its access from network A to network B, it can operate as follows.

[0447] Applications can receive a service list from a service provider via network B. To receive the service list, the service list retrieval method defined in network B can be used. To continuously receive multicast sessions received via network A, session information associated with service IDs can be exchanged. The received service list may include URLs used to request presentation manifests mapped to service IDs.

[0448] Since the multicast gateway and multicast rendezvous service are configured in the device, operations related to interfaces L2 and B2 can be performed optionally.

[0449] For the service being received, the application can obtain the URL used to request the presentation manifest. In this case, the URL points to the multicast rendezvous service (B).

[0450] The application can control the start of content reception for the content playback function. In this case, it can deliver a URL for the multicast rendezvous service (B).

[0451] The content playback function uses a URL delivered from the application to request a presentation list from the multicast rendezvous service (B) via reference point B2.

[0452] The multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network. When a service for a requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (B) sends a redirect URL for the multicast gateway (B) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0453] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (B) via reference point L2 based on the redirection.

[0454] When the multicast gateway (B) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0455] The content playback function requests media segments of the content based on the received presentation list.

[0456] The multicast stream is transmitted from the multicast server to the multicast gateway (B) via interface M2.

[0457] The content playback function can receive and play requested media segments via a multicast gateway (B). Media playback continues when no separate control is available.

[0458] The following provides a further description of a multicast signal processing method / device capable of accessing multiple networks.

[0459] Multicast servers can be located on each network.

[0460] Figure 25 illustrates an implementation of a device accessing various serviceable networks when a multicast server and a multicast gateway are configured in each network, according to an embodiment.

[0461] Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0462] This diagram illustrates an implementation where a device accesses various serviceable networks when a multicast server and multicast gateway are configured in each network based on the above description. The system according to this implementation may include a service provider, a network, and a device. The service provider, network, and device are configured according to this implementation as follows.

[0463] Figure 26 illustrates a structure in which a single multicast server provides services to multiple heterogeneous networks according to an embodiment, and a multicast gateway for the single multicast server is configured in each network.

[0464] As described above, this illustration depicts an implementation where a device accesses various serviceable networks when the service of a single multicast server is provided for multiple heterogeneous networks and a multicast gateway for that single multicast server is configured in each network. The system according to this implementation may include a service provider, a network, and a device. The service provider, network, and device are configured as follows.

[0465] Each component constituting an implementation corresponds to hardware, software, a processor, and / or a combination thereof.

[0466] The transmitting / receiving device according to the embodiments can efficiently control and provide DVB multicast ABR and 5G media streaming transmission in various network environments based on the operation according to the embodiments.

[0467] The receiving operation and the operation of the receiving device according to the embodiments will be described below.

[0468] The following protocols can be implemented for the architecture based on the above implementation method.

[0469] Based on the architecture described in the implementation, the elements and attributes required for an apparatus capable of transmitting ABR multicast streams by accessing multiple transport networks are defined.

[0470] The receiver according to the embodiment can perform the reverse process of the transmitter's operation. The receiver can perform ABR multicast stream transmission based on the following operations. The receiver can perform ABR multicast stream transmission based on the following network structure.

[0471] The following is an example of the protocol stack in a receiving device.

[0472] Figure 27 The protocol configuration of ABR multicast according to the implementation method is illustrated.

[0473] For multicast ABR transmission, multicast streams can be sent from the multicast server via interface M. In this case, ROUTE or FLUTE can be used as the multicast transmission protocol. The multicast gateway can use DASH or HLS for HTTP-based adaptive media streaming to the playback function via interface L. In the playback function, the protocol used to receive HTTP-based adaptive media streams from the multicast gateway, as well as the file format and media codec used for the received adaptive streams, can be configured. Here, Layer 1 and Layer 2 protocols can be configured as the optimal protocols for the corresponding networks.

[0474] To access multiple networks, implementation methods may include the protocols described below.

[0475] Figure 28 An embodiment of a protocol that can be configured in a receiving device to access multiple networks is illustrated.

[0476] This figure illustrates the protocol implemented on the architecture according to the above-described embodiment when the multicast signal processing device according to the embodiment is implemented as a receiving device.

[0477] According to the implementation method, it is assumed that a multicast gateway for network A is configured on the network, and a multicast gateway for network B is configured in the device.

[0478] According to the implementation, a multicast gateway configured on a network to provide ABR multicast stream transmission services on network A receives multicast stream transmissions from a multicast server and sends the multicast stream transmissions to the device via interface L in an HTTP-based adaptive media stream transmission manner. Therefore, a protocol stack for receiving adaptive media stream transmissions via interface L can be configured in the device.

[0479] Furthermore, a multicast gateway can be configured in the device to receive ABR multicast streams via network B. Therefore, a protocol stack for receiving adaptive media streams via interface M for network B can be configured in the device.

[0480] Therefore, protocols for interfaces M and L can be configured simultaneously in the receiver device to access multiple networks and receive ABR multicast services. In this case, the multicast gateway function in the device can convert the multicast stream transmission into an HTTP-based adaptive media stream transmission in the same way as a multicast gateway configured on the network, and deliver the converted stream transmission to interface L in the device.

[0481] Figure 28 The protocol according to the implementation method is shown.

[0482] This figure illustrates the protocol implemented on the architecture according to the above-described embodiment when the multicast signal processing device according to the embodiment is implemented as a receiving device.

[0483] According to the implementation method, it is assumed that a multicast gateway for network A is configured on the network, and a multicast gateway for network B is configured in the device.

[0484] According to the implementation, a multicast gateway configured on a network to provide ABR multicast stream transmission services on network A receives multicast stream transmissions from a multicast server and sends the multicast stream transmissions to the device via interface L in an HTTP-based adaptive media stream transmission manner. Therefore, a protocol stack for receiving adaptive media stream transmissions via interface L can be configured in the device.

[0485] Furthermore, a multicast gateway can be configured in the device to receive ABR multicast streams via network B. Therefore, a protocol stack for receiving adaptive media streams via interface M for network B can be configured in the device.

[0486] Therefore, protocols for interfaces M and L can be configured simultaneously in the receiver device to access multiple networks and receive ABR multicast services. In this case, the multicast gateway function in the device can convert the multicast stream transmission into an HTTP-based adaptive media stream transmission in the same way as a multicast gateway configured on the network, and deliver the converted stream transmission to interface L in the device.

[0487] Figure 29 An example of a protocol according to an implementation method is shown.

[0488] In this implementation, it is assumed that a multicast gateway for network A is configured on the network, and a multicast gateway for network B is configured in the device.

[0489] In one implementation, a multicast gateway configured on a network to provide ABR multicast stream transmission services on network A receives multicast stream transmissions from a multicast server and sends the multicast stream transmissions to the device via interface L in an HTTP-based adaptive media stream transmission manner. Therefore, a protocol stack for receiving adaptive media stream transmissions via interface L can be configured in the device.

[0490] Furthermore, a multicast gateway can be configured in the device to receive ABR multicast streams via network B. Therefore, a protocol stack for receiving adaptive media streams via interface M for network B can be configured in the device.

[0491] Therefore, protocols for interfaces M and L can be configured simultaneously in the receiver device to access multiple networks and receive ABR multicast services. In this case, unlike a multicast gateway configured on a network, the multicast gateway function in the device can have interface L configured within the device. Interface L can be directly configured as a protocol stack without a separate interface. For streams received via network A, the device can operate when the playback function is activated. For streams received via network B, the device can operate as a multicast gateway. When operating as a multicast gateway, interface L can be omitted, and the payload of the multicast protocol can be adaptive media stream data.

[0492] Next, the operations for generating and sending / receiving service lists and presenting lists according to the implementation method will be described.

[0493] Figure 30 The configuration of services and service-related information according to the implementation method is illustrated.

[0494] For DASH-based ABR multicast services, service providers, according to the implementation method, can configure the presentation manifest (e.g., MPD) and service list as follows. In terms of service provisioning, the service list and presentation manifest can be configured non-redundantly for the same content.

[0495] Figure 31 A method for generating and sending a service list and presentation list for ABR multicast according to an implementation is illustrated.

[0496] To support ABR multicast, the multicast signal processing method / device according to the implementation method can be as follows: Figure 31 The generated and sent / received service list and presentation list are shown.

[0497] The elements that can be sent can be determined based on the interfaces defined in the ABR multicast architecture. The receiving device's application can receive a service list from the service list directory. The list may include the service ID and URL for the multicast rendezvous service. When the content playback function requests the list from the multicast rendezvous service via the URL, it can obtain the multicast gateway's address and list path through the multicast rendezvous service's redirect message and receive the presentation list via interface L. The multicast gateway can receive the presentation list (e.g., MPD) from the multicast server. For this purpose, multicast session configuration information can be obtained.

[0498] Figure 32 The example illustrates the management of service lists and presentation lists according to the implementation method.

[0499] The receiving device according to the embodiment can be as follows: Figure 32 The management service list and presentation list are shown. For the service list and presentation list (e.g., MPD) configured in the structure according to the implementation, the service list can be managed in a receiver capable of receiving ABR multicast services through multiple networks, as described below.

[0500] In other words, MPDs can be generated and sent / received for multiple networks such as Network 1 and Network 2 for the same service.

[0501] In this implementation, the adaptive sets provided by the respective networks can differ from one another in devices that receive ABR multicast services using multiple networks. Therefore, the presentation list is configured and managed separately for each network.

[0502] When the ABR multicast service receiving function is configured in TV or the like and the broadcast content is simultaneously received by the corresponding receiver, the service list according to the implementation method can be managed like a channel mapping.

[0503] Figure 33 A list of services according to an implementation method is shown.

[0504] Figure 33 The syntax for the service list according to the implementation method is shown.

[0505] ServiceList - This is the root element that contains configuration information about services.

[0506] @serviceIdentifier - An identifier used to identify a service.

[0507] PresentationManifestRequestURL - An element containing information about a multicast service when configuring multiple multicast services for a single service.

[0508] @NetworkType - The network type for the deployed multicast rendezvous service. It can be used to set priorities when devices are accessing the network simultaneously.

[0509] @HostAddress - The address for the multicast rendezvous service.

[0510] @RendezvousServerType - An attribute for the deployment of multicast rendezvous services. For example, 0 is for rule-based deployment, and 1 is for peer-to-peer deployment.

[0511] The MulticastTransportSession element can optionally be sent if the device includes a multicast gateway. When the MulticastTransportSession element is not sent, the information can be provided through the multicast gateway configuration.

[0512] Figure 34 A multicast session according to an implementation method is shown.

[0513] This diagram illustrates an implementation of multicast session element configuration. Multicast session elements are sent from the provisioning function to the multicast server and multicast gateway. Therefore, the CMS interface and CMR interface can be used respectively. When the network only supports unidirectional transmission, the element can be delivered to the multicast server via the CMS interface, and then from the multicast server to the multicast gateway via interface M.

[0514] @serviceIdentifier: The service identifier of the logical service associated with this session.

[0515] @contentPlaybackAvailabilityOffset: Duration string. When passed to an instance of the content playback feature, the availability time offset is adjusted for the original presentation manifest.

[0516] @networkIdentifier: The identifier of the network from which the current multicast session is sent.

[0517] PresentationManifestLocator: The URL of the presentation manifest for the linear service.

[0518] @manifestId: Uniquely identifies the manifest within the scope of the multicast session.

[0519] @contentType: The MIME content type of this render manifest.

[0520] MulticastTransportSession: A container for multicast transport session parameters.

[0521] @networkIdentifier - An identifier for the network providing the current multicast session. Receivers can identify the network from which the same multicast service is being received.

[0522] According to the implementation of the manifest request and redirection

[0523] In the above architecture, the syntax of the request URL for the HTTP message sent by the content playback function to the multicast rendezvous service is configured as follows.

[0524] http: / / <host> / <manifestpath> [？ <field> ＝ <value> [& <field> ＝ <value>]*]

[0525] Figure 35 The elements included in the URL according to the implementation method are shown.

[0526] Figure 35 The illustration shows elements included in the request URL of an HTTP message according to an embodiment.

[0527] Host: The FQDN (or IP address) of the multicast rendezvous service and an optional port number.

[0528] ManifestPath: The resource path used to retrieve the rendering manifest from the specified host.

[0529] AToken: If required by the system operator, this value is an authentication token authorizing access to the multicast rendezvous service. This may have already been included in the original presentation manifest URL, or it may have been added by a third-party CDN proxy as part of an earlier HTTP redirect URL, or it may be generated locally by the application.

[0530] Priority: Retrieves the presentation priority when deploying multiple networks.

[0531] MGstatus: This value represents the current state of the multicast gateway. For example, 0 = inactive and 1 = active.

[0532] MGid: This value is the port number of the multicast gateway, optionally preceded by an IP address. The format is [IP address]:port.

[0533] MGhost: This value is the multicast gateway hostname.

[0534] Ori: This value is the original target host's hostname (FQDN).

[0535] Applications can use the local multicast rendezvous service hostname or address instead of the original target hostname (FQDN). Furthermore, when relying on a third-party CDN proxy, the proxy can specify the original target hostname (FQDN) here before redirecting requests to the multicast rendezvous service.

[0536] Priority - When the playback function requests a list from the multicast rendezvous service and the multicast rendezvous service is able to redirect it to multiple multicast gateways, different priorities can be assigned to the networks in which the multicast gateways are configured, making it possible to determine the priority of multicast reception.

[0537] Upon receiving the request URL according to the implementation method, the multicast rendezvous service can send a 307 temporary redirect response. Here, the syntax of the redirect URL in the location response header is configured as follows:

[0538] http[s]: / / <host>[ / session ID] / <manifestpath>[?conf= <multicastsession

[0539] The elements included in the URL according to the embodiments are disclosed below.

[0540] Figure 36 The information included in the redirect URL in the location response header according to the implementation is shown.

[0541] Host: The IP address or FQDN of the multicast gateway and an optional port number (e.g., "router.example:8088" or "192.0.2.1:8088").

[0542] Session ID: A unique presentation session identifier transmitted and possibly generated by a multicast rendezvous service that includes one or more URL path elements.

[0543] ManifestPath: The resource path used to retrieve the rendering manifest from the specified host.

[0544] RequestedPriority: The priority value for requests made from content playback.

[0545] conf: Multicast session parameters can be in the form of a multicast gateway configuration example document that includes a multicast session.

[0546] Documents can be compressed using Gzip and base64url encoding before being included as parameters in a URL query string.

[0547] RequestedPriority - When the replay function requests a list from the multicast rendezvous service and multiple multicast gateway priorities are configured, it can return the priority sent during redirection. The multicast rendezvous service can then redirect it to the multicast gateway with the highest possible priority that can be redirected.

[0548] When the presentation manifest is associated with a multicast session in the multicast session configuration (the service can be sent via multicast), the multicast rendezvous service can redirect the request to the multicast gateway as follows:

[0549] HTTP / 1.1 307 Temporary Redirect

[0550] server:<Multicast gateway>

[0551] Location: http[s]: / / <Multicast gateway> / <manifestpath>[? <requestedPriority]*

[0552] The URL corresponding to the location field in the HTTP header may include query parameters for carrying a multicast gateway configuration instance document that includes a session identifier and a multicast session corresponding to the requested presentation manifest.

[0553] The operation of the content provider and service provider according to the implementation method will be described below.

[0554] The architecture according to the implementation may include content providers, service providers, networks, and devices. Each component may correspond to hardware, software, a processor, and / or a combination thereof. The processor according to the implementation may perform the operations according to the implementation and may be connected to memory to store information about the operations.

[0555] Figure 37 illustrates several content providers according to the implementation method.

[0556] The architecture described in this embodiment illustrates a structure that uses content created by multiple content providers to provide services. In this architecture, a multicast server, multicast gateway, and multicast rendezvous service for each network provide services to content playback functionality connected to the respective network.

[0557] In this scenario, a service provider can use multiple networks to provide services to a receiver device. The service provider can configure a service list directory and obtain the list of content to be provided through content provider control functions configured in each content provider. The received content list can be configured as a service list in a format suitable for the service. The service list is then provided to the application.

[0558] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0559] Content provider servers provide content (ingestion) to multicast servers configured within the service provider. In this scenario, information about the ingested content can be sent from each content provider control function to the service provider control function. Based on this information, the service provider control function can configure multicast session configuration information and deliver it to the multicast servers and multicast gateways.

[0560] In the content playback function of the device, interfaces L and B can be configured for each network. Media stream transmission can be received via interfaces L1, L2, L3, and L4 through multicast gateways (A), (B), (C), and (D), and initial access information from the multicast gateways can be received via interfaces B1, B2, B3, and B4. Since multicast gateway (D) and multicast rendezvous service (D) are configured within the device, interfaces L4 and B4 can be replaced by internal interfaces of the device.

[0561] Figure 38 illustrates several service providers according to the implementation method.

[0562] The architecture described in this embodiment illustrates a structure that provides services to content providers through multiple service providers. In this architecture, a multicast server, a multicast gateway, and a multicast rendezvous service for each network provide services to content playback functions connected to the respective network.

[0563] In this scenario, each service provider can use multiple networks to provide services to the receiver device. Each service provider can configure a service list directory and can obtain the list of content to be served through the content provider's content provider control functions. The received content list can be configured as a service list in a format suitable for the service. The service list is then provided to the application.

[0564] Applications obtain a list of multicast services and access information for the corresponding multicast rendezvous services via a service discovery interface. The service discovery interface can conform to methods defined separately between the service provider and the application. Additionally, each network can support sending and receiving data used for the service discovery interface.

[0565] The content provider server provides content (ingestion) to a multicast server configured within the service provider. In this scenario, information about the ingested content can be sent from the content provider control function to the service provider control function. Based on this information, the service provider control function can configure multicast session configuration information and deliver it to the multicast server and multicast gateway.

[0566] In the content playback function of the device, interfaces L and B can be configured for each network. Media stream transmission can be received via interfaces L1, L2, L3, and L4 through multicast gateways (A), (B), (C), and (D), and initial access information from the multicast gateways can be received via interfaces B1, B2, B3, and B4. Since multicast gateway (D) and multicast rendezvous service (D) are configured within the device, interfaces L4 and B4 can be replaced by internal interfaces of the device.

[0567] Figure 39 is a flowchart illustrating the changes made by the service provider according to the implementation method.

[0568] This diagram illustrates the process of receiving the same content even after changing the service provider, following the process of obtaining a list and receiving multicast media by a device for an architecture according to the implementation.

[0569] The process related to content providers can be performed as follows.

[0570] The content provider control function passes the content list to the service provider control functions of service provider A and service provider B.

[0571] The list of control functions provided by the service provider is reorganized into a service list, and the service list is sent to each associated application.

[0572] The process related to the multicast server is as follows (operations are performed independently for each service provider).

[0573] Each function is deployed according to the architecture, and the configuration for the multicast service is applied to the multicast server, multicast gateway, and multicast rendezvous service.

[0574] The provisioning function delivers configuration information about the current provisioning multicast session to the multicast server via network control.

[0575] When a multicast session begins, media segments are ingested from the content provider into the multicast server, and multicast transmission commences. Furthermore, any multicast gateways capable of receiving media segments are activated for reception.

[0576] After receiving the service through service provider A, the device can operate as follows.

[0577] Application (A) can receive a service list from the service list directory (A) via network A. To receive the service list, a service list retrieval method defined in network A can be used. For example, when a service directory is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service directory, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0578] When a user selects multicast content to receive through application (A), the application can obtain a URL for requesting an initial presentation manifest from a service catalog, etc. In this case, the URL indicates either the multicast gateway (A) or the multicast rendezvous service (A).

[0579] Application (A) can control the operation of initiating content reception for the content playback function. In this case, it can deliver a URL for the multicast gateway (A) or the multicast rendezvous service (A).

[0580] The content playback function uses a URL delivered from the application (A) to request a presentation list from the multicast rendezvous service (A) via reference point B1.

[0581] The multicast rendezvous service (A) checks the status of the multicast gateway (A) configured in the same network. When a service for the requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (A) sends a redirect URL for the multicast gateway (A) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0582] Upon receiving the redirect message, the content playback function requests the presentation list from the multicast gateway (A) via reference point L1 based on the redirection.

[0583] When the multicast gateway (A) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0584] The content playback function requests media segments of the content based on the received presentation list.

[0585] The multicast stream is transmitted from the multicast server (A) to the multicast gateway (A) via interface M1.

[0586] The content playback function can receive and play requested media segments via a multicast gateway (A). Media playback continues when no separate control is available.

[0587] In this state, when the device changes access from service provider A to service provider B and changes the network to network (B), it can operate as follows.

[0588] Application (B) can receive a service list from the service list catalog (B) via network B. To receive the service list, the service list retrieval method defined in network B can be used. For example, when a service catalog is configured in a DVB-I network, the service list can be received through interaction between the service provider, the service catalog, and the application. For ABR multicast operations, the service list may include a URL used to request a presentation manifest mapped to a service ID.

[0589] For the service being received, the application (B) can obtain the URL used to request the presentation manifest. In this case, the URL indicates the multicast gateway (B) and the rendezvous service (B).

[0590] When a user selects to receive multicast content, the application can obtain the URL for requesting the initial presentation manifest through a service catalog or similar means. In this case, the URL indicates either a multicast gateway (B) or a multicast rendezvous service (B).

[0591] The application can control the start of content reception for the content playback function. In this case, it can deliver the URLs for the multicast gateway (B) and the multicast rendezvous service (B).

[0592] When the multicast gateway and multicast rendezvous service are configured in the same device (co-located deployment), the following procedure may be performed optionally.

[0593] The content playback function uses a URL delivered from the application (B) to request a presentation list from the multicast rendezvous service (B) via reference point B2.

[0594] The multicast rendezvous service (B) checks the status of the multicast gateway (B) configured in the same network. When a service for a requested presentation manifest is defined in the multicast configuration, the multicast rendezvous service (B) sends a redirect URL for the multicast gateway (B) to the content playback function. In this case, the updated multicast session configuration can be included in the redirect message sent.

[0595] The playback function that receives the redirect message follows this redirection.

[0596] Using the obtained URL, a request for the presentation manifest is made to the multicast gateway (B) via reference point L2.

[0597] When the multicast gateway (B) has a pre-cached presentation list, it sends the presentation list to the content playback function.

[0598] The content playback function requests media segments of the content over the network (B) based on the received presentation list.

[0599] The multicast stream is sent from the multicast server to the multicast gateway (B) via interface M.

[0600] The content playback function can receive and play requested media segments via a multicast gateway (B). Media playback continues when no separate control is available.

[0601] Figure 40 An example of a MABR network configuration for one-way delivery according to an embodiment is shown.

[0602] The method / apparatus according to the embodiments can support unidirectional delivery through a network with a MABR architecture according to the above embodiments. An example of multicast transport session mapping for unidirectional delivery will be described.

[0603] In the architecture according to the implementation method, the multicast ABR service provider configures a multicast server for each network and uses a multicast interface (M) to send multicast content and configuration information to the multicast gateway and multicast rendezvous service. Here, interface M can be configured through a unidirectional network without an uplink channel. Satellite (broadcast) networks or terrestrial broadcast networks can be considered as such unidirectional networks.

[0604] Multicast ABR content and configuration information received by the multicast gateway and multicast rendezvous service can be transmitted to the content playback function via HTTP or other means provided by interface L, and the multicast gateway can function as a server for the home broadcast (HB) network.

[0605] Interfaces L and B can be configured in the content playback function of the device or HB network. Media stream transmission can be received via the multicast gateway through interface L, and the initial access information of the multicast gateway can be received via interface B. Here, when the multicast gateway and multicast rendezvous service are configured in the same device, interfaces L and B can be replaced by the device's internal interfaces.

[0606] After a list of services that can provide 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 can deliver it to the multicast gateway via interface M.

[0607] Figure 41 An example of a MABR network configuration for one-way delivery according to an embodiment is shown.

[0608] In the architecture of this implementation, the multicast ABR service provider configures a single multicast server and uses the same multicast interface (M) to send the same multicast content and configuration information to the multicast gateway and the multicast rendezvous service. Here, interface M can be configured through a unidirectional network without an uplink channel. Satellite (broadcast) networks or terrestrial broadcast networks can be considered as such unidirectional networks.

[0609] Multicast ABR content and configuration information received by the multicast gateway and multicast rendezvous service can be transmitted to the content playback function via HTTP or other means provided by interface L, and the multicast gateway can function as a server for the home broadcast (HB) network.

[0610] Interfaces L and B can be configured in the content playback function of the device or HB network. Media stream transmission can be received via interface L through the multicast gateway, and initial access information from the multicast gateway can be received via interface B. Here, when the multicast gateway and multicast rendezvous service are configured in the same device, interfaces L and B can be replaced by internal interfaces of the device.

[0611] After a list of services that can provide 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 can deliver it to the multicast gateway via interface M.

[0612] Figure 42 An example of an interface configuration according to an implementation method is shown.

[0613] according to Figure 41 The M-interface of the implementation shown is configured as follows.

[0614] Based on the M-interface, which includes a unidirectional link, the method / apparatus implemented according to the method can perform unidirectional delivery. In this case, the unidirectional link can be configured with a satellite channel, the physical layer can be configured with DVB-S2 or DVB-S2X, and the data link layer can be configured with DVB-GSE.

[0615] When a multicast server sends a multicast transmission session to a multicast gateway via the protocol defined in the M interface, the satellite transmitter receives the session and transmits it to the satellite receiver over the satellite channel. The satellite receiver then delivers the session to the multicast gateway according to the protocol defined in the M interface. When a multicast transmission session is transmitted over the satellite channel, it can be multiplexed into a single signaling message. To demultiplex the multicast transmission session and deliver it to the multicast gateway, the multicast transmission session can be mapped to an IP multicast transmitted over the satellite channel. In this case, data link layer signaling can be used to map the multicast transmission session.

[0616] Figure 43 An example of an interface configuration according to an implementation method is shown.

[0617] Based on the M-interface including a unidirectional link, the method / apparatus according to the implementation can perform unidirectional delivery. In this case, the unidirectional link can be configured with a broadcast channel, the physical layer can be configured with DVB-T2, and the data link layer can be configured with DVB-GSE.

[0618] When a multicast server sends a multicast transmission session to a multicast gateway via the protocol defined in the M interface, the broadcast transmitter receives the session and transmits it to the broadcast receiver on the broadcast channel. The broadcast receiver delivers the session to the multicast gateway according to the protocol defined in the M interface. When a multicast transmission session is transmitted on the broadcast channel, it can be multiplexed into a single signaling message. To demultiplex the multicast transmission session and deliver it to the multicast gateway, the multicast transmission session can be mapped to an IP multicast sent on the broadcast channel. In this case, data link layer signaling can be used to map the multicast transmission session.

[0619] According to the implementation method, DVB-DASH-based services according to ETSI TS103 285 can be included in the DVB-I service list. DVB-NIP DVB-DASH-based services can be carried on the DVB broadcast network defined in ETSI TS103 769 using the FLUTE / ROUTE protocol defined by DVB-MABR.

[0620] Signaling and A / V services are carried over the broadcast RF channel via IP multicast (using DVB-DASH ETSI TS103285). DVB-NIP IP multicast sessions are carried at the data link layer using the GSE-Lite profile as defined in Clause D.2 of ETSI TS102 606-1 or multiprotocol encapsulation as defined in ETSI EN 301 192. Alternatively, DVB-S2X (ETSI 302307-1, ETSI 302 307-2), DVB-S2 (ETSI 302 307-1), and DVB-T2 (ETSI TS102 755) can be used at the physical layer.

[0621] Figure 44 An example of a link control data (LCD) configuration according to an implementation method is shown.

[0622] Based on the logical layer control structure of the multicast transmission session mapping according to the implementation method, the method / apparatus according to the implementation method can perform one-way delivery.

[0623] GSE-LLC structure

[0624] In the configuration for interface M according to the implementation, DVB-GSE LLC (Logical Layer Control) is used as an implementation of the method of mapping multicast transmission sessions using data link layer signaling.

[0625] DVB-GSE LLC consists of Link Control Data (LCD) and Network Control Data (NCD).

[0626] LCD syntax can be as follows Figure 44 The configuration shown.

[0627] PHY_descriptors() - Descriptors for the physical layer modulation system.

[0628] number_of_links - Indicates the number of links or physical streams included in the modulation system of the physical layer.

[0629] link_id - Identifier of the physical link included in the modulation system of the physical layer.

[0630] link_association_descriptors() can be configured as described below.

[0631] Figure 45 Link-related descriptors according to an implementation method are illustrated.

[0632] modulation_system_type - Indicates the type of broadcast modulation system. For example, it can be encoded as follows.

[0633] 0x00-DVB-S2 / S2X

[0634] 0x01-DVB-T2

[0635] modulation_system_id - A unique identifier for the modulation system.

[0636] PHY_stream_id - This can be encoded according to modulation_system_type as follows:

[0637] modulation_system_type = 0x00 - DVB - Input Stream Identifier (ISI) for S2 / S2X

[0638] modulation_system_type = 0x01-DVB-T2 physical layer channel

[0639] NCD can be configured as described below.

[0640] Figure 46 Network control data (NCD) according to an implementation method is illustrated.

[0641] In the NCD structure, platform_descriptor(), target_descriptor(), and operational_descriptor can be defined for each signaling destination.

[0642] Regarding `target_descriptors()`, when the GSE only has IP address information, it can handle multicast according to the implementation method. Therefore, `target_descriptors()` according to the implementation method can solve the problem by including information for multicast identification.

[0643] In the NCD structure, platform_descriptor(), target_descriptor(), and operational_descriptor can be defined for each signaling destination.

[0644] Figure 47 A multicast transmission session according to an implementation method is illustrated.

[0645] The method / apparatus according to the implementation can perform transport session mapping based on multicast transport sessions.

[0646] like Figure 47 As shown, a multicast transmission session can be defined from the multicast server.

[0647] Multicast transmission sessions sent from a multicast server can be mapped to IP multicast streams by a one-way delivery transmitter (satellite transmitter) and the IP multicast stream information can be carried to a one-way delivery receiver (satellite receiver).

[0648] Figure 48 An example of an mABR IPv6 transport session descriptor according to an implementation is shown.

[0649] When the method / apparatus according to the implementation method transmits a multicast transmission session via IPv6, the target descriptor may include, for example: Figure 48 The descriptor shown.

[0650] descriptor_tag - The identifier that corresponds to the descriptor.

[0651] descriptor_length - Indicates the length of the descriptor.

[0652] multicast_transport_session_id_length - Indicates the length in bytes of the following multicast_transport_session_id.

[0653] multicast_transport_session_id - A unique identifier for the multicast transport session. It has the same value as the id included in the multicast ABR session configuration.

[0654] source_IPv6_address - Indicates the source IP address of the current multicast transmission session sent via IPv6.

[0655] destination_IPv6_address - Indicates the group (destination) IP address of the current multicast transmission session sent via IPv6.

[0656] source_UDP_port - Indicates the source UDP port of the current multicast transport session.

[0657] destination_UDP_port - Indicates the destination UDP port of the current multicast transport session.

[0658] Multicast can be supported by defining the source_UDP_port and destination_UDP_port in the GSE-related descriptors, depending on the implementation method / device.

[0659] A transport session descriptor can be called a multicast list descriptor and may also include the following information.

[0660] num_multicasts: This is a 16-bit field that indicates the number of multicasts.

[0661] multicast_stream_id: This is a 16-bit field that uniquely identifies the IP / UDP multicast stream within the physical link identified by link_id.

[0662] source_ip_address: This is a 32-bit field that indicates the source IPv4 address of the multicast carried on the physical link identified by link_id.

[0663] destination_ip_address: This is a 32-bit field that indicates the destination IPv4 address of the multicast carried on the physical link identified by link_id.

[0664] source_port: This is a 16-bit field that indicates the source UDP port number of the multicast carried on the physical link identified by link_id.

[0665] destination_port: This is a 16-bit field that indicates the destination UDP port number of the multicast carried on the physical link identified by link_id.

[0666] `header_compression_flag`: This is a 1-bit Boolean field that indicates whether header compression is applied to the multicast stream identified by `multicast_stream_id`. 0 (zero) indicates that the multicast stream is delivered from the DVB-GSE layer without header compression. 1 (one) indicates that header compression is applied to the multicast stream from the DVB-GSE layer. When `compressed_flag` equals 1, the ROHC-U descriptor or ROHC-U_multicast_descriptor is notified by a signal.

[0667] reserved_for_future_use: This is a 7-bit field reserved for future use, and all its bits should be set to 0.

[0668] Figure 49 An example of an mABR IPv4 transport session descriptor according to an implementation is shown.

[0669] When sending a multicast transmission session via IPv4, the method / apparatus according to the implementation may include, in the target descriptor, items such as... Figure 49 The descriptor shown.

[0670] descriptor_tag - The identifier that corresponds to the descriptor.

[0671] descriptor_length - Indicates the length of the descriptor.

[0672] multicast_transport_session_id_length - Indicates the length in bytes of the following multicast_transport_session_id.

[0673] multicast_transport_session_id - A unique identifier for the multicast transport session. It has the same value as the id included in the multicast ABR session configuration.

[0674] source_IPv6_address - Indicates the source IP address of the current multicast transmission session sent via IPv4.

[0675] destination_IPv6_address - Indicates the group (destination) IP address of the current multicast transmission session sent via IPv4.

[0676] source_UDP_port - Indicates the source UDP port of the current multicast transport session.

[0677] destination_UDP_port - Indicates the destination UDP port of the current multicast transport session.

[0678] When multiple multicast transport sessions are mapped to a single link, multiple mABR_IPv6_transport_session_descriptor() or mABR_IPv4_transport_session_descriptor() can be included in the NCD loop.

[0679] A transport session descriptor can be called a multicast list descriptor and may also include the following information.

[0680] num_multicasts: This is a 16-bit field that indicates the number of subsequent multicasts.

[0681] multicast_stream_id: This is a 16-bit field that uniquely identifies the IP / UDP multicast stream within the physical link identified by link_id.

[0682] source_ip_address: This is a 128-bit field that indicates the source IPv6 address of the multicast carried on the physical link identified by link_id.

[0683] destination_ip_address: This is a 128-bit field that indicates the destination IPv6 address of the multicast carried on the physical link identified by link_id.

[0684] source_port: This is a 16-bit field that indicates the source UDP port number of the multicast carried on the physical link identified by link_id.

[0685] destination_port: This is a 16-bit field that indicates the destination UDP port number of the multicast carried on the physical link identified by link_id.

[0686] `header_compression_flag`: This is a 1-bit Boolean field that indicates whether header compression is applied to the multicast stream identified by `multicast_stream_id`. 0 (zero) indicates that the multicast stream is delivered from the DVB-GSE layer without header compression. 1 (one) indicates that header compression is applied to the multicast stream from the DVB-GSE layer. When `compressed_flag` equals 1, the ROHC-U descriptor or ROHC-U_multicast_descriptor is notified by a signal.

[0687] reserved_for_future_use: This is a 7-bit field reserved for future use, and all its bits should be set to 0.

[0688] Figure 48 and Figure 49 The multicast list descriptor conveys a list of multicast packets carried on the physical link. This descriptor conveys a list of IPv4 multicast packets carried on the physical link and provides information for processing UDP / IPv4 packets carrying multicast packets in the DVB-GSE layer. Additionally, this descriptor conveys a list of IPv6 multicast packets carried on the physical link and provides information for processing UDP / IPv6 packets carrying multicast packets in the DVB-GSE layer.

[0689] Figure 50 An example of a structure for a 5G-based system service according to an implementation method is shown.

[0690] The method / device according to the implementation method can be associated with the 5G system architecture as follows.

[0691] A 5G system can consist of the following network functions (NFs).

[0692] The abbreviations for the implementation are as follows: Authentication Server Function (AUSF), Core Access and Mobility Management Function (AMF), Data Network (DN) (e.g., operator service, Internet access, or third-party service), Structured Data Storage Network Function (SDSF), Unstructured Data Storage Network Function (UDSF), Network Open Function (NEF), NF Library Function (NRF), Policy Control Function (PCF), Session Management Function (SMF), Unified Data Management (UDM), User Plane Function (UPF), Application Function (AF), User Equipment (UE), and (Radio) Access Network ((R)AN).

[0693] The architecture of a 5G system in non-roaming scenarios is shown as a service-based interface. User plane data is transmitted via DN, UPF, (R)AN, and UE, and other functions can process control plane data.

[0694] Here, the service-based interfaces are defined as follows: Namf: Service-based interface presented by AMF. Nsmf: Service-based interface presented by SMF. Nnef: Service-based interface presented by NEF. Npcf: Service-based interface presented by PCF. Nudm: Service-based interface presented by UDM. Naf: Service-based interface presented by AF. Nnrf: Service-based interface presented by NRF. Nausf: Service-based interface presented by AUSF.

[0695] Figure 51 An example of a 5G system architecture in a reference point representation according to an implementation method is shown.

[0696] Figure 51 The architecture of a 5G system in a non-roaming scenario is shown using reference points that indicate how multiple network functions interact.

[0697] User plane data is transmitted via DN, UPF, (R)AN, and UE, and other functions can process control plane data. Therefore, data can be transmitted via N6 and N3, which are reference points between corresponding functions, and (R)AN and UE can be wirelessly connected.

[0698] Here, reference points can be defined as follows: N1: Reference point between UE and AMF. N2: Reference point between (R)AN and AMF. N3: Reference point between (R)AN and UPF. N4: Reference point between SMF and UPF. N5: Reference point between PCF and AF. N6: Reference point between UPF and data network. N7: Reference point between SMF and PCF. N7r: Reference point between PCF in the access network and PCF in the home network. N8: Reference point between UDM and AMF. N9: Reference point between two core UPFs. N10: Reference point between UDM and SMF. N11: Reference point between AMF and SMF. N12: Reference point between AMF and AUSF. N13: Reference point between UDM and Authentication Server Function (AUSF). N14: Reference point between two AMFs. N15: Reference point between PCF and AMF in non-roaming scenarios, and between PCF and AMF in the access network in roaming scenarios. N16: Reference point between two SMFs (in roaming situations, between an SMF in the access network and an SMF in the home network). N17: Reference point between an AMF and an EIR. N18: Reference point between any NF and a UDSF. N19: Reference point between a NEF and an SDSF.

[0699] The reference points listed above can be defined by individual protocols or via messages with unique identifiers on a public protocol. For this purpose, the control plane interface can be physically shared with other reference points, and reference points can be identified using each protocol or message set.

[0700] Figure 52 An example of a 5G system architecture for multiple PDU sessions according to an implementation method is illustrated.

[0701] Figure 51 The diagram illustrates a network architecture for supporting two DNs based on the aforementioned 5G system architecture. To access a DN, the DN's UPF and SMF can be configured separately. These functions can be connected to control plane functions via corresponding reference points. Therefore, each DN can provide a separate PDU session, and the SMF can control the session.

[0702] Although Figure 52 This example illustrates simultaneous access to two or more DNs (data networks), but access to two or more DNs can be configured according to the network setup.

[0703] Figure 53 An example of a 5G system architecture for access coexisting in two data networks, according to an embodiment, is illustrated.

[0704] Figure 53 You can follow a PDU session option.

[0705] Figure 53 An example is shown of a network architecture configured in a structure connected to two DNs such that the PDU sessions provided by each DN can operate as a single session using a single SMF.

[0706] For this network structure, it can be as follows: Figure 54 The diagram shows the definition of the user plane protocol stack for a PDU session.

[0707] Figure 54 An example of a user plane protocol stack according to an implementation method is shown.

[0708] PDU Layer: This layer corresponds to the PDU delivered between the UE and the DN via a PDU session. When the PDU session type is IPv6, this layer corresponds to IPv6 packets. When the PDU session type is Ethernet, this layer corresponds to Ethernet frames.

[0709] 5G Encapsulation: This layer supports multiplexing services (which can correspond to different PDU session types) via N3 (i.e., between AN and 5GC) or N9 (i.e., between different UPFs of 5GC). It provides encapsulation at the PDU session level. This layer also performs QoS flow-related marking.

[0710] AN Protocol Stack: This set of protocols / layers is AN-specific. When the AN is a 3GPP RAN, the protocols / layers are defined by the 3GPP RAN.

[0711] The number of UPFs on a data path is not limited by the 3GPP specification. It can be on the data path of PDU sessions 0 and 1 that do not support PDU session anchoring functionality for PDU sessions, or it can be multiple UPFs. In the case of IP, the UPF used as the PDU session anchor in a type PDU session refers to the IP anchor point assigned to the UE's IP address / prefix.

[0712] For the above 5G architecture, each function is defined as follows.

[0713] Access and Mobility Management Function (AMF)

[0714] The Access and Mobility Management Function (AMF) can include the following functions. A single AMF instance can support all or some of the following functions: RAN CP interface termination (N2); NAS (N1) termination; NAS encryption and integrity protection; registration management; connection management; accessibility management; mobility management; lawful interception (interface for AMF events and LI systems); SM message transmission between the UE and the SMF. It provides a transparent proxy for SM message routing, access authentication, access authorization, and SMS message transmission between the UE and the SMSF. Security Anchor Function (SEA). It interacts with the AFSF and the UE and receives an intermediate key established as a result of the UE authentication process. For USIM-based authentication, the AMF retrieves security data from the AFSF. Security Context Management (SCM). The SCM receives a key from the SEA, which is used to obtain a network-specific key for access.

[0715] In addition, AMF can include the following functions to support non-3GPP access networks.

[0716] Supports interfaces N3IWF and N2. Information (e.g., 3GPP cell identifier) ​​and procedures (e.g., handover-related procedures) defined via 3GPP access through these interfaces may not be applied, and non-3GPP access-specific information that is not applicable to 3GPP access may be applied.

[0717] NAS signaling with the UE is supported via N3IWF. Some procedures supported by NAS signaling for 3GPP access may not be applicable to unreliable non-3GPP access (e.g., paging).

[0718] Supports authentication for UEs connected via N3IWF. Provides mobility, authentication, and separate security context state management for UEs connected via non-3GPP access or simultaneously via 3GPP and non-3GPP access. Supports effective coordination of RM management contexts for both 3GPP and non-3GPP access. Supports dedicated CM management contexts for UEs connected via non-3GPP access. Session Management Function (SMF).

[0719] Session Management Functions (SMF) can include the following features. A single SMF instance can support all or some of these features:

[0720] Session management (e.g., session establishment, modification, and release) includes: tunnel maintenance between the UPF and AN nodes; UEIP address assignment and management (including optional authorization); selection and control of UP functions; UPF configuration of service control to route services to appropriate targets; termination of interfaces to policy control functions; control over some aspects of policy enforcement and QoS; lawful interception (for SM events and LI system interfaces); termination of the SM portion of NAS messages; downlink data notification; initiator of AN-specific SM information sent to the AN via the N2 through the AMF; determination of the SSC mode of the session; roaming functions: it handles local implementation to apply QoS SLA (VPLMN); charging data ingestion and charging interface (VPLMN); lawful interception (for SM events and LI system interfaces in the VPLMN); and support for interaction with external DNs for signaling of PDU session authorization / authentication by external DNs.

[0721] User-Face Functionality (UPF)

[0722] A user-defined UPF can include the following functionalities. A single UPF instance can support all or some of these functionalities:

[0723] Anchor points for intra-RAT / inter-RAT mobility (if applicable), which are external PDU session points for interconnection to the data network; packet routing and forwarding; packet inspection and user plane portion of policy rule enforcement; lawful ingestion (UP ingestion); service usage reporting; support for routing service flows to uplink classifiers in the data network; branch points supporting multi-family PDU sessions; QoS processing for the user plane (e.g., packet filtering, gating, UL / DL rate enforcement); uplink service verification (SDF to QoS flow mapping); transport-level packet indication for uplink and downlink; downlink packet buffering and downlink data notification triggering.

[0724] Policy Function (PCF)

[0725] PCF can include the following functions.

[0726] It supports a unified policy framework for controlling network behavior. It provides control plane functionality for applying policy rules. It implements a front-end that accesses subscription information related to policy decisions in the User Database (UDR).

[0727] Network Open Function (NEF)

[0728] NEF can include the following functionalities.

[0729] It provides means for securely exposing services and functions provided by 3GPP network functions to third parties, internal exposure / re-exposure, application functions, and edge computing, as described in Section 5.13.

[0730] The NEF receives information from another network function (based on the exposure function of other network functions). It can use a standardized interface for data storage network functions (the interface to be defined in 3GPP) to store the received information as structured data. The stored information can then be "re-exposed" by the NEF to other network functions and application functions, and used for other purposes (such as analysis).

[0731] NF Library Functionality (NRF)

[0732] NRF can include the following functions.

[0733] It supports service retrieval functionality. It receives NF discovery requests from NF instances and provides NF instances with information about discovered (or yet to be discovered) NF instances. It maintains information about available NF instances and supporting services.

[0734] Figure 55 An example of Unified Data Management (UDM) according to an implementation method is given.

[0735] UDM can be divided into Application Front End (FE) and User Database (UDR).

[0736] Figure 55 A reference architecture for a UDM is shown, which may include the following FEs.

[0737] UDM FE: Responsible for credential processing, location management, subscription management, etc.

[0738] PCF: Responsible for policy control. PCF is not part of UDM, as it is a separate network function within the overall 5GC architecture. However, PCF can request and provide policy subscription information to UDR. Therefore, it is exposed within the UDM architecture.

[0739] The UDR stores the data required for the functions provided by the UDM-FE and the policy profiles required by the PCF. The data stored in the UDR includes:

[0740] Subscription identifier; security credentials; user subscription data including access and mobility-related subscription data and session-related subscription data; and policy data. The UDM-FE accesses the subscription information stored in the UDR and supports the following functions.

[0741] It handles authentication credentials, user identification, access granting, registration / mobility management, subscription management, SMS management, and FE application logic, without requiring an internal UDR. Multiple different FEs can provide services to the same user in different transactions.

[0742] The N25 / Nudr reference point / interface is defined for the frontend to read, update (including add, modify), delete, subscribe to data change notifications, and notify the UDR of data changes. N25 is the name of the P2P reference point, and Nudr is the name of the service-based interface. Both the FE and UDR reside in the HPLMN.

[0743] Authentication Server Function (AUSF)

[0744] AUSF supports the following functions. AUSF is supported.

[0745] Application Functionality (AF)

[0746] An AF (Application Function) interacts with the 3GPP core network to provide services. For example, it supports: application impact on service routing; access to network functions; and interaction with policy frameworks used for policy control. Based on operator deployment, AFs deemed trustworthy by the operator can directly interact with relevant network functions. AFs that do not allow direct operator access to network functions should use an external open framework via NEF (Network Function Framework) to interact with relevant network functions.

[0747] Figure 56 An architecture for 5G media streaming transmission according to an implementation method is illustrated.

[0748] 5G downlink media stream transmission within a 5G system

[0749] Figure 56 An architecture for configuring downlink media streaming capabilities in a 5G network is illustrated.

[0750] exist Figure 56 In this architecture, for 5G media stream transmission, the UE is configured with a 5GMSd awareness application and a 5GMSd client, and can configure 5GMSd AF and 5GMSd AS in the data network (DN). Here, when the DN is configured in a network operated by a mobile network operator, it can be considered a trusted DN. When the DN is configured outside the mobile network operator, it can be considered an external DN (e.g., a third-party CDN). Other functions and interfaces are further described in Appendix A.

[0751] Figure 57 A media architecture for unicast downlink media stream transmission according to an embodiment is illustrated.

[0752] For the network architecture described above, the media architecture for unicast downlink media stream transmission can be defined as follows. Here, each function and interface defines the logical interface for media stream transmission.

[0753] Define the following functions:

[0754] The 5GMSd client on the UE (5G media streaming client for downlink): a receiver for the 5GMS downlink media streaming service that can be accessed through explicitly defined interfaces / APIs. Alternatively, the UE can be implemented in a self-contained manner, so that interfaces M6d and M7d are not exposed at all.

[0755] The 5GMSd client includes two sub-functions:

[0756] Media Session Processor: Functions on the UE that communicate with the 5GMSd AF to establish, control, and support the delivery of media sessions. The Media Session Processor can expose APIs that can be used by 5GMSd-aware applications.

[0757] Media Player: A device on the UE that communicates with the 5GMSd AS to stream media content and provides API functionality to 5GMSd-aware applications for media playback and media session processors for media session control.

[0758] 5GMSd-aware applications: 5GMSd clients are typically controlled by external media applications (e.g., apps) that implement specific logic for the external application or content service provider and enable the establishment of media sessions. 5GMSd-aware applications are not defined within the 5G media streaming specification, but this functionality utilizes 5GMSd clients and network functions that use 5GMSd interfaces and APIs.

[0759] 5GMSd AS: An application server that hosts 5G media functions. Note that different implementations of 5GMSd AS may exist (e.g., Content Delivery Network (CDN)).

[0760] 5GMSd application providers: external applications or content-specific media functions (e.g., media creation, encoding, and formatting using 5GMSd to stream media to 5GMSd-aware applications).

[0761] 5GMSd AF: An application function that provides various control functions to the media session handler and / or 5GMSd application provider on the UE. It can relay or initiate requests for different policy or charging function (PCF) processing, or interact with other network functions via NEF.

[0762] The interface used for 5G downlink media stream transmission can be defined as follows.

[0763] M1d (API provided by 5GMSd): An external API exposed by 5GMSd AF to provide access to 5G media streaming systems and to obtain feedback.

[0764] M2d (5GMSd Ingestion API): An optional external API exposed by the 5GMSd AS used when selecting a trusted DN to host content for streaming services.

[0765] M3d: (Internal): Internal API used to exchange information for content hosting on the 5GMSd AS within the Trusted DN.

[0766] M4d (Media Streaming API): The 5GMSd AS exposes an API to media players for streaming media content.

[0767] M5d (Media Session Processing API): An API exposed by 5GMSd AF to media session processors for media session processing, control, and assistance, including appropriate security mechanisms such as authorization and authentication.

[0768] M6d (UE Media Session Processing API): An API exposed by the Media Session Processing side to the media player for client-internal communication, and this API is exposed to 5GMSd-aware applications, enabling them to utilize 5GMS functionality.

[0769] M7d (UE Media Player API): An API exposed by the media player to 5GMSd-aware applications and media session processors to utilize the media player.

[0770] M8d: (Application API): An application interface used for information exchange between 5GMSd sensing applications and 5GMSd application providers, for example, to provide service access information to 5GMSd sensing applications. This API is outside the 5G system and is not specified by 5GMS.

[0771] Multicast Adaptive Bit Rate System Architecture

[0772] The method / apparatus according to the implementation can be linked to the multicast adaptive bit rate system architecture described below.

[0773] Figure 58 A reference architecture according to an implementation is shown.

[0774] Reference point:

[0775] exist Figure 58 In the reference architecture, the relationships between logical functions can be defined by a reference point. When this architecture is actually deployed, they can be implemented through specific interfaces, and necessary information can be exchanged between related functions using specific protocols.

[0776] Data reference points:

[0777] In the above architecture, the following reference points are used to transmit content.

[0778] L: Performs unicast HTTP (and HTTPS) interactions between the content playback function and the multicast gateway. This interface includes fetching of all specified content types.

[0779] When the multicast gateway and content playback functionality are both located on a single terminal device such as a set-top box, interface L can be implemented as a local API.

[0780] B: Responsible for directing unicast HTTP interactions between the content playback function and the multicast rendezvous service. Used to request the presentation manifest at the start of a linear playback session.

[0781] A: HTTP retrieval of content hosting functionality from content not provided at reference point M.

[0782] The content playback function is used to retrieve content outside the range of reference point L.

[0783] In some deployments, the unicast repair service is used to retrieve content from the content hosting function, thereby enabling content repair.

[0784] When U is unable to perform content repair, it is also used by the multicast gateway to retrieve the content directly from the content hosting function via unicast.

[0785] M: Responsible for multicast IP content transmission via multicast server function and reception via multicast gateway function, and in some deployments, reception via unicast repair service function.

[0786] U: Responsible for unicast interactions between unicast repair clients and unicast repair services within the multicast gateway. In addition to requesting payloads used for content repair functionality, this interface can also be used to carry such payloads.

[0787] U': As an alternative to obtaining repaired content via A, it handles unicast interactions between the unicast repair service and the multicast server. In addition to requesting payloads used for content repair functionality, this interface can also be used to carry such payloads.

[0788] Pin: The content encapsulation sub-function publishes content to the content hosting function. This can be implemented as a push interface, or content can be pulled from the content encapsulation function on demand.

[0789] Oin: Content is ingested from the content hosting function by the multicast server function. This is typically implemented as a pull interface.

[0790] Pin: The multicast server directly ingests content from the content encapsulation function. This is typically implemented as a push interface.

[0791] Control Surface Reference Point

[0792] In the above architecture, the following reference points are defined for the transmission of control signaling and operation report information.

[0793] CMS: A control interface for configuring multicast server functionality.

[0794] CMR: Control interface used for configuring multicast gateway functions.

[0795] CCP: Control interface used for configuring supply functions.

[0796] RS: Service report sent from the multicast gateway function to the service report capture function.

[0797] RCP: Service reporting from the service report capture sub-function to the content provider's metric report capture function.

[0798] RPM: A metric report capture function that sends playback metric reports to the content provider via the content playback function.

[0799] Figure 59 A reference architecture according to an implementation is shown.

[0800] Reference architecture diagram:

[0801] Figure 29 A detailed diagram of the reference architecture is shown.

[0802] The architecture includes the following features.

[0803] Content preparation

[0804] Content Encoding

[0805] Content encoding transforms the source media stream into encoded media to reduce the bit rate. A single source media stream can be transformed into multiple different encoded representations to match delivery conditions. Virtual segmentation boundary markers can be placed in the encoded media representation to help the content playback function adapt to delivery conditions.

[0806] The encoder's output is a plaintext stream formatted for transmission to encryption or encapsulation functions. For example, it can be an MPEG elementary stream, MPEG-2 TS, or an intermediate format for similar purposes.

[0807] Content Encryption

[0808] The content encryption feature takes a plaintext stream as input and encrypts it to form a ciphertext stream. The encryption key can be obtained from the DRM license management feature.

[0809] Content encapsulation

[0810] The content encapsulation function ingests one or more coded representations and organizes the data according to the desired encapsulation format. In the context of dynamic adaptive streaming, the encapsulator's output is a sequence of encapsulated media segments with representation switching points aligned across different representations of the same source media stream. Examples of encapsulation formats can include ISO Basic Media File Format (MP4) and Segmented MPEG-2 TS.

[0811] Content hosting

[0812] The prepared content is provided by the content hosting feature for:

[0813] Unicast delivery to the multicast server corresponds to content ingestion via Oin;

[0814] Unicast repair service via interface A to multicast gateway - for cache misses via interface A;

[0815] Content playback functionality without multicast receiver connection - transmitted via interface B.

[0816] Content hosting functionality can be implemented as a simple web server (as part of the original cluster) or as a distributed CDN. In this way, load balancing and request distribution techniques (such as DNS round-robin and HTTP 302 redirects) can be used to allow clients to receive content from the appropriate content server.

[0817] multicast server

[0818] The multicast server function ingests content from content sources. That is, media streams can be input to interface Oin. Typically, the protocol used by the media player can be used. In the multicast server, the payload of the ingested media stream is encapsulated in a delivery unit of the multicast transport protocol and sent over the network. They are sent via interface M using IP multicast to subscribed multicast gateway clients. This entity can be configured based on configuration information received from the network control function via interface CMS.

[0819] Content intake

[0820] Both push and pull content ingestion methods can be used on multicast servers:

[0821] Ingestion via HTTP pull from interface Oin:

[0822] It is similar to a regular adaptive streaming media player and downloads encapsulated media segments from the content hosting function based on the description in the presentation manifest. In this case, the interface Oin can be functionally identical to interface L, although its operational details may differ. MPEG-DASH or HLS can be used to encapsulate the segments. Segments from one or more representations described in the presentation manifest can be downloaded simultaneously. DVB DASH, MPEG-DASH, HLS, and other manifest formats are supported.

[0823] HTTP push ingestion via the Pin interface:

[0824] It can provide HTTP push interfaces, such as WebDAV (Web Distributed Authorization and Versioning). The content encapsulation sub-function uploads media segments to the content ingestion function immediately upon creation. Segments can be encapsulated in formats such as MPEG-DAH or HLS.

[0825] Ingestion via RTP push through the Pin interface:

[0826] It provides an RTP-based push-in mechanism to the content encapsulation sub-function. The encapsulator uses RTP to send MPEG-2TS packets. Segment boundaries are marked with virtual segment boundary markers.

[0827] Multicast transmission

[0828] This function is responsible for sending the stream received by the content ingestion subfunction in the payload of IP multicast packets via interface M.

[0829] Unicast Repair Service

[0830] The unicast repair service provides payload repair functionality to the unicast repair clients in the multicast gateway via reference point U. The following repair modes can be considered.

[0831] The unicast repair service receives multicast content sent through reference point M and locally caches copies of the packet stream to satisfy repair requests from unicast repair clients.

[0832] If the requested packet cannot be satisfied from the cache of the unicast repair service, the packet repair request can be passed to the multicast server via interface U'.

[0833] Group repair requests can be converted by the unicast repair service into HTTP requests made on the content hosting function using the same interface as reference point A.

[0834] If requests for the same repair are received from multiple multicast gateways, it may be more efficient to send repair packets via reference point M.

[0835] Multicast gateway

[0836] The primary purpose of a multicast gateway is to provide segmented encapsulated content to content playback functionality. A multicast gateway can be implemented as a forwarding proxy or as a local source including a reverse proxy. Multicast gateways can be instantiated in user premises equipment such as home gateway devices or IP-connected set-top boxes (STBs). It can also be located in upstream network nodes as an alternative to user premises equipment.

[0837] Content requests are received from one or more instances of the content playback function via interface L. For the requested content, the content is either directly served in the cache within the asset storage subfunction or indirectly served via interface A. In this case, the content obtained via interface A may optionally be cached in the asset storage subfunction.

[0838] Service Management

[0839] The service management sub-function can collect multicast session configuration information and the location of the service report capture function regarding multicast content streams that can be received via interface M. This information can be received as follows:

[0840] Control functions directly from the network via the CMR interface;

[0841] Indirectly via the multicast receiving sub-function (in the case of sending information via interface M);

[0842] In the unicast response delivered from the content hosting function via interface A.

[0843] Multicast reception

[0844] The multicast receive subfunction receives content streams requested or configured by terminal devices via interface M. Fully received content can also be cached in the asset storage for later use. Before the multicast gateway caches content corrupted in transit, any specified mechanism (e.g., forward error correction, unicast repair via U, or unicast retrieval via A) can be used to repair content corrupted in transit. Non-negligible content should not be served via interface L.

[0845] Unicast Repair Client

[0846] Perform multicast packet loss detection and recover lost packets using forward error correction information received via interface M or unicast repair services (e.g., unicast packet retransmission or multicast segment loss signaling) via interface U. For packets that are not recovered in this manner, unicast transmission via interface A can be used.

[0847] Asset storage

[0848] The asset storage sub-function provides temporary storage for assets to be served via interface L. This storage function is performed solely by the multicast gateway.

[0849] Manage pre-positioned media content assets. For example, all or part of popular content or advertising-related information can be pre-stored before it is actually available to multiple users.

[0850] Temporary cache for linear media content segments.

[0851] Service Report

[0852] Service-related metrics (e.g., telemetry and analytics data) are reported by the service reporting subfunction to the service reporting capture subfunction via the interface RS.

[0853] supply

[0854] The purpose of the supply function is:

[0855] Centrally collect service report information from deployed multicast gateway instances; configure resources in the network; configure multicast servers to use the configured network resources; configure multicast gateways to use the configured network resources.

[0856] The provisioning function can be linked to the content provider's control function based on information delivered via the interface CCP.

[0857] Service report capture

[0858] Service report information captured by the multicast gateway is supplied to the service report capture function via the interface RS. Reports may include metrics describing service performance (e.g., cache hit rate, viewership) and other key indicators. Metrics may depend on which channels are requested, when channels are established, and how many segments are in the cache. Service report information can be used to improve service performance or configure multicast channels.

[0859] The service report capture function can export service report information to the content provider's metric report capture function via the RCP interface. This information (such as multicast content and bitrate) can be included in the report information.

[0860] Network control

[0861] Network control functions can perform functions such as controlling, configuring, and providing network resources. This can include resources for multicast transmissions via interface M and unicast operations via interfaces U and A.

[0862] In a centralized system, network control functions can distribute configuration information about available multicast streams to network resources, and can also send this configuration information to the multicast server via the CMS interface or to the multicast gateway via the CMR interface. The configuration information about available multicast streams can be updated based on content provider control policy rules and / or the number of client requests.

[0863] Content provider control

[0864] Content provider control functions use the CCP interface to enable network control functions to provide information about the services available via multicast delivery path M. A single content provider control function can interact with multiple network control functions, each operated by a different network provider.

[0865] Content Replay

[0866] The content playback function manages the requesting, receiving, decrypting, and rendering of content. It only supports unicast delivery via interface L. Playback operates regardless of the delivery path of the content.

[0867] Content playback functionality can be implemented independently with a multicast gateway on a terminal device such as a smartphone. Alternatively, it can be combined with a multicast gateway in, for example, a set-top box or a connected TV.

[0868] The additional features of the content playback function are:

[0869] Retrieve the presentation list for the linear service via interface B;

[0870] Retrieve any content via interface B that was not intended to be retrieved via the multicast gateway.

[0871] Content decapsulation

[0872] The content decapsulation subfunction can extract basic stream data from the acquired transport object and provide it to the content decryption and content decoding subfunctions. For example, for ISO basic media file format segments, the subfunction can extract the appropriate media data boxes. In the case of MPEG-2TS, it filters the expected PID and extracts the payload of the reassembled PES packets.

[0873] Content Decryption

[0874] If the Digital Rights Management System is active, the Content Decryption sub-function obtains the appropriate decryption key from the DRM license management function and decrypts any encrypted underlying stream.

[0875] Content Decoding

[0876] The content decoding sub-function parses and interprets the content of the basic media streams, allowing them to be rendered for playback on, for example, a screen or loudspeaker.

[0877] Playback metric report

[0878] The Playback Metrics Reporting sub-function can report information related to the behavior and quality of content playback to the content provider via the RPM interface. Metrics can include HTTP requests / responses, initial playback latency, buffer levels, indicating toggle events, and network throughput. Playback metrics reported by this function can be directly related to the Quality of End User Experience (QoE) and can be used to optimize quality in the content provider or network.

[0879] Multicast conferencing service

[0880] The multicast rendezvous service manages data records (including current multicast gateway status, multicast session status, and related data) for multiple multicast gateway instances. Network control functions can provide this relevant information to the multicast rendezvous service.

[0881] The multicast rendezvous service processes the initial request for a presentation manifest received from the content playback function via reference point B. The multicast rendezvous service determines whether an active multicast session exists for a linear service corresponding to the requested presentation manifest. It also determines whether an active multicast gateway is suitable for use by the content playback function in making the request.

[0882] If at least the second condition is met, the multicast rendezvous service can redirect the request to the multicast gateway instance. Otherwise, the multicast rendezvous service will redirect the request to the content hosting function, and the session will operate using unicast.

[0883] DRM Licensing Management

[0884] The DRM license management function provides the appropriate encryption key for the content encryption function to use for core content protection, and grants licenses to the content decryption sub-function so that the content playback function can decrypt the protected content.

[0885] application

[0886] Applications control content playback functionality. Examples may include embedded control applications (EPG applications) on TVs or set-top boxes or third-party applications contributed by content providers. The interface used by the application to control content playback typically involves delivering reference points in a presentation manifest (e.g., the URL of an MPEG DASH MPD) to initiate playback of an individual linear service. Applications may interact with the service management sub-functions of a multicast gateway to discover the existence of linear services and control the multicast gateway's reception of them. Applications may also discover the existence of linear services through private interactions with application-specific service catalog functions.

[0887] Service Catalog

[0888] Applications can use a private service catalog to find available linear services. This service catalog functionality can be configured and controlled by the content provider.

[0889] Figure 60 A multicast gateway deployment model according to an implementation method is illustrated.

[0890] In the multicast ABR architecture described above, the multicast gateway function can be implemented in various nodes within the network. Figure 60 The multicast gateway is shown as being deployed in a network edge device.

[0891] When a multicast gateway is implemented in a network edge device, the terminal device does not support receiving IP multicast from the home network. The terminal device includes content playback functionality and has an application installed to control linear playback.

[0892] The multicast gateway provides multicast-to-unicast conversion to multiple home gateway devices. Therefore, the services on the access network between the network edge device and the home gateway device are unicast.

[0893] Figure 61 An example of a multicast gateway structure deployed in a home gateway device according to an embodiment is shown.

[0894] Multicast gateways are deployed within home gateway devices (such as routers), which are typically provided by Internet Service Providers (ISPs). Additionally, multicast gateways provide multicast-to-unicast conversion capabilities to multiple end devices within the same home network. Each of these end devices has an instance of content playback functionality and the relevant applications installed on it.

[0895] Figure 62 An example of a multicast gateway structure deployed in a terminal device according to an embodiment is shown.

[0896] When a multicast gateway is implemented in a terminal device, the terminal device supports receiving IP multicast data from the home network. Each terminal device includes both a multicast gateway and content playback functionality, and loads an application to control linear playback. In this deployment model, the multicast gateway functionality will only provide content services to the host terminal device.

[0897] Home gateway devices may only perform multicast group subscription-related operations. This can lead to unpredictable quality changes when the home network does not fully support multicast delivery.

[0898] Figure 63 An example of a hybrid broadcast receiving device according to an embodiment is shown.

[0899] The receiving device according to the embodiment can be as follows: Figure 63 The diagram is shown. Each component of the receiving device according to the embodiment may correspond to hardware, software, a processor, and / or a combination thereof.

[0900] The following abbreviations are defined: 5GC: 5G Core Network; 5GMS: 5G Media Streaming; 5GMSd: 5G Media Streaming Downlink; 5GMSu: 5G Media Streaming Uplink; 5GS: 5G System; 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 Real-Time Uplink Streaming; FQDN: Fully Qualified Domain Name; GPU: Graphics Processing Unit; GSM: Global System for Mobile Communications; HPLMN: Public Land Mobile Network for Homes; HTTP: Hypertext Transfer Protocol; HTTPS: Hypertext Transfer Protocol Security; 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 Help; NEF: Network Open Function; NR: New Radio; NSMF: Network Slice Management Function; NSSAI: Network Slice Selection Help Information; NSSP: Network Slice Selection Policy; OAM: Operation, Management 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 Access Network. Service architecture; SLA: Service Level Agreement; TCP: Transmission Control Protocol; URL: Unique Resource Identifier; URSP: UE Routing Strategy; AAC: Advanced Audio Coding; ABR: Adaptive Bitrate; API: Application Programmer Interface; BMFF: Basic Media File Format; CDN: Content Delivery Network; CMAF: Common Media Application Format; CP: Content Provider; DASH: Dynamic Adaptive Streaming over HTTP; DNS: Domain Name System; DRM: Digital Rights Management; EPG: Electronic Program Guide; IGMP: Internet Group Management Protocol.IP: Internet Protocol; ISO: International Organization for Standardization; HLS: HTTP Real-Time Streaming; HTTP: Hypertext Transfer Protocol; HTTPS: Secure Hypertext Transfer Protocol; MBMS: Multimedia Broadcast Multicast Service (part of 3GPP); MPD: Media Presentation Description (part of MPEG-DASH); MPEG: Moving Picture Experts Group; OTT: Over-the-Top; PID: Packet Identifier (part of MPEG-2 Transport Streaming); 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 (part of HTTP).

[0901] The device according to the above embodiments can efficiently utilize various networks in broadcast and multicast transmissions based on the operation / configuration and / or signaling information according to the embodiments.

[0902] Furthermore, the method / apparatus according to the above embodiments can reduce network load in various streaming sessions, lower implementation costs, and efficiently provide ABR multicast services related to various networks and / or devices. To provide these effects, the architecture and processes of the embodiments are required.

[0903] Operations according to the embodiments described in this disclosure can be performed by a transmitting / receiving device including a memory and / or a processor according to the embodiments. The memory may store programs for processing / controlling the operations according to the embodiments, and the processor may control the various operations described in this specification. The processor may be referred to as a controller, etc. In the embodiments, operations may be performed by firmware, software, and / or combinations thereof. Firmware, software, and / or combinations thereof may be stored in a processor or memory.

[0904] Figure 64 illustrates the multicast GSE layer structure according to an implementation method.

[0905] The method / apparatus according to the implementation can process multicast signals through the GSE layer structure for local IP systems.

[0906] The GSE layer structure according to the implementation method may include an upper layer, a GSE layer, and a physical layer.

[0907] The upper layer can process data and pass the processed data to the GSE layer. The GSE layer can receive IP streams from the upper layer.

[0908] The GSE layer can generate GSE streams based on the streams received from the upper layer. The GSE layer can generate multiple GSE streams. GSE stream generation operations can include IP header compression, GSE-LLC descriptor generation, GSE-LLC encapsulation, encapsulation of header-compressed ROHC streams, and encapsulation of uncompressed IP streams.

[0909] This layer can receive IP data from the upper layer and may or may not compress the IP header. When the IP header is compressed, it can be compressed based on the ROHC scheme, and a ROHC-U descriptor associated with the header compression can be generated. The ROHC-U descriptor can be encapsulated together with the GSE-LLC descriptor and passed to the physical layer. The ROHC compressed stream can have values ​​from CID0 to MAX. IP header compression can be performed based on IP address information and / or port number.

[0910] GSE streams can be delivered by a PLP at the physical layer. GSE streams are delivered by a PLP with a PLP ID.

[0911] Figure 65 An example of a DVB-GSE ROHC profile and a DVB-GSE header compressor according to an embodiment is shown.

[0912] GSE-ROHC(102 606-3)

[0913] The method / apparatus according to the implementation can perform ROHC compression according to the DVB Native IP (NIP) standard. For header compression, protocols can be considered. The ROUTE / FLUTE protocol over UDP / IP can be used. RTP and ESP can also be used. The method / apparatus according to the implementation can minimize the types of protocols used for efficient protocols. Figure 65 The ROHC profile of DVB-GSE according to the profile identifier is shown.

[0914] The method / apparatus implemented according to the method can support multiple IP streams. When the ROHC compressor detects a change in the static fields of the received IP stream, the ROHC compressor can perform context reinitialization (CONTEXT_REINITIALIZATION). A new value for the CONTEXT ID (CID) can be assigned to the compressed IP stream. The new CID value can be unique in the system. This unique value may not be used by other ROHC compressors in the system.

[0915] According to DVB-GSE, the ROCH compressor and decompressor can be driven in unidirectional mode.

[0916] refer to Figure 65 The adaptive mode corresponds to the additional process following the operation of the ROHC compressor. Static chains can be extracted from IR packets, and IR packets can be converted into IR-DYN packets. Signaling data can be delivered via ROHC compressed streams.

[0917] The adaptive mode can be selected for use. Because signaling data transmission is error-resistant, separate transmission of context information may be useful across multiple PLP structures. However, in some cases, using adaptive mode is not beneficial. This is when context data and the corresponding ROHC stream are sent by the same PLP.

[0918] ROHC parameters can be generated. The maximum value of MAX_CID can be 127. The number of ROHC streams can be limited. The size of the CID field in the ROHC header can be 1 byte.

[0919] Figure 66 The ROHC-U information according to the implementation method is illustrated.

[0920] GSE-LLC(102 606-2)

[0921] The method / apparatus implemented according to the method can generate multicast (GSE stream) mapping descriptors. Multicast mapping descriptors are a new requirement. Regular descriptors cannot support methods for identifying UDP ports for GSE-LLC. Multicast link ID (GSE stream ID) mappings can be provided.

[0922] The ROHC-U descriptor is used for multiple streams and UDP, and can be used as follows: Figure 66 The generated result is shown. It can present a multicast-ROHC channel-context ID-context information mapping.

[0923] The ROHC-U descriptor, according to the implementation method, can support multiple IP streams.

[0924] A link represents a virtual network interface on a receiver. It can be associated with exactly one IP stream. Because the same data stream is available on one or more modulation system streams, a link can be associated with a modulation system stream and ROHC-U information instance specified by the modulation system type, modulation system ID, and physical stream ID. For example, it can be specified by a specific PLP in a DVB-T2 system. Because the same data is carried on the link, the receiver can freely switch between instances of a specific link.

[0925] IP Stream: A data stream can be carried over a given link. Because the same data can be obtained from various locations, an IP stream can be associated with one or more links. An IP stream can be described with parameters as targets. For example, the IP source and / or destination addresses can be described. IP streams can be described using operational parameters such as ROHC-U header compression parameters. The connection between an IP stream and a link can be established using a link ID.

[0926] The ROUC-U information for NIP includes the number of PLPs from which the number of GSE flows can be determined. It includes the PLP ID associated with the ROHC channel ID. It includes the CIDmax value and a profile of the per-channel parameters for ROHC. It includes IP flow address information for each context ID. The flow address information includes the source IP address, destination IP address, source port information, and destination port information. Context IDs and IP flow address information are mapped to each other. Context information for each context ID is included. Context information includes static chain length information and static chain byte information.

[0927] Implementations may also include NIP-specific link-layer protocols, layer architecture, selection for ROHC, and bootstrapping procedures in the link layer. IP flows not covered by ROHC can be delivered separately. Delivery options can be identified via signaling information. Bootstrapping can receive GSE flows and filter requested IP / UDP flows.

[0928] Figure 67 illustrates the transmitting and receiving devices according to an embodiment.

[0929] The device according to the embodiment may include a NIP transmitter and a MIP receiver as shown in FIG67.

[0930] The NIP transmitter can receive the DVB-I service list from the DVB-I service list server. The PLP can send the GSE stream by encapsulating the IP stream, which includes IP packets. LLC data containing descriptors and ROHC-U descriptors, including information about the GSE layer, can be generated and sent by the PLP.

[0931] The NIP transmitter can receive IP multicast from the multicast server based on a ROUTE session, and can also receive IP streams including multicast gateway configuration information. According to the implementation, ROHC streams can be generated through IP header compression.

[0932] The NIP receiver can receive GSE streams and parse IP streams. It can deliver DVB-I service lists to DVB-I clients. It can filter IP streams and forward IP multicast and multicast gateway configurations to the multicast gateway. Multicast configuration-related operations can be handled based on interface M, which serves as the reference point for the MABR.

[0933] According to the implementation method, a NIP stream can be the same as a GSE-Lite stream or an MPE stream. NIP stream is interpreted as a term referring to a stream comprising IP multicast data delivered by a DVB-NIP broadcast system.

[0934] Multicast data transmitted on broadcast channels is primarily generated by multicast servers, but can also be generated by NIP signaling servers associated with each NIP stream. Each NIP stream may have only a single connected multicast server. Multicast servers can create multicast transport sessions, each of which includes one or more multicast streams.

[0935] Figure 68 An example of a multicast transmission method according to an implementation method is shown.

[0936] S6800: The multicast transmission method according to the implementation method may include the following steps: sending a multicast signal from a multicast server based on an interface.

[0937] S6810: The multicast sending method may also include the following steps: generating information for multicast.

[0938] Figure 69 A multicast receiving method according to an implementation method is illustrated.

[0939] S6900: The multicast receiving method according to the implementation method may include the following steps: receiving multicast signals from a multicast server based on an interface.

[0940] S6910: The multicast receiving method may further include the following steps: playing the multicast service included in the multicast signal.

[0941] Based on the flowchart shown in Figure 5, Figure 6 and Figure 7 The information shown, such as information related to multicast, can be found in... Figures 1 to 4 The execution is based on the multicast ABR structure shown. Figure 68 and Figure 69 Multicast processing methods.

[0942] according to Figure 68 and Figure 69 Multicast processing methods can be based on Figures 8 to 10 as well as Figures 54 to 63 The 5G network shown is used to handle multicast signals.

[0943] according to Figure 68 and Figure 69 The multicast processing method can be based on multiple networks, as shown in Figures 11 to 26, to process multicast signals.

[0944] according to Figure 68 and Figure 69 Multicast processing methods can be based on Figures 27 to 32 The protocol and structure shown are used to process multicast signals through multiple networks.

[0945] According to Figure 68 and Figure 69 In multicast processing methods, data can be generated and sent. Figures 33 to 36 The information shown is for multicast, and the receiver can receive and play multicast media content based on the information for multicast.

[0946] According to Figure 68 and Figure 69 In the multicast processing method, multicast signals can be generated, sent and processed in the systems shown in Figures 37 to 39.

[0947] according to Figure 68 and Figure 69 Multicast processing methods may include mapping operations between multicast transport sessions and the physical layer. To process multicast signals through this inter-session mapping, in... Figure 40 , Figure 41 and Figure 47 The structure shown is configured Figure 42 and Figure 43 The protocol, and the generation, sending and receiving of protocols for... Figures 44 to 46 , Figure 48 and Figure 49 Multicast mapping information.

[0948] According to Figure 68 and Figure 69 In multicast processing methods, multicast can be handled through the GSE (link layer) structure shown in Figure 64, as follows: Figure 65 and Figure 66 The data above the compression layer is shown, and related link layer signaling information can be generated and sent. Additionally, based on... Figure 68 and Figure 69 In the multicast processing method, information indicating the relationship between GSE and PLP can be generated as shown in Figure 67, so that the receiving device can receive multicast signals and play multicast media data.

[0949] about Figure 41 The interface according to the implementation method can constitute a DVB-NIP standard broadcast system. Devices for receiving multicast signals may include: a multicast gateway configured to receive multicast signals from a multicast server via the interface; and content playback configured to display multicast services from the multicast signals. The multicast signal receiving device may receive multicast signals according to the local Internet Protocol (IP).

[0950] about Figure 42 The interface is configured according to the DVB-NIP protocol implementation. The interface may include protocols including multicast transport sessions, User Datagram Protocol / Internet Protocol (UDP / IP), Generic Stream Encapsulation (GSE) layer, and physical layer.

[0951] about Figure 48 The implementation method can generate the following signaling information. This information can be referred to as signaling information, metadata, ABR transport session descriptor, IP multicast list descriptor, etc. Logical layer control (LLC) information can be carried in the GSE layer. LLC information may include multicast descriptors, wherein the multicast descriptor may include source address information, destination address information, source UDP port information, and destination UDP port information.

[0952] Regarding Figure 64, a GSE layer can be defined for DVB-NIP. In an implementation, a physical layer channel (PLP) carrying a GSE stream can be received from the GSE layer. The GSE stream may include GSE data encapsulated with compressed IP data and IP headers, GSE data encapsulated with uncompressed IP data and IP headers, descriptors for multicast, and robust header compression (ROHC) descriptors associated with IP header compression.

[0953] about Figure 44 An LLC table for DVB-NIP can be defined. In an implementation, Logical Link Control (LLC) information can be received from the GSE layer. The Logical Link Control information may include Network Control Data (NCD) and Link Control Data (LCD). The NCD may include descriptors for multicast, and the LCD may include link identifiers for the physical layer. Therefore, mappings between sessions can be indicated, and multicast media can be received.

[0954] Regarding Figure 67, the implementation may include: a parser configured to parse LLC information; and a decompressor configured to receive a Robust Header Compression (ROHC) stream included in a GSE stream at the GSE layer and decompress the IP header.

[0955] The receiving method according to the implementation may include the following steps: receiving a multicast signal from a multicast server based on an interface; and displaying the multicast service included in the multicast signal.

[0956] The transmission method according to the implementation may include the following steps: transmitting a multicast signal from a multicast server based on an interface, wherein 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; and generating logical layer control (LLC) information in the GSE layer.

[0957] Therefore, it can resolve the issues related to the lack of link technology between terrestrial broadcasting and satellite broadcasting, as well as the lack of session information and interface configuration for multicast media transmission. In other words, to transmit DVB ABR multicast media objects in a one-way delivery network (such as the link between terrestrial broadcasting and satellite broadcasting as defined in the DVB standard), an interface and signaling stream can be provided for interworking multicast transmission sessions with broadcast streams.

[0958] The implementation methods and / or apparatus have been described, and the descriptions of the methods and apparatus can be applied to complement each other.

[0959] Although the accompanying drawings have been described separately for simplicity, new embodiments can be designed by combining the embodiments shown in the corresponding drawings. Recording media containing programs for executing the above embodiments, designed to be computer-readable by those skilled in the art, also fall within the scope of the appended claims and their equivalents. The apparatus and methods according to the embodiments are not limited to the configurations and methods of the above embodiments. Various modifications can be made to the embodiments by selectively combining all or some of the embodiments. Although preferred embodiments have been described with reference to the accompanying drawings, those skilled in the art will understand that various modifications and variations can be made to the embodiments without departing from the spirit or scope of this disclosure as described in the appended claims. These modifications should not be understood solely from the technical concept or perspective of the embodiments.

[0960] Various elements of the apparatus according to the embodiments can be implemented by hardware, software, firmware, or a combination thereof. Various elements in the embodiments can be implemented by a single chip (e.g., a single hardware circuit). According to the embodiments, the components according to the embodiments can be implemented as separate chips. According to the embodiments, at least one or more components of the apparatus according to the embodiments can include one or more processors capable of executing one or more programs. One or more programs can execute any or more of the operations / methods according to the embodiments, or include instructions for performing said operations / methods. Executable instructions for performing the methods / operations of the apparatus according to the embodiments can be stored in a non-transitory CRM or other computer program product configured to be executed by one or more processors, or can be stored in a transient CRM or other computer program product configured to be executed by one or more processors. Additionally, the memory according to the embodiments can be used as a concept encompassing not only volatile memory (e.g., RAM) but also non-volatile memory, flash memory, and PROM. Furthermore, it can also be implemented in the form of a carrier wave (e.g., transmission via the Internet). Additionally, processor-readable recording media can be distributed to computer systems connected via a network, allowing processor-readable code to be stored and executed in a distributed manner.

[0961] In this specification, the terms " / " and "," should be interpreted as meaning "and / or". For example, the expression "A / B" can mean "A and / or B". Furthermore, "A, B" can mean "A and / or B". Additionally, "A / B / C" can mean "at least one of A, B, and / or C". Furthermore, "A / B / C" can mean "at least one of A, B, and / or C". Additionally, in this specification, the term "or" should be interpreted as meaning "and / or". For example, the expression "A or B" can mean 1) only A, 2) only B, or 3) both A and B. In other words, the term "or" as used in this document should be interpreted as indicating "additionally or alternatively".

[0962] Terms such as "first" and "second" can be used to describe various elements of the embodiments. However, the various components according to the embodiments should not be limited by the above terms. These terms are only used to distinguish one element from another. For example, a first user input signal can be referred to as a second user input signal. Similarly, a second user input signal can be referred to as a first user input signal. The use of these terms should be interpreted without departing from the scope of the various embodiments. Both the first user input signal and the second user input signal are user input signals, but unless the context clearly indicates otherwise, they do not mean the same user input signal.

[0963] The terms used to describe embodiments are for the purpose of describing particular embodiments and are not intended to limit the embodiments. As used in the description of embodiments and claims, unless the context clearly indicates otherwise, the singular forms "a," "an," and "the" include plural referents. The expression "and / or" is used to include all possible combinations of terms. Terms such as "comprising" or "having" are intended to indicate the presence of drawings, numbers, steps, elements, and / or components, and should be understood to not exclude the possibility of the additional presence of drawings, numbers, steps, elements, and / or components. As used herein, conditional expressions such as "if" and "when" are not limited to optional cases and are intended to be interpreted as performing a related operation when a specific condition is met or interpreting a related definition according to a specific condition.

[0964] Operations according to the embodiments described in this disclosure can be performed by a transmitting / receiving device including a memory and / or a processor according to the embodiments. The memory may store programs for processing / controlling the operations according to the embodiments, and the processor may control the various operations described in this specification. The processor may be referred to as a controller, etc. In the embodiments, operations may be performed by firmware, software, and / or combinations thereof. Firmware, software, and / or combinations thereof may be stored in a processor or memory.

[0965] The operations according to the above embodiments can be performed by the transmitting and / or receiving devices according to the embodiments. The transmitting / receiving devices may include: a transmitter / receiver configured to transmit and receive media data; a memory configured to store instructions (program code, algorithms, flowcharts, and / or data) for processing according to the embodiments; and a processor configured to control the operation of the transmitting / receiving devices.

[0966] The processor may be referred to as a controller, etc., and may correspond to, for example, hardware, software, and / or a combination thereof. The operations according to the above embodiments can be performed by the processor. Alternatively, the processor may be implemented as an encoder / decoder for the operations of the above embodiments.

[0967] Open mode

[0968] As described above, the relevant content has already been described in the best mode for performing the implementation.

[0969] Industrial applicability

[0970] As described above, the implementation methods can be applied in whole or in part to point cloud data transmission / reception devices and systems.

[0971] It will be apparent to those skilled in the art that various changes or modifications can be made to the embodiments within the scope of the embodiments.

[0972] Therefore, the embodiments are intended to cover modifications and variations of this disclosure, provided that they fall within the scope of the appended claims and their equivalents.< / manifestpath> < / manifestpath> < / host> < / value> < / field> < / value> < / field> < / manifestpath> < / host> < / manifestpath> < / manifestpath> < / host> < / value> < / field> < / value> < / field> < / manifestpath> < / host>

Claims

1. A device for receiving signals, the device comprising: A multicast gateway configured to receive the signal from a multicast server; as well as A content playback unit, configured to display the services in the signal. The signal includes a multicast transmission session carrying the service. The service is based on User Datagram Protocol / Internet Protocol (UDP / IP), Generic Stream Encapsulation (GSE) protocol, and physical layer protocols. The signal includes logic layer control LLC information based on the GSE protocol. The LLC information includes a multicast descriptor. The multicast descriptor includes source address information, destination address information, source UDP port information, and destination UDP port information.

2. The device according to claim 1, in, The multicast descriptor includes index information for multicast.

3. The device according to claim 1, further configured to: Receive the physical layer channel PLP carrying the GSE stream from the GSE layer, the GSE stream including: GSE data encapsulated with IP headers and compressed IP data; GSE data containing uncompressed IP data with an IP header; Descriptors for multicast; as well as Robust header compression (ROHC) descriptor associated with IP header compression.

4. The device according to claim 1, further configured to: Receive Logical Link Control LLC information from the GSE layer. in, The LLC information includes Network Control Data (NCD) and Link Control Data (LCD). Among them, NCD includes descriptors for multicast. The LCD includes a link identifier for the physical layer.

5. The device according to claim 4, further comprising: A parser configured to parse the LLC information; as well as A decompressor configured to receive a robust header-compressed ROHC stream from a GSE stream in the GSE layer and decompress the IP header.

6. A method for receiving a signal, the method comprising the following steps: Receive signals from the multicast server; as well as The service shown in the signal is displayed. The signal includes a multicast transmission session carrying the service. The service is based on User Datagram Protocol / Internet Protocol (UDP / IP), Generic Stream Encapsulation (GSE) protocol, and physical layer protocols. The signal includes logic layer control LLC information based on the GSE protocol. The LLC information includes a multicast descriptor. The multicast descriptor includes source address information, destination address information, source UDP port information, and destination UDP port information.

7. The method according to claim 6, in, The multicast descriptor includes index information for multicast.

8. The method according to claim 6, further comprising the following step: Receive the physical layer channel PLP carrying the GSE stream from the GSE layer, the GSE stream including: GSE data encapsulated with IP headers and compressed IP data; GSE data containing uncompressed IP data with an IP header; Descriptors for multicast; and Robust header compression (ROHC) descriptor associated with IP header compression.

9. The method according to claim 6, further comprising the following step: Receive Logical Link Control LLC information from the GSE layer. The LLC information includes Network Control Data (NCD) and Link Control Data (LCD). Among them, NCD includes descriptors for multicast. The LCD includes a link identifier for the physical layer.

10. The method according to claim 9, further comprising the following step: The LLC information is parsed; and Receive the robust header-compressed ROHC stream from the GSE stream in the GSE layer, and decompress the IP header.

11. A method for transmitting a signal, the method comprising the following steps: Send a signal from the multicast server. The signal includes a multicast transmission session carrying the service. The service is processed based on User Datagram Protocol / Internet Protocol (UDP / IP), Generic Stream Encapsulation (GSE) protocol, and physical layer protocols; and Logical layer control LLC information is generated based on the GSE protocol. The LLC information includes a multicast descriptor, which includes source address information, destination address information, source UDP port information, and destination UDP port information.

Images