CN117643060A

CN117643060A - Method and apparatus for processing multicast signals

Info

Publication number: CN117643060A
Application number: CN202280050713.1A
Authority: CN
Inventors: 权祐奭; 尹准熙
Original assignee: LG Electronics Inc
Current assignee: LG Electronics Inc
Priority date: 2021-07-22
Filing date: 2022-07-21
Publication date: 2024-03-01

Abstract

A method of transmitting a multicast signal according to an embodiment of the present invention may include the steps of: selectively performing header compression on an IP stream composed of IP packets including multicast service data for a multicast service; generating first signaling information including information related to header compression when header compression is performed on an IP stream; generating second signaling information including information related to the multicast service; and transmitting the IP stream, the first signaling information, and the second signaling information for selectively performing header compression.

Description

Method and apparatus for processing multicast signals

Technical Field

The present disclosure relates to an apparatus and method for processing multicast signals.

Background

With the development of digital technology and communication technology, the distribution and demand of audio/video-oriented multimedia content is rapidly expanding in various fields such as broadcasting, movies, the internet, personal media. In addition, as display technology advances, the size of home television screens increases, and Ultra High Definition (UHD) broadcast services are increasingly being discussed.

Regarding the broadcast service, a multicast transmission scheme for transmitting the same content to a plurality of users is effective because it 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. Therefore, when a multicast receiving device establishes and releases a connection to a different access network, a new multicast service needs to be started after the termination of the existing multicast service. In addition, when a plurality of delivery protocols are used, if there is no registration in the IANA (internet serial number assignment mechanism), the protocol constituting the payload on IP/UDP (internet protocol/user datagram protocol) or IP/TCP (internet protocol/transmission control protocol) cannot be identified with the port number.

Disclosure of Invention

Technical problem

An object of an embodiment devised to solve the problem lies on providing a transmitting apparatus, a transmitting method, a receiving apparatus, and a receiving method for efficiently transmitting/receiving a multicast signal.

Another object of the embodiments is to provide a transmitting apparatus, a transmitting method, a receiving apparatus, and a receiving method for efficiently providing a multicast service between a plurality of networks.

It is another object of the embodiments to provide a transmitting apparatus, a transmitting method, a receiving apparatus, and a receiving method for efficiently transmitting/receiving media in an adaptive bit rate multicast (ABM) network based on unidirectional transmission.

It is another object of the embodiments to provide a transmitting apparatus, a transmitting method, a receiving apparatus, and a receiving method for efficiently transmitting/receiving signaling information for media transmission in an ABM network based on unidirectional transmission.

The technical scope of the embodiments is not limited to the above technical objects, and may be extended to other technical objects that may be inferred by those skilled in the art based on the entire disclosure herein.

Technical proposal

According to an embodiment, a method of transmitting a multicast signal may include the steps of: selectively performing header compression on an IP stream composed of IP (internet protocol) packets including multicast service data for a multicast service; generating first signaling information including information related to the header compression while the header compression is performed on the IP stream; generating second signaling information including information related to the multicast service; and transmitting the IP stream, the first signaling information, and the second signaling information for selectively performing the header compression.

According to an embodiment, the method of transmitting a multicast signal further comprises the steps of: context information is extracted from a header-compressed IP stream generated by performing the header compression on the IP stream. According to an embodiment, the first signaling information may further comprise the extracted context information.

According to an embodiment, the header-compressed IP stream includes at least one IR (initialization and refresh) packet, at least one IR-DYN (IR-dynamic) packet, and a compressed packet. According to an embodiment, the context information is static chain information included in a header of the at least one IR packet.

According to an embodiment, the second signaling information comprises the first signaling information, and the second signaling information further comprises link control data and network control data.

According to an embodiment, the network control data includes at least identification information for identifying a multicast stream including the multicast service data, information for indicating whether to perform the header compression on the IP stream, and address and port information for identifying the IP stream.

According to an embodiment, the method further comprises the steps of: third signaling information including information related to system operation is generated. According to an embodiment, the third signaling information comprises a plurality of signaling files, and the third signaling information is included in at least one IP packet having a fixed IP address and a fixed port number.

According to an embodiment, the header of the at least one IP packet comprising the third signaling information further comprises a signaling header, and the signaling header comprises information identifying each of the plurality of signaling files.

According to an embodiment, the step of transmitting comprises: encapsulating the IP stream for selectively performing the header compression into a first GSE (generic stream encapsulation) stream; encapsulating the first signaling information and the second signaling information into a second GSE stream; and transmitting the first and second GSE streams.

According to an embodiment, the first and second GSE flows are transmitted over different physical links.

According to an embodiment, an apparatus for transmitting a multicast signal may include: a header compressor configured to selectively perform header compression on an IP stream composed of IP packets including multicast service data for a multicast service; a first generator configured to generate first signaling information including information related to the header compression when the header compression is performed on the IP stream; a second generator configured to generate second signaling information including information related to the multicast service; and a transmitter configured to transmit the IP stream, the first signaling information, and the second signaling information for selectively performing the header compression.

According to an embodiment, the device further comprises a context information extractor configured to extract context information from a header-compressed IP stream generated by performing the header compression on the IP stream. According to an embodiment, the first signaling information further comprises the extracted context information.

According to an embodiment, the header-compressed IP stream comprises at least one IR packet, at least one IR-DYN packet, and a compressed packet, and the context information is static chain information included in a header of the at least one IR packet.

According to an embodiment, the second signaling information comprises the first signaling information and the second signaling information further comprises link control data and network control data, and the network control data comprises at least identification information for identifying a multicast stream comprising the multicast service data, information for indicating whether to perform the header compression on the IP stream, and address and port information for identifying the IP stream.

According to an embodiment, the device further comprises a third generator configured to generate third signaling information comprising information related to system operation. According to an embodiment, the third signaling information comprises a plurality of signaling files, and wherein the third signaling information is included in at least one IP packet having a fixed IP address and a fixed port number.

Advantageous effects

According to an embodiment, a multicast service may be provided between a plurality of networks.

According to an embodiment, a media architecture for multicast media streaming over multiple networks may be provided, enabling the same level of media services over multiple networks to which the DVB multicast ABR structure may be applied.

According to an embodiment, multicast content may be received through various access methods, independent of the network to which the receiving device is connected during multicast streaming.

According to the embodiment, the same level of ABR multicast service can be provided even when various devices are connected to separate networks.

According to embodiments, a transmitting apparatus, a transmitting method, a receiving apparatus, and a receiving method may present a media architecture for multicast media streaming based on a plurality of networks, thereby enabling the same level of media services in various networks to which a DVB multicast ABR structure is applicable. In particular, when multicast streaming is performed, various access methods may be used to receive multimedia content independent of a network to which a receiving apparatus is connected. Thus, the same level of ABR multicast service can be provided even when various devices are connected to separate networks.

According to embodiments, in a unidirectional delivery network, such as a terrestrial or satellite broadcast network, a transmitting apparatus, a transmitting method, a receiving apparatus, and a receiving method may support adaptive bit rate multicast media transmission configured to be applied to an existing ISP network by mapping a multicast transmission session to resources of the unidirectional delivery network. In addition, transparent transport may be supported when unidirectional delivery networks are applied to the interface between the multicast server and the multicast gateway.

According to embodiments, in a unidirectional delivery network, such as a terrestrial or satellite broadcast network, a transmitting apparatus, a transmitting method, a receiving apparatus, and a receiving method may transmit signaling information to support adaptive bitrate multicast media transmission configured to be applied to an existing ISP network. In particular, the transmitting apparatus, the transmitting method, the receiving apparatus, and the receiving method according to the embodiments may provide an identification method for signaling, thereby allowing signaling to be filtered at a gateway.

Drawings

The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate embodiments of the disclosure and together with the description serve to explain the principles of the disclosure. For a better understanding of the various embodiments described below, reference should be made to the description of the embodiments below in conjunction with the accompanying drawings. The same reference numbers will be used throughout the drawings to refer to the same or like parts.

Fig. 1 illustrates a multicast Adaptive Bit Rate (ABR) structure according to an embodiment;

FIG. 2 illustrates a multicast rendezvous service based presentation manifest retrieval process according to an embodiment;

fig. 3 illustrates a structure for a multicast rendezvous service according to an embodiment;

fig. 4 illustrates a structure for a multicast rendezvous service according to an embodiment;

fig. 5a and 5b show a flow chart of multicast-based media reception according to an embodiment;

FIG. 6 illustrates elements included in a URL according to an embodiment;

FIG. 7 illustrates elements included in a URL according to an embodiment;

fig. 8 shows a multicast application scheme for 5G media streaming according to an embodiment;

fig. 9 illustrates a multicast streaming structure for both multicast network streaming and communication network streaming according to an embodiment;

fig. 10 illustrates an architecture for wireless media transmission based on multicasting and broadcasting in a communication network according to an embodiment;

fig. 11a and 11b illustrate examples of multicast server configurations in each network according to an embodiment;

fig. 12a and 12b illustrate examples of multicast server configurations for all networks according to an embodiment;

FIG. 13 illustrates an example of multiple networks to which a device is connected according to an embodiment;

fig. 14 illustrates an example of configuring a multicast server and a multicast gateway in each network according to an embodiment;

fig. 15 illustrates another example of configuring a multicast server and a multicast gateway in each network according to an embodiment;

fig. 16 illustrates an example of providing a service of a single multicast server for a plurality of heterogeneous networks and configuring a multicast gateway for the single multicast server in each network according to an embodiment;

fig. 17 illustrates an example of providing a service of a single multicast server for a plurality of heterogeneous networks and configuring each network for a multicast gateway of the single multicast server according to an embodiment;

fig. 18 illustrates an example in which all multicast rendezvous services are configured in a co-ordinated deployment when a multicast server and a multicast gateway are configured in each network, according to an embodiment;

fig. 19a and 19b illustrate an embodiment of a device accessing various serviceable networks when a multicast server and a multicast gateway are configured in each network, according to an embodiment;

fig. 20a and 20b illustrate a structure in which a single multicast server provides services to a plurality of heterogeneous networks and a multicast gateway for the single multicast server is configured in each network according to an embodiment;

Fig. 21 illustrates a protocol configuration of ABR multicasting according to an embodiment;

fig. 22 illustrates an embodiment of a protocol that may be configured in a receiving device to access multiple networks, according to an embodiment;

FIG. 23 illustrates a protocol according to an embodiment;

fig. 24 illustrates a configuration of a service and service related information according to an embodiment;

FIG. 25 illustrates a method of generating and transmitting service listings and presence listings for ABR multicast according to an embodiment;

FIG. 26 illustrates service listings and presentation manifest management according to an embodiment;

FIG. 27 shows a service list according to an embodiment;

fig. 28 illustrates a multicast session according to an embodiment;

FIG. 29 illustrates elements included in a request URL of an HTTP message according to an embodiment;

FIG. 30 illustrates information included in a redirect URL of a location response header according to an embodiment;

FIGS. 31a and 31b illustrate a plurality of content providers according to an embodiment;

FIGS. 32a and 32b illustrate a plurality of service providers according to an embodiment;

FIG. 33 illustrates an MABR network configuration for unidirectional delivery according to an embodiment;

FIG. 34 illustrates another MABR network configuration for unidirectional delivery according to an embodiment;

FIG. 35 illustrates an interface configuration according to an embodiment;

FIG. 36 illustrates an interface configuration according to an embodiment;

fig. 37 illustrates a Link Control Data (LCD) configuration according to an embodiment;

FIG. 38 illustrates a link-related descriptor according to an embodiment;

fig. 39 illustrates Network Control Data (NCD) according to an embodiment;

fig. 40 illustrates a multicast transmission session according to an embodiment;

fig. 41 illustrates an mABR IPv6 transmission session descriptor according to an embodiment;

fig. 42 illustrates an mABR IPv4 transmission session descriptor according to an embodiment;

FIG. 43 illustrates a GSE packet structure according to an embodiment;

fig. 44 illustrates an exemplary syntax structure of ip_multicast_list_descriptor (), according to an embodiment;

fig. 45 illustrates an example of a syntax structure of IPv6_multicast_list_descriptor ();

FIG. 46 illustrates an example of a mapping structure of an NCD and an LCD according to an embodiment;

fig. 47a and 47b are block diagrams illustrating a configuration of an entire system for multicast transmission/reception according to an embodiment;

fig. 48a and 48b are block diagrams illustrating a configuration of an entire system for multicast transmission/reception according to other embodiments;

FIG. 49 shows an exemplary syntax structure of an ROHC-U descriptor according to an embodiment;

fig. 50a and 50b are configuration block diagrams illustrating a GSE system according to an embodiment;

fig. 51 is a table showing an example of an ROHC profile for DVB-GSE according to an embodiment;

fig. 52 illustrates an example of an IP packet containing signaling information according to an embodiment;

fig. 53 illustrates an exemplary syntax structure of a binary signaling header according to an embodiment;

fig. 54 is a table showing the definition of values of table IDs assigned to binary signaling headers according to an embodiment;

fig. 55 and 56 illustrate exemplary syntax structures of a multicast gateway configuration transport session according to an embodiment;

fig. 57 is a diagram illustrating an exemplary logical session configuration in an M interface according to an embodiment;

fig. 58 is a diagram illustrating another exemplary logical session configuration in an M-interface according to an embodiment;

fig. 59 is a diagram illustrating another exemplary logical session configuration in an M interface according to an embodiment;

fig. 60 illustrates a multicast transmission method according to an embodiment; and

fig. 61 illustrates a multicast receiving method according to an embodiment.

Detailed Description

Reference will now be made in detail to the preferred embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. The detailed description set forth below with reference to the appended drawings is intended to explain exemplary embodiments of the present disclosure and is not intended to illustrate the only embodiments that may be implemented in accordance with the present disclosure. The following detailed description includes specific details to provide a thorough understanding of the present disclosure. However, it will be apparent to one skilled in the art that the present disclosure may be practiced without these specific details.

Although most terms used in the present disclosure are selected from terms widely used in the art, the applicant arbitrarily selects some terms and interprets their meanings in detail as necessary in the following description. Accordingly, the present disclosure should be understood based on the intended meaning of the terms rather than their simple names or meanings.

The multicast signal processing method and apparatus according to the embodiment 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 a method/apparatus according to the embodiment.

Methods/apparatus in accordance with embodiments relate to methods of media delivery in adaptive bitrate multicast networks based on unidirectional delivery.

Methods/apparatus in accordance with embodiments relate to methods for signaling of media delivery in adaptive bitrate multicast networks based on unidirectional delivery.

Methods/apparatus in accordance with embodiments relate to configuration of signaling for adaptive bitrate multicast media transmission in unidirectional delivery networks and methods of identifying the same.

Media according to an embodiment may be referred to as media signals, media data, etc., and may be construed as terms corresponding to or including services or service data.

Embodiments present an architecture for media streaming in an Internet Protocol (IP) based media delivery system.

Embodiments propose a media streaming architecture for multicast applications when an IP-based media delivery system is configured with multiple networks.

Embodiments propose ABR multicast methods for use when an IP-based media delivery system is configured with multiple networks.

The embodiment proposes an operation of a service list receiving method (flow) and apparatus (multicast signal processing device according to the embodiment) when an IP-based media delivery system is configured with a plurality of networks.

The embodiments propose signaling information required for reception (devices) over multiple networks.

Embodiments propose a multicast ABR architecture according to a configuration of a content provider and a service provider corresponding to a multicast signal processing device.

Embodiments provide a media architecture for multicast media streaming over multiple networks. Thus, the DVB multicast ABR structure may be applied and the same level of media services are available in multiple networks. In particular, during multicast streaming, multicast content may be received through various access methods, independent of the network to which the receiving device is connected.

Thus, when various devices are connected to separate networks, the same level of ABR multicast service can be provided.

Methods/apparatus according to embodiments may provide multicast transmission session mapping methods for adaptive bitrate multicast media delivery in unidirectional delivery networks.

Methods/apparatus according to embodiments may map multicast transmission sessions to resources of a unidirectional delivery network to support adaptive bitrate multicast media delivery configured to be applied to existing Internet Service Provider (ISP) networks in the unidirectional delivery network, such as terrestrial broadcast or satellite broadcast.

The method/apparatus according to embodiments may support transparent transmission when a unidirectional delivery network is applied to an interface between a multicast server and a multicast gateway.

Methods/apparatus according to embodiments may send signaling information to support adaptive bitrate multicast media transmissions configured for application to existing ISP networks in unidirectional delivery networks, such as terrestrial broadcast or satellite broadcast networks.

Methods/apparatus according to embodiments may provide an identification method for signaling to filter signaling at a gateway.

With the diversity of networks, when various devices access the network, it is necessary to provide media streaming to various devices and multiple users. In such an environment, if transmission is performed only in a unicast manner for all streaming sessions, the quality of media streaming service and other services using the network may deteriorate due to an increase in load on the network. Therefore, there is a need for multicast efficient multicast streaming. Currently, the ABR multicast structure defined in DVB is mainly defined when the multicast providing network is a single network. In order to provide the same service on various networks including a 5G network (wireless network), it is required that the apparatus smoothly operate on each network. To this end, the interfaces and architecture may need to be updated. In addition, if excessive network changes are made to existing service providers to support ABR multicast, actual ABR multicast services may not be provided due to implementation difficulties and cost issues.

Multicast technology provides services in a variety of network environments for universal media streaming and can be transported in most IP-based networks. In addition, in order to provide ABR multicast service using the same function for a plurality of heterogeneous networks, a function and architecture adapted to each network are required. When ABR multicast services are provided over multiple networks, it is necessary to define the transmission of the service list and its management plan to provide continuity of service from the user's perspective.

In the present disclosure, a description will be given of an architecture that allows a DVB ABR multicast structure to be provided through various networks and interfaces thereof. Moreover, a description will be given of a method of providing a service list on a plurality of networks and interfaces and a flow for processing the service list in an apparatus.

Additionally, a method/apparatus according to an embodiment may provide an interface and signaling stream for linking a multicast transmission session to a broadcast stream to transmit DVB ABR multicast media objects in a unidirectional delivery network, such as the terrestrial broadcast and satellite broadcast links defined in the DVB standard.

Fig. 1 illustrates a multicast Adaptive Bit Rate (ABR) structure according to an embodiment.

The multicast signal processing method/apparatus according to the embodiment may transmit media contents through multicast based on the structure shown in fig. 1. The media content may be referred to as multicast media, multicast media data, service data, etc. Each component in fig. 1 corresponds to hardware, software, a processor, and/or a combination thereof.

The interface in fig. 1 may be defined as follows.

L: a unicast HTTP interface between the content playback function and the multicast gateway.

B: a bootstrapped unicast HTTP interface between the content playback function and the multicast bootstrapping function. It may be used to request an initial presentation manifest.

M: the multicast server sends multicast IP content and the multicast gateway receives the interface of the content.

U: the content playback function receives interfaces of media content directly from a content provider through unicast.

Intake (Ingest): an interface for providing media content to a multicast server.

CMS: a control interface for configuring the multicast server.

CMR: a control interface for configuring the multicast gateway.

Configuration: a control interface for exchanging configuration information between content providers, configurations and multicast bootstrapping functions.

The modules in fig. 1 may be defined as follows. Each module may correspond to hardware, software, a processor, and/or a combination thereof.

Content provider: creates media content or stores the created media content and delivers the content to the user over a network. It may use transmission schemes such as multicast and unicast to send media content to users and provide media content data and control information to the multicast server via the ingest interface for multicast transmission. The media content data may be encapsulated in a format such as DASH (dynamic adaptive streaming over HTTP) or HLS (HTTP real-time streaming), and the presentation manifest may be configured according to the encapsulation format.

The multicast server: media content is received from a content provider and sent to a multicast gateway via interface M using an IP multicast transmission scheme. In this case, some control information may also be transmitted. As the multicast protocol, ROUTE (real-time object delivery over unidirectional transport), FLUTE (file delivery over unidirectional transport), QUIC (fast UDP internet connection), RTP (real-time protocol), and the like can be considered.

Multicast gateway: the encapsulated content segments sent by multicast are received and provided to the content playback function via interface L in HTTP or the like. To this end, the content segments are cached. Content segments may represent segmented media data. Segmented media data may be stored (cached).

Configuration (network control): configuration information about the network and the multicast streaming session is provided to the multicast server and the multicast gateway.

Multicast bootstrapping: address information (url or address) for the content playback function may be targeted and processed to first access via interface B. It processes an initial request for a presentation manifest received from the content playback function via reference point B. In the case of multicasting, redirection information is provided for receiving the manifest via interface L. In case of unicast, redirection information for receiving the manifest via interface U is provided. Multicast rendezvous service functions may be performed in a DVB ABR multicast structure.

Content playback: the content playback function manages content requests, receives, decodes, presents, etc. Unicast transmissions via interface L may be considered.

Application: the application controls the content playback function based on the user input. For example, it may be a built-in control application (EPG application) of a television or set-top box, or a third party application provided by a content provider. The interface applied for controlling the playback of the content may be implemented as a separate API or the like according to each device.

The multicast signal processing method/apparatus according to the embodiment may include a multicast server and a multicast gateway, and further include a content provider, a configuration, and a multicast bootstrapping function in terms of an operation of transmitting media.

The multicast signal processing method/apparatus according to an embodiment may include a content playback function and an application in terms of an operation of receiving media.

Fig. 2 illustrates a multicast rendezvous service based presentation manifest retrieval process according to an embodiment.

The multicast signal processing method/apparatus according to the embodiment of fig. 1 may perform a multicast rendezvous service as shown in fig. 2. Each component in fig. 2 corresponds to hardware, software, a processor, and/or a combination thereof.

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. To this end, to obtain a presentation manifest for receiving media content, an initial content playback function may first access a multicast rendezvous service via reference point B. The multicast rendezvous service may provide URLs to content playback functions that may obtain presentation listings appropriately from multicast and unicast.

Fig. 3 illustrates a structure for a multicast rendezvous service according to an embodiment.

In the structures of fig. 1 and 2, a multicast method/apparatus according to an embodiment may perform a rendezvous service as shown in fig. 3. Each component in fig. 3 corresponds to hardware, software, a processor, and/or a combination thereof.

Deployment of multicast rendezvous services:

multicast rendezvous services can be divided into regular deployments and co-located deployments depending on whether HTTP and unidirectional transport are supported.

The content playback function of the multicast signal processing device according to the embodiment can acquire manifest url information and perform configuration for media reception by the following operations.

Rule deployment: the multicast rendezvous service is configured in the network and managed by the system operator.

And (3) co-position deployment: the multicast rendezvous service is implemented in the same device as the multicast gateway.

Rule deployment

Referring to fig. 3, a multicast rendezvous service corresponds to elements located in a network and managed and controlled by a system operator.

The content playback function may acquire manifest url information for receiving content from the multicast rendezvous service via reference point B upon initial access to the content to be received. For this reason, the following configuration can be realized.

The configuration for the basic parameter set (e.g., the multicast gateway configures the endpoint address of the transport session) may be applied to the multicast gateway. For this configuration, an in-band multicast gateway configuration method may be used.

The configuration for the currently configured multicast session set may be applied to the multicast gateway via reference point CMR or reference points CMS and M. For this configuration, out-of-band push configuration, out-of-band pull configuration, and instant configuration methods, as well as in-band multicast gateway configuration methods, may be applied.

Fig. 4 illustrates a structure for a multicast rendezvous service according to an embodiment.

Fig. 4 illustrates the co-located deployment of fig. 3.

And (3) co-position deployment:

as shown in fig. 4, the multicast rendezvous service may be configured in the same apparatus (multicast processing device according to an embodiment) as the multicast gateway. It can be used mainly when the multicast ABR network is configured in a unidirectional deployment. Each component in fig. 4 corresponds to hardware, software, a processor, and/or a combination thereof.

The configuration for the basic parameter set (e.g., the multicast gateway configures the endpoint address of the transport session) may be applied to multicast rendezvous services.

The configuration for the currently configured multicast session set may be applied to the multicast gateway via reference point M.

In this case, an in-band multicast gateway configuration method may be used for each configuration.

Fig. 5a and 5b show a flow chart of multicast-based media reception according to an embodiment.

The multicast signal processing method/apparatus (fig. 1 to 4) according to an embodiment may receive multicast media based on the following flowcharts.

Multicast operation according to embodiments:

when a user or a multicast signal processing apparatus selects multicast content to be received, an application may acquire a URL for requesting an initial presentation manifest through a service directory or the like. Here, the URL indicates a multicast rendezvous service.

The application controls the content playback function to begin an operation for content reception. In this case, it may deliver a URL for the multicast rendezvous service.

The content playback function uses the URL obtained from the application to request presentation manifest from the multicast rendezvous service via reference point B.

The multicast rendezvous service checks the state of the multicast gateway and when a service for the requested presentation manifest is defined in the multicast configuration, sends a redirect URL for the multicast gateway to the content playback function. In this case, the multicast session configuration may be included in the sent redirect message.

Upon receiving the redirect message, the content playback function requests presentation of the manifest to the multicast gateway in accordance with the redirect.

When the multicast gateway has a pre-cached presentation manifest, the multicast gateway sends the presentation manifest to the content playback function.

When the multicast gateway does not have a cached presence manifest, the multicast gateway may obtain the presence manifest from the content hosting function via reference point a and send the presence manifest to the content playback function.

The content playback function may receive media segments for the content via the multicast gateway based on the received presentation manifest.

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

http[s]://<Host>/<ManifestPath>[？<field>＝<value>[&<field>＝<value>]*]

FIG. 6 illustrates elements included in a URL according to an embodiment.

The elements included in the URL are shown in fig. 6.

Host: FQDNs (fully qualified domain name or IP address) and optionally port numbers of multicast rendezvous services.

Manifastpath: a resource path for retrieving a presentation manifest from a specified host.

AToken: this value is an authentication token authorizing access to the multicast rendezvous service if required by the system operator. This may have 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.

MGstatus: this value is the current state of the multicast gateway: 0 = inactive; 1 = active.

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

MGhost: this value is the multicast gateway hostname.

Ori: this value is the hostname (FQDN) of the original target host.

The application may replace the original target host (FQDN) with the local multicast rendezvous service host name or address. Further, where a third party CDN proxy is relied upon, the third party CDN proxy may indicate the original target hostname (FQDN) here before redirecting the request to the multicast rendezvous service.

When the multicast rendezvous service receives the request URL, the multicast rendezvous service may send 307 a temporary redirect response. Here, the syntax of the redirect URL in the location response header is configured as follows:

http[s]://<Host>[/session ID]/<ManifestPath>[？conf＝<multicast session

FIG. 7 illustrates elements included in a URL according to an embodiment.

The elements included in the URL are shown in fig. 7.

Host: the IP address or FQDN of the multicast gateway and optionally the port number (e.g., "router. Example:8088" or "192.0.2.1: 8088").

Session ID: a unique presentation session identifier transmitted and possibly generated by a multicast rendezvous service including one or more URL path elements.

conf: the multicast session parameters will take the form of a multicast gateway configuration instance document that includes one multicast session.

The documents may be compressed using Gzip and base64URL encodings before being included as URL query string parameters.

When the presence manifest is associated with a multicast session in a multicast session configuration (the service may be sent over multicast), the multicast rendezvous service may redirect the request to the multicast gateway as follows:

HTTP/1.1 307 temporary redirection

And (3) a server: < Multicast gateway >

Position: http [ s ]/< Multicast gateway >/< manifastpath >

The URL corresponding to the location field in the HTTP header may include a query parameter for piggybacking a multicast gateway configuration instance document including a session identifier corresponding to the requested presentation manifest and the multicast session.

The multicast ABR according to an embodiment may be connected to a 5G network (communication network).

Fig. 8 shows a multicast application scheme for 5G media streaming according to an embodiment.

The multicast signal processing method/apparatus according to the embodiment may support multicasting in a 5G media streaming structure (multicast ABR architecture).

Fig. 8 shows an embodiment of a 5G media streaming architecture employing a multicast ABR architecture. That is, the 5G structure and the DVB structure may be combined with each other.

The 5G application provider (5 GMSd application provider) may be the same as or may be part of the content provider of the multicast ABR shown in fig. 1-6. The application for receiving the 5G media stream transmission (i.e., the 5GMSd aware application) may be the same as the multicast ABR application of fig. 1-6 or may be part of the application. The client (5 GMSd client) may be the same as or part of the content playback function of the multicast ABR of fig. 1 to 5. The controller (5 GMSd AF) may include a configuration function including a network control sub-function of the multicast ABR shown in fig. 1 to 6 and a multicast bootstrapping function including a multicast rendezvous service.

The access information (presentation manifest url) for the initial multicast transmission may be requested and received by the 5GMSd client via interface M5d, which interface M5d may correspond to interface B of the multicast ABR shown in fig. 1 to 6.

Unicast streaming may be sent from the 5GMSd AS to the media player via the interface M4 d. In this operation, HTTP may be used.

The multicast server and the multicast gateway may be configured for multicast transmission between the 5GMSd AS and the media player. Since data is transferred between the multicast gateway and the media player through the 5G RAN, only unicast may be supported.

For multicast transmission, interfaces m4d_m and m4d_l may be defined as follows.

M4d_m-multicast streaming may be sent from the 5GMSd AS to the multicast server via the interface m4d_m, and the interface M defined in the multicast ABR may be used between the multicast server and the multicast gateway. AS another embodiment, the multicast server functionality may be included in a 5GMS AS. In this case, the interface m4d_m may be omitted. As the multicast protocol, a protocol defined in the interface M may be used.

The m4d_l-m4d_l interface may be used between a multicast gateway and a media player. Here, m4d_m and m4d_l may use HTTP-based protocols. From the DVB multicast ABR perspective, m4d_m may correspond to the ingestion interface and m4d_l may correspond to the interface L.

Fig. 9 illustrates a multicast streaming structure for both multicast network streaming and communication network streaming according to an embodiment.

The multicast signal processing method/apparatus according to the embodiment may transmit/receive and process media contents when DVB multicast ABR network and 5G media streaming are simultaneously provided with multicast streaming. Each component in fig. 9 corresponds to hardware, software, a processor, and/or a combination thereof.

There may be multiple networks providing multicast streaming. When the 5G network is one of such networks, a use case of providing a multicast service from the same content provider through the 5G mobile network and another other IP network at the same time can be considered. Fig. 9 illustrates an embodiment of simultaneously providing multicast streaming over a 5G network and a DVB multicast ABR network.

The configuration for the multicast session configuration may be defined individually according to the characteristics of each network. The multicast interface M through which media is delivered from the multicast server to the multicast gateway may be configured in the same manner.

In this case, the interfaces M2d and m4d_m defined in the 5G network may be the same as the ingestion interface. To this end, the content provider may maintain the same protocol for transmission over each network.

Fig. 10 illustrates an architecture for wireless media transmission based on multicasting and broadcasting in a communication network according to an embodiment.

When wireless multicast and broadcast transmissions are supported in the 5G RAN, the multicast gateway may be configured inside the 5G UE. Each component in fig. 10 corresponds to hardware, software, a processor, and/or a combination thereof.

The 5GMSd application provider may be the same as or may be part of the content provider of the multicast ABR. The 5GMSd aware application for receiving 5G media streaming may be the same as the multicast ABR application or may be part of the application. The 5GMSd client may be the same as, or may be part of, the content playback function of the multicast ABR. The 5GMSd AF may include: a configuration function including a network control sub-function of the multicast ABR and a multicast bootstrapping function including a multicast rendezvous service.

The access information (presentation manifest url) for the initial multicast transmission may be requested and received by the 5GMSd client via interface M5d, which interface M5d may correspond to interface B of the multicast ABR.

The multicast server and the multicast gateway may 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 may be implemented as an interface inside the UE.

The interface m4d_m between the multicast server and the multicast gateway may be defined as the same interface as the interface M defined in the multicast ABR. Thus, as the multicast protocol, a protocol defined in the interface M may be used.

The method/apparatus/processor (multicast signal processing method/apparatus) according to the embodiment may perform the above-described network control operation and provide a media architecture for 5G network-based multicast media streaming based on the relevant signaling information. With the operation according to the embodiment, multicast content can be received through various access methods without depending on a network to which a receiving apparatus is connected during multicast streaming. In addition, by presenting a multicast transmission structure, network resources can be efficiently used to send the same content to multiple receivers.

Embodiments include an MABR (multicast adaptive bitrate) architecture based on multiple IP networks.

The plurality of IP networks according to the embodiments may include various networks, such as communication and broadcast networks.

In order to apply the ABR multicast structure and interface according to the embodiment to each network to be actually provided, additional architecture configuration and application method for the corresponding interface will be described. Each component included in the architecture according to the embodiments may correspond to hardware, software, a processor, and/or a combination thereof.

Fig. 8 to 10 correspond to the multicast signal processing method/apparatus according to the embodiments shown in fig. 1 to 6.

Fig. 11a and 11b illustrate an example of a multicast server configuration in each network according to an embodiment.

Fig. 11a and 11b illustrate an embodiment of a structure in which a multicast server is configured for each network to provide ABR multicast services. This embodiment corresponds to the case where the multicast service server is deployed mainly by the network operator. The transmitting/receiving apparatus according to the embodiment may provide an ABR multicast service based on a multicast server structure shown in the drawings. Each of the components in fig. 11a and 11b corresponds to hardware, software, a processor, and/or a combination thereof.

When ABR multicast services are provided over multiple heterogeneous networks, the deployment of multicast gateways to receive ABR multicast may be implemented separately.

Multicast gateway (a) -when the multicast gateway is configured for ABR multicast services in an ISP network, the multicast gateway may be configured within a router or home gateway provided by the ISP operator.

Multicast gateway (B) -when the multicast gateway is configured for ABR multicast services in a mobile network such as a 5G system, the multicast gateway may be configured within the edge of the mobile network.

Multicast gateway (C) -when the multicast gateway is configured for ABR multicast services in a satellite broadcast network, the multicast gateway may be configured within a STB capable of receiving satellite broadcasts.

Multicast gateway (D) -when the multicast gateway is configured for ABR multicast services in a terrestrial broadcast network, the multicast gateway may be configured within a broadcast receiver.

The ABR multicast function can be configured independently for each network even when ABR multicast services are provided on a plurality of heterogeneous networks.

Fig. 12a and 12b illustrate examples of multicast server configurations for all networks according to an embodiment.

This figure illustrates an embodiment of a structure in which a single multicast server provides ABR multicast services through multiple heterogeneous networks. This embodiment corresponds to the case where the multicast service server is mainly deployed by the content provider. The transmitting/receiving apparatus according to the embodiment may provide an ABR multicast service based on a multicast server structure shown in the drawings.

Each of the components in fig. 12a and 12b corresponds to hardware, software, a processor, and/or a combination thereof.

Fig. 13 illustrates an example of a plurality of networks to which devices according to an embodiment are connected.

In a network structure according to an embodiment, a multicast signal processing method/apparatus for receiving the same multicast media service by accessing a plurality of networks according to an embodiment may be considered. An architecture of a multicast signal processing method/apparatus for receiving the same multicast streaming service through access to a plurality of networks and an implementation of an ABR multicast interface according to an embodiment will be described. Embodiments may be implemented in a variety of architectures.

This figure illustrates an embodiment of a case where all multicast rendezvous services are configured in a regular deployment when multicast servers and multicast gateways are configured in corresponding networks. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and device are configured as shown in fig. 13. Each component in fig. 13 corresponds to hardware, software, a processor, and/or a combination thereof.

In an architecture according to an embodiment, 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. For example, a device may access a mobile network while simultaneously accessing Wi-Fi through an ISP network.

The content playback function in the apparatus may be constituted by two L interfaces L1 and L2 and two B interfaces B1 and B2. The media stream transmission may be received through the multicast gateway (a) via the interface L1, and initial access information regarding the initial multicast gateway (a) may be received via the interface B1. The media stream transmission may be received through the multicast gateway (B) via the interface L2, and the initial access information about the multicast gateway (B) may be received via the interface B2.

The application obtains a list of multicast services and access information about the corresponding multicast rendezvous service via the service discovery interface. The service discovery interface may conform to a method defined separately between the service provider and the application. In addition, each network may support the transmission and reception of data for the service discovery interface.

Fig. 11 to 13 show examples of multicast signal processing apparatuses according to the embodiments shown in fig. 1 to 6, 9 and 10 configured according to types of networks according to embodiments.

Fig. 14 illustrates an example of configuring a multicast server and a multicast gateway in each network according to an embodiment.

In addition to the configuration of fig. 13, embodiments may include a network server and gateway as shown in fig. 14.

This figure illustrates an embodiment of a case where multicast rendezvous services are configured in regular deployment and co-located deployment when multicast servers and multicast gateways are configured in corresponding networks. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and device are configured as shown in fig. 14. Each component in fig. 14 corresponds to hardware, software, a processor, and/or a combination thereof.

In the above architecture, for each network, the multicast server, the multicast gateway, and the multicast rendezvous service for each network provide services to the content playback functions connected to the respective networks. For example, the device may access a set top box through a satellite broadcast network while simultaneously accessing Wi-Fi through an ISP network.

Fig. 15 illustrates an example of configuring a multicast server and a multicast gateway in each network according to an embodiment.

This figure illustrates an embodiment of a case where all multicast rendezvous services are configured in a co-located deployment when a multicast server and a multicast gateway are configured in a corresponding network. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and device are configured as shown in fig. 15. Each component in fig. 15 corresponds to hardware, software, a processor, and/or a combination thereof.

In an architecture according to an embodiment, 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. For example, the device may receive a broadcast over a terrestrial broadcast network while accessing a set top box over a satellite broadcast network. The type of network may vary according to the embodiment. Both networks may be unidirectional networks.

The content playback function in the apparatus may be constituted by two L interfaces L1 and L2 and two B interfaces B1 and B2. The media stream transmission may be received through the multicast gateway (a) via the interface L1, and initial access information regarding the initial multicast gateway (a) may be received via the interface B1. The media stream transmission may be received through the multicast gateway (B) via the interface L2, and the initial access information about the multicast gateway (B) may be received via the interface B2. Here, the multicast gateway (B) and the multicast rendezvous service (B) are configured in the device, and thus the interfaces L2 and B2 may be replaced with internal interfaces of the device.

Fig. 16 illustrates an example of providing a service of a single multicast server for a plurality of heterogeneous networks and configuring a multicast gateway for the single multicast server in each network according to an embodiment.

This figure illustrates an embodiment of a case where all multicast rendezvous services are configured in a regular deployment when services of a single multicast server are provided for a plurality of heterogeneous networks and multicast gateways for the single multicast server are configured in each network. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and device are configured as shown in fig. 16. Each component in fig. 16 corresponds to hardware, software, a processor, and/or a combination thereof.

Fig. 17 illustrates an example of providing a service of a single multicast server for a plurality of heterogeneous networks and configuring each network for a multicast gateway of the single multicast server according to an embodiment.

This figure illustrates an embodiment of configuring multicast rendezvous services in regular deployments and co-located deployments when providing services of a single multicast server for multiple heterogeneous networks and configuring multicast gateways for the single multicast server in each network. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and device are configured as shown in fig. 17. Each component in fig. 17 corresponds to hardware, software, a processor, and/or a combination thereof.

In an architecture according to an embodiment, 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. For example, the device may access a set top box through a satellite broadcast network while simultaneously accessing Wi-Fi through an ISP network.

Fig. 18 illustrates an example in which all multicast rendezvous services are configured in a co-ordinated deployment when a multicast server and a multicast gateway are configured in each network, according to an embodiment.

This figure illustrates an embodiment in which all multicast rendezvous services are configured in a co-located deployment when multicast servers and multicast gateways are configured in each network. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and device are configured as shown in fig. 18. Each component in fig. 18 corresponds to hardware, software, a processor, and/or a combination thereof. The server may be located outside the network.

In an architecture according to an embodiment, 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. For example, the device may receive a broadcast over a terrestrial broadcast network while accessing a set top box over a satellite broadcast network.

The content playback function in the apparatus may be constituted by two L interfaces L1 and L2 and two B interfaces B1 and B2. The media stream transmission may be received through the multicast gateway (a) via the interface L1, and initial access information regarding the initial multicast gateway (a) may be received via the interface B1. The media stream transmission may be received through the multicast gateway (B) via the interface L2, and the initial access information about the multicast gateway (B) may be received via the interface B2. Here, the multicast gateway (B) and the multicast rendezvous service (B) are configured in the device, and thus the interfaces L2 and B2 may be replaced with interfaces inside the device.

Fig. 19a and 19b illustrate embodiments of device access to various serviceable networks when a multicast server and a multicast gateway are configured in each network, according to embodiments.

Each of the components that make up an embodiment corresponds to hardware, software, a processor, and/or a combination thereof.

This figure illustrates an embodiment of the device accessing various serviceable networks when a multicast server and a multicast gateway are configured in each network based on the above description. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and apparatus according to the embodiments are configured as follows.

Fig. 20a and 20b illustrate a structure in which a single multicast server provides services to a plurality of heterogeneous networks and a multicast gateway for the single multicast server is configured in each network according to an embodiment.

As described above, this figure illustrates an embodiment in which a device accesses various serviceable networks when services of a single multicast server are provided for a plurality of heterogeneous networks and a multicast gateway for the single multicast server is configured in each network. A system according to an embodiment may include a service provider, a network, and an apparatus. The service provider, network and device are configured as follows.

The transmitting/receiving apparatus according to the embodiment can efficiently control and provide DVB multicast ABR and 5G media streaming in various network environments based on the operation according to the embodiment.

Hereinafter, a receiving operation and an operation for a receiving apparatus according to an embodiment will be described.

For the architecture according to the above embodiment, the following protocol may be implemented.

Based on the described architecture according to the embodiments, elements and attributes required for a device capable of receiving ABR multicast streaming over multiple transport networks are defined.

The receiver according to the embodiment may perform a reverse process of the operation of the transmitter. The receiver may perform ABR multicast streaming based on the following operations. The receiver may perform ABR multicast streaming based on the following network structure.

The following is an example of a protocol stack in a receiving device.

Fig. 21 illustrates a protocol configuration of ABR multicast according to an embodiment.

For multicast ABR transmissions, multicast streaming may be transmitted from a multicast server via interface M. In this case, ROUTE or FLUTE may be used as the multicast transmission protocol. The multicast gateway may use DASH or HLS for HTTP-based adaptive media streaming to the playback function via interface L. In the playback function, a protocol for receiving HTTP-based adaptive media streaming from the multicast gateway, and a file format and media codec for the received adaptive streaming may be configured. Here, the layer 1 and layer 2 protocols may be configured as optimal protocols for the respective networks.

To access multiple networks, embodiments may include the protocols described below.

Fig. 22 illustrates an embodiment of a protocol that may be configured in a receiving device to access multiple networks, according to an embodiment.

The figure shows a protocol implemented on the architecture according to the above-described embodiments when the multicast signal processing apparatus according to the embodiments is implemented as a receiving device.

According to an embodiment, 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.

According to an embodiment, a multicast gateway configured on a network to provide a service of ABR multicast streaming on network a receives multicast streaming from a multicast server and sends the multicast streaming to devices via interface L in an HTTP-based adaptive media streaming manner. Thus, in an apparatus, a protocol stack for receiving adaptive media streaming via the interface L may be configured.

Furthermore, to receive ABR multicast streaming over network B, a multicast gateway may be configured in the device. Thus, in an apparatus, a protocol stack for receiving adaptive media streaming via an interface M for a network B may be configured.

Thus, the protocols for interface M and interface L may be configured in the receiver device simultaneously to access multiple networks to receive ABR multicast services. In this case, the multicast gateway function in the device may convert the multicast streaming into HTTP-based adaptive media streaming in the same manner as a multicast gateway configured on a network and deliver the converted streaming to the interface L in the device.

Fig. 23 illustrates a protocol according to an embodiment.

In an embodiment, 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.

In an embodiment, a multicast gateway configured on a network to provide a service of ABR multicast streaming on network a receives multicast streaming from a multicast server and sends the multicast streaming to devices via interface L in a HTTP-based adaptive media streaming manner. Thus, in an apparatus, a protocol stack for receiving adaptive media streaming via the interface L may be configured.

Thus, the protocols for interface M and interface L may be configured in the receiver device simultaneously to access multiple networks to receive ABR multicast services. In this case, unlike a multicast gateway configured on a network, a multicast gateway function in a device may have an interface L configured in the device. Interface L may be directly configured as a protocol stack without a separate interface. For streaming received over network a, the device may operate while the playback function is operated. For streaming received over network B, the device may operate as a multicast gateway. When operating as a multicast gateway, interface L may be omitted and the payload of the multicast protocol may be the adaptive media streaming data.

Next, operations of generating and transmitting/receiving a service list and a presentation manifest according to an embodiment will be described.

Fig. 24 illustrates a configuration of a service and service related information according to an embodiment.

For DASH-based ABR multicast services, a service provider according to an embodiment may configure a presentation manifest (e.g., MPD (media presentation description)) and a service list as follows. In terms of service configuration, the service list and the presentation manifest may not be redundantly configured for the same content.

Fig. 25 illustrates a method of generating and transmitting service listings and presentation listings for ABR multicast according to an embodiment.

To support ABR multicasting, a multicast signal processing method/apparatus according to an embodiment may generate and transmit/receive service lists and presentation lists as shown in fig. 25.

The elements that can be sent may be determined from interfaces defined in the ABR multicast architecture. The application of the receiver device may receive the service list from the service list directory. The list may include service ids and url for multicast rendezvous services. When the content playback function requests a manifest from the multicast rendezvous service through url, the address of the multicast gateway and the path of the manifest can be acquired through a redirect message of the multicast rendezvous service and the presentation manifest is received via interface L. The multicast gateway may receive a presentation manifest (e.g., MPD) from the multicast server. To this end, multicast session configuration information may be obtained.

FIG. 26 illustrates service listings and presentation manifest management according to an embodiment.

The receiving apparatus according to the embodiment may manage the service list and the presentation list as shown in fig. 26. For service listings and presentation listings (e.g., MPDs) configured in an architecture according to an embodiment, the service listings may be managed in a receiver capable of receiving ABR multicast services over multiple networks as described below.

That is, MPDs for a plurality of networks such as network 1 and network 2 may be generated and transmitted/received for the same service.

In an embodiment, the adaptation sets provided through the respective networks may be different from each other in a device that receives ABR multicast services using a plurality of networks. Thus, the presentation manifest is configured and managed separately for each network.

When the ABR multicast service reception function is configured in a TV or the like and broadcast content is simultaneously received by a corresponding receiver, a service list according to an embodiment may be managed like channel mapping.

Fig. 27 shows a syntax of a service list according to an embodiment.

ServiceList-this is the root element that includes configuration information about the service.

@ serviceIdentifier-an identifier used to identify a service.

Presentationanalifsetrequest url-an element of information about a multicast rendezvous service when configured for one service through a plurality of multicast rendezvous services.

Network type-network type of multicast rendezvous service deployed. It may be used to set priority when devices access the network simultaneously.

Address of @ HostAddress-multicast rendezvous service.

Attributes of deployment of the RendezvouserType-multicast rendezvous service. For example, 0 is for rule deployments and 1 is for parity deployments.

The elements of the multicastTransportSession-multicast transport session may optionally be sent when the device includes a multicast gateway. When the multicastTransportSession element is not sent, the information may be provided through a multicast gateway configuration.

Fig. 28 shows an embodiment of a configuration of multicast session elements. The multicast session element is sent from the configuration function to the multicast server and the multicast gateway. Thus, the CMS interface and the CMR interface may be used, respectively. When the network supports only unidirectional transmission, elements may be delivered to the multicast server via the CMS interface and then from the multicast server to the multicast gateway via interface M.

@ serviceIdentifier: a service identifier of a logical service associated with the session.

@ contentPlaybackAvailabilityOffset: duration string. When passed to an instance of the content playback function, the availability time offset adjustment applied to the original presentation manifest.

@ network identifier: an identifier of the network for transmitting the current multicast session.

Presentationaniffesfestlocator: the URL of the presentation manifest of the linear service.

@ manifisetid: the presentation manifest is uniquely identified within the scope of the multicast session.

@ contentType: the MIME content type of the presentation manifest.

multicastTransportSession: a container for multicast transmission session parameters.

Network identifier-identifier for the network providing the current multicast session. The receiver may identify the network for receiving the same multicast service.

Inventory request and redirection according to an embodiment

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

http[s]://<Host>/<ManifestPath>[？<field>＝<value>[&<field>＝<value>]*]

FIG. 29 illustrates elements included in a URL according to an embodiment.

Fig. 29 illustrates elements included in a request URL of an HTTP message according to an embodiment.

Host: FQDN (or IP address) and optionally port number of the multicast rendezvous service.

Priority: the priority of the presentation is retrieved when deploying the plurality of networks.

MGstatus: this value is the current state of the multicast gateway. For example, 0=inactive, and 1=active.

MGhost: this value is the multicast gateway hostname.

Ori: this value is the hostname (FQDN) of the original target host.

Priority-when a playback function requests a manifest from a multicast rendezvous service and the multicast rendezvous service is able to redirect it to multiple multicast gateways, the network in which the multicast gateway is configured may be assigned different priorities so that the Priority of multicast reception may be determined.

After receiving the request URL according to an embodiment, the multicast rendezvous service may send 307 a temporary redirect response. Here, the syntax of the redirect URL in the location response header is configured as follows:

http[s]://<Host>[/session ID]/<ManifestPath>[？conf＝<multicast session

elements included in a URL according to an embodiment are disclosed below.

Fig. 30 illustrates information included in a redirect URL of a location response header according to an embodiment.

RequestedPriority: priority value of playback request from content.

conf: the multicast session parameters may take the form of a multicast gateway configuration instance document that includes one multicast session.

Prior to including as a URL query string parameter, the document may be compressed using Gzip and base64URL encoded.

RequestedPriority-when the playback function requests a manifest from a multicast rendezvous service and configures the priorities of multiple multicast gateways, the priority sent at the time of redirection transmission may be returned. The multicast rendezvous service may redirect it to the multicast gateway with the highest possible priority that may be redirected.

HTTP/1.1 307 temporary redirection

And (3) a server: < Multicast gateway >

Position: http [ s ]// < Multicast gateway >/< manifastpath > [? < requestedPriority ]. Times.

Hereinafter, operations of the content provider and the service provider according to the embodiment will be described.

An architecture according to an embodiment may include a content provider, a service provider, a network, and a device. Each component may correspond to hardware, software, a processor, and/or a combination thereof. A processor according to an embodiment may perform operations according to an embodiment, and may be connected to a memory to store information about the operations.

Fig. 31a and 31b illustrate a plurality of content providers according to an embodiment.

An architecture according to an embodiment shows a structure for providing a service using content created by a plurality of content providers. In an architecture according to an embodiment, 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.

In this case, the service provider may provide the service to the receiver apparatus using a plurality of networks. The service provider can configure the service list directory and can acquire a content list to be provided through a content provider control function configured in each content provider. The received content list may configure the service list in a form suitable for the service. The list of services is provided to the application.

The content provider server provides content (intake) to a multicast server configured in the service provider. In this case, information about the ingested content may be transmitted from each content provider control function to the service provider control function. Based on this information, the service provider control function may configure and deliver multicast session configuration information to the multicast server and multicast gateway.

Interface L and interface B may be configured for each network in a content playback function in the device. Media streaming may be received through the multicast gateway (a), the multicast gateway (B), the multicast gateway (C) and the multicast gateway (D) via the interfaces L1, L2, L3 and L4, and initial access information of the multicast gateway is received via the interfaces B1, B2, B3 and B4. Since the multicast gateway (D) and the multicast rendezvous service (D) are configured in the device, the interfaces L4 and B4 can be replaced by internal interfaces of the device.

Fig. 32a and 32b illustrate a plurality of service providers according to an embodiment.

The architecture according to the embodiment shows a structure in which a service is provided to a content provider through a plurality of service providers. In an architecture according to an embodiment, 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.

In this case, each service provider may provide services to the receiver apparatus using a plurality of networks. Each service provider may configure a service list directory and may obtain a list of content to be served through a content provider control function of the content provider. The received content list may configure the service list in a form suitable for the service. The list of services is provided to the application.

The content provider server provides content (intake) to a multicast server configured in the service provider. In this case, information about the ingested content may be sent from the content provider control function to the service provider control function. Based on this information, the service provider control function may configure and deliver multicast session configuration information to the multicast server and multicast gateway.

Fig. 33 illustrates an MABR network configuration for unidirectional delivery according to an embodiment.

The method/apparatus according to the embodiment may support unidirectional delivery through a network of the MABR architecture according to the above embodiment. An example of multicast transmission session mapping for unidirectional delivery will be described.

In an architecture according to an embodiment, a multicast ABR service provider configures a multicast server for each network and sends multicast content and configuration information to a multicast gateway and a multicast rendezvous service using a multicast interface (M). Here, the interface M may be configured through a unidirectional network having no uplink channel. As the unidirectional network, a satellite (broadcast) network or a terrestrial broadcast network may be considered.

Multicast ABR content and configuration information received by the multicast gateway and the multicast rendezvous service may be delivered to the content playback function using HTTP or the like provided by the interface L, and the multicast gateway may operate as a server of a Home Broadcast (HB) network.

The interface L and the interface B may be configured in a content playback function in the device or HB network. Media streaming may be received through the multicast gateway via interface L and initial access information of the multicast gateway via interface B. Here, when the multicast gateway and the multicast rendezvous service are configured in the same device, the interface L and the interface B may be replaced by internal interfaces of the device.

After the service list, which may 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 may be delivered to the multicast service, and the multicast server may deliver it to the multicast gateway via the interface M.

Fig. 34 illustrates an MABR network configuration for unidirectional delivery according to an embodiment.

In an architecture according to an embodiment, a 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 a multicast gateway and a multicast rendezvous service. Here, the interface M may be configured through a unidirectional network having no uplink channel. As the unidirectional network, a satellite (broadcast) network or a terrestrial broadcast network may be considered.

Fig. 35 illustrates an interface configuration according to an embodiment.

The M interface according to the embodiment is configured as follows.

The method/apparatus according to embodiments may perform unidirectional delivery based on the M interface including a unidirectional link. In this case, the unidirectional link may be configured with a satellite channel, the physical layer may be configured with DVB-S2 (digital video broadcast-satellite-second generation) or DVB-S2X (DVB-S2 extension), and the data link layer may be configured with DVB-GSE (digital video broadcast-generic stream encapsulation).

When the multicast server sends a multicast transmission session to the 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 delivers the session to the multicast gateway according to the protocol defined in the M-interface. When a multicast transmission session is sent over a satellite channel, it may be multiplexed into a single signaling. To de-multiplex the multicast transmission session and pass it to the multicast gateway, the multicast transmission session may be mapped to IP multicast sent over the satellite channel. In this case, data link layer signaling may be used to map the multicast transmission session.

Fig. 36 illustrates an interface configuration according to an embodiment.

The method/apparatus according to embodiments may perform unidirectional delivery based on the M interface including a unidirectional link. In this case, the unidirectional link may be configured with a broadcast channel, the physical layer may be configured with DVB-T2 (DVB-terrestrial 2), and the data link layer may be configured with DVB-GSE.

When the multicast server transmits the multicast transmission session to the multicast gateway through a protocol defined in the M interface, the broadcast transmitter receives the session and transmits it to the broadcast receiver on a broadcast channel. The broadcast receiver delivers the session to the multicast gateway according to a protocol defined in the M interface. When a multicast transmission session is sent on a broadcast channel, it may be multiplexed into a single signaling. To de-multiplex and communicate multicast transmission sessions to the multicast gateway, the multicast transmission sessions may be mapped to IP multicast sent on broadcast channels. In this case, data link layer signaling may be used to map the multicast transmission session.

According to an embodiment, DVB-DASH based services according to ETSI TS103 285 may be included in a DVB-I (internet) service list. DVB-DASH based services of DVB-NIP (local IP) may be carried over DVB broadcast networks defined in ETSI TS103 769 using the FLUTE/ROUTE protocol defined by DVB-MABR.

Signaling and a/V services (using DVB-DASH ETSI TS103 285) are carried over broadcast RF channels via IP multicast. The DVB-NIP IP multicast session is carried at the data link layer using GSE-Lite profile as defined in clause d.2 of ETSI TS102 606-1 or multiprotocol encapsulation as defined in ETSI EN 301 192. DVB-S2X (ETSI 302307-1, ETSI 302 307-2), DVB-S2 (ETSI 302 307-1) and DVB-T2 (ETSI TS102 755) at the physical layer may also be used.

Based on the logical layer control structure of the multicast transmission session map according to the embodiment, the method/apparatus according to the embodiment may perform unidirectional delivery.

GSE-LLC structure

In a configuration for interface M according to an embodiment, DVB-GSE LLC (logical layer control) is used as an embodiment of a method of mapping multicast transmission sessions using data link layer signaling.

The DVB-GSE LLC is composed of Link Control Data (LCD) and Network Control Data (NCD).

The syntax of the LCD may be configured as shown in fig. 44.

That is, fig. 37 shows a configuration of Link Control Data (LCD) according to an embodiment.

Phy_descriptors () —descriptors of the physical layer modulation system.

number_of_links-indicates the number of links or physical streams included in the modulation system of the physical layer.

An identifier of a physical link included in a modulation system of a link_id-physical layer.

link_association_descriptions () may be configured as follows.

Fig. 38 designates one of link_association_descriptions () included in an LCD according to an embodiment. Link_association_descriptor () of fig. 38 is identified by a corresponding link_id included in the LCD.

modulation_system_type-indicates the type of broadcast modulation system. For example, it may be encoded as follows.

0x00-DVB-S2/S2X

0x01-DVB-T2

The modulation_system_id-unique identifier of the modulation system.

Phy_stream_id-this can be encoded according to the modulation_system_type as follows:

input Stream Identifier (ISI) of modulation_system_type=0x00-DVB-S2/S2X

Physical layer channel of modulation_system_type=0x01-DVB-T2

The NCD may be configured as follows.

Fig. 39 illustrates Network Control Data (NCD) according to an embodiment.

In the NCD structure, a platform_descriptor (), a target_descriptor (), and an operation_descriptor may be defined for each signaling purpose.

Regarding target_descriptors (), when GSE has only IP address information, it can handle multicast according to an embodiment. Thus, target_descriptors () according to the embodiment can solve the problem by including information identified for multicasting.

Fig. 40 illustrates a multicast transmission session according to an embodiment.

Methods/apparatus in accordance with embodiments may perform transmission session mapping based on multicast transmission sessions.

As shown in fig. 40, a multicast transmission session transmitted from a multicast server may be defined.

The multicast transmission session sent from the multicast server may be mapped to an IP multicast stream by a unidirectional delivery transmitter (e.g., a satellite transmitter) and carry IP multicast stream information to a unidirectional delivery receiver (e.g., a satellite receiver).

Fig. 41 illustrates an mABR IPv6 transmission session descriptor according to an embodiment.

When the method/apparatus according to the embodiment transmits a multicast transmission session through IPv6, a transmission session descriptor as shown in fig. 41 may be included in a destination descriptor of the NCD.

descriptor_tag-an identifier corresponding to a descriptor.

descriptor_length-indicates the length of the descriptor.

multicast_transport_session_id_length-indicates the length in bytes of the following multicast_transport_session_id.

A unique identifier of the multicast_transport_session_id-multicast transmission session. It has the same value as the id included in the multicast ABR session configuration.

source_ipv 6_address-indicates the source IP address of the current multicast transmission session sent over IPv 6.

destination_ipv 6_address-indicates the group (e.g., destination) IP address of the current multicast transmission session sent over IPv 6.

source_udp_port-indicates the source UDP port for the current multicast transport session.

destination_udp_port—indicates the destination UDP port of the current multicast transport session.

According to an embodiment, the method/apparatus according to an embodiment may support multicasting by additionally defining source_udp_port and destination_udp_port in GSE-related descriptors (e.g., transport session descriptors).

Fig. 42 illustrates an mABR IPv4 transmission session descriptor according to an embodiment.

When a multicast transmission session is transmitted through IPv4, a method/apparatus according to an embodiment may include a transmission session descriptor as shown in fig. 42 in a target descriptor of an NCD.

descriptor_tag-an identifier corresponding to a descriptor.

descriptor_length-indicates the length of the descriptor.

source_ipv 6_address-indicates the source IP address of the current multicast transmission session sent over IPv 4.

destination_ipv 6_address-indicates the group (e.g., destination) IP address of the current multicast transmission session sent over IPv 4.

When a plurality of multicast transmission sessions are mapped to a single link, a plurality of mabr_ipv6_transport_session_descriptor () or mabr_ipv4_transport_session_descriptor () may be included in an NCD loop (NCD loop).

According to an embodiment, a method/apparatus according to an embodiment may support multicasting by additionally defining source_udp_port and destination_udp_port in GSE-related descriptors (e.g., transport session descriptors of fig. 41 or 42).

The transport session descriptor of fig. 41 and/or 42 may be referred to as a multicast list descriptor.

The transport session descriptors (i.e., multicast list descriptors) of fig. 41 and/or 42 carry the multicast list delivered in the physical link. In one embodiment, the descriptor carries a list of IPv4 multicast carried in the physical link and provides information for handling UDP/IPv4 packets carrying multicast in the DVB-GSE layer. In addition, the descriptor carries a list of IPv6 multicast delivered in the physical link and provides information for handling UDP/IPv6 packets carrying multicast in the DVB-GSE layer.

Fig. 43 illustrates an exemplary header structure of a GSE packet for transmitting the GSE-LLC.

According to an embodiment, the GSE-LLC is signaling information of the data link layer and is composed of an LCD and an NCD.

According to an embodiment, after a mandatory extension header is configured in a GSE packet to transmit GSE-LLC, index data (llc_index), LCD, and NCD are transmitted in a table structure (GSE _table_structure ()) through the mandatory extension header. In this case, protocol Data Unit (PDU) data does not exist in the GSE packet.

In the present disclosure, index data (llc_index), LCD, and NCD in a table structure (GSE _table_structure ()) transmitted through an extension header of a GSE packet will be referred to as LLC data. According to an embodiment, LLC data may be divided into an index portion and a record portion, and the record portion may be further divided into a plurality of tables. Here, each table constituting the recording section may have a GSE table structure or a general section table structure.

In this case, in an embodiment, a protocol_type field included in the GSE header is assigned 0x0087 to identify GSE-LLC.

Each gse _table_structure () may include a table_id field, an interactive_network_id field, a version_number field, and a current_next_indicator field.

According to an embodiment, when the value of the table_id field is 0xB3, gse _table_structure () includes index data llc_index. When the value is 0xB4, gse _table_structure () includes an LCD. When the value is 0xB5, gse _table_structure () includes NCD.

The table_id field included in the index data llc_index indicates LCD (e.g., 0xB 4) or NCD (e.g., 0xB 5).

According to an embodiment, for details of information contained in LCD () and NCD () carried in an extension header of a GSE packet as shown in fig. 43, description of the details is omitted herein with reference to fig. 37 to 39 to avoid repetitive description. In order to map IP multicast transmitted through DVB GSE to physical layer resources and to transmit IP multicast list information to a receiving device, a multicast list descriptor may be included in target_descriptors () of NCD (), and GSE-LLC data may be transmitted.

In addition, a link_id field may be used in LCD (), to identify physical layer resources. In the case of DVB T2, the link_id field may be mapped to PLP_ID, and in the case of DVB-S2/S2X, the link_id field may be mapped to ISI_ID.

The multicast list descriptor according to the embodiment carries an IPv4 multicast list or an IPv6 multicast list carried on a physical link in an interactive_network_id. The descriptor may include additional information for processing UDP/IPv4 packets or UDP/IPv6 packets carrying multicasting in the DVB-GSE layer. In the present disclosure, the UDP/IPv4 packet may be referred to as an IPv4 packet, and the UDP/IPv6 packet may be referred to as an IPv6 packet.

Fig. 44 illustrates an exemplary syntax structure of ip_multicast_list_descriptor (), according to an embodiment.

Fig. 44 shows an example of transmitting a multicast stream through IPv 4.

According to an embodiment, ip_multicast_list_descriptor () includes a num_multicasts field.

The num_multicasts field indicates the number of multicasts signaled in the descriptor.

According to an embodiment, ip_multicast_list_descriptor () includes as many iteration sentences as the value of num_multicasts field. In this case, in an embodiment, i is initialized to 0, incremented by 1 each time an iterative statement is executed. Furthermore, the iterative statement is iterated until i becomes the value of the num_multicasts field. The iterative statement may include a multicast_stream_id field, a source_ip_address field, a destination_ip_address field, a source_port field, a destination_port field, and a header_compression_flag field.

The multicast_stream_id field uniquely identifies the multicast stream.

The source_ip_address field indicates the source IPv4 address of the UDP/IPv4 packet carrying the multicast stream identified by the multicast_stream_id field. That is, it indicates the source IPv4 address of the multicast stream identified by the multicast_stream_id field.

The destination_ip_address field indicates the destination IPv4 address of the UDP/IPv4 packet carrying the multicast stream identified by the multicast_stream_id field. That is, it indicates the destination IPv4 address of the multicast stream identified by the multicast_stream_id field.

The source_port field indicates the source UDP port number of the UDP/IPv4 packet carrying the multicast stream identified by the multicast_stream_id field. That is, it indicates the source UDP port number of the multicast stream identified by the multicast_stream_id field.

The destination_port field indicates the destination UDP port number of the UDP/IPv4 packet carrying the multicast stream identified by the multicast_stream_id field. That is, it indicates the destination UDP port number of the multicast stream identified by the multicast_stream_id field.

In other words, the multicast_stream_id field may be assigned an ID value of a multicast stream having a unique combination of a source IP address field, a destination IP address field, a source port number field, and a destination port number field following the multicast_stream_id field.

The header_compression_flag field indicates whether header compression is applied to the multicast stream (i.e., corresponding IP multicast or IP stream) identified by the multicast_stream_id field. For example, when the value of the header_compression_flag field is 0, it may indicate that header compression is not applied to a multicast stream (i.e., a corresponding IP multicast or IP stream). When the value is 1, it may indicate that header compression is applied to the multicast stream (i.e., the corresponding IP multicast or IP stream). In other words, when the value of the header_compression_flag field is 0, it indicates that the multicast stream is transmitted without header compression at the DVB-GSE layer. When the value of the header_compression_flag field is 1, it indicates that header compression is applied to the multicast stream in the DVB-GSE layer. In this case, signaling information (e.g., a robust header compression unidirectional mode (ROHC-U) descriptor) regarding the header compression related configuration parameters may be additionally transmitted. In other words, when the value of the header_compression_flag field is 1, the ROHC-U descriptor is signaled.

A detailed description of header compression and ROHC descriptors will be provided later.

The ROHC descriptor in the present disclosure may be referred to as ROHC-u_multicast_descriptor or multicast_rohc-u_descriptor or ROHC-U information.

Fig. 45 illustrates an example of a syntax structure of IPv6_multicast_list_descriptor (), according to an embodiment.

Fig. 45 illustrates an example of transmitting a multicast stream through IPv 6.

The IPv6_multicast_list_descriptor () in fig. 45 is the same as the descriptor in fig. 44 except that source_ipv6_address field, destination_ipv6_address field, source_port field, and destination_port field indicate the source IP address, destination IP address, source UDP port number, and destination UDP port number of the UDP/IPv6 packet carrying the multicast stream identified by the multicast_stream_id field. Accordingly, the description of each field of fig. 44 is referred to for the details of each field of fig. 45, and the description of the details is omitted herein.

Fig. 46 illustrates another example of an NCD syntax structure and an LCD syntax structure according to an embodiment.

In fig. 46, the NCD includes an interactive_network_id field, a platform loop (platform loop), and one or more IP multicast configuration loops.

The network may be identified by an interactive_network_id field.

According to an embodiment, the platform loop may include IP/mac_plane_name_descriptor (), and IP/mac_plane_provider_descriptor ().

According to an embodiment, each IP multicast configuration cycle may include a target cycle and an operational cycle.

The target cycle may include the IP multicast list descriptor of fig. 44 and the IPv6 multicast list descriptor of fig. 45.

The operational loop may include multicast_rohc-u_descriptor (). The multicast_rohc-u_descriptor () may include IP/mac_link_location_descriptor (). The IP/mac_link_location_descriptor () may include a link_id field.

The link_id field uniquely identifies the physical link in the interactive network identified by the interactive_network_id field. That is, the physical link can be identified by the link_id field of IP/mac_link_location_descriptor ().

That is, since the multicast list descriptor in the target cycle signals information about a plurality of IP/IPv6 multicast streams and the IP/mac_link_location_descriptor () in the operable cycle signals the link_id field, information about a plurality of IP/IPv6 multicast streams is mapped to the link_id field.

The link_id field included in the IP/mac_link_location_descriptor () of the NCD is mapped to a link_id having the same value in the link cycle of the LCD. That is, a reference relationship between the NCD and the LCD may be indicated based on the link_id field.

The Link loop of the LCD also includes link_association_descriptor (). Link_association_descriptor () includes a modulation_system_type field, a modulation_system_id field, and a phy_stream_id field. Accordingly, the link_id field of the LCD may be mapped to link_association_descriptor () and identified by the value of the phy_stream_id field of the physical layer.

For details of fields in the LCD, description of the details is omitted herein with reference to the description of the fields of fig. 37 and 38 to avoid repetitive description.

Fig. 47a and 47b are exemplary block diagrams illustrating a configuration of an entire system for multicast transmission and reception in a unidirectional delivery structure according to an embodiment. The systems of fig. 47a and 47b may be referred to as unidirectional delivery systems for transmission/reception of multicast ABR content. Unidirectional delivery structures have the same meaning as unidirectional delivery systems. The multicast ABR content in this disclosure may be referred to as multicast service data or media objects or media content.

Fig. 47a and 47b show data streams for transmitting GSE streams through a DVB-NIP based transmitter (NIP transmitter) and receiving GSE streams through a DVB-NIP based receiver (NIP receiver), according to embodiments.

In fig. 47a and 47b, the DVB-I service list registry provides information (e.g., URL) about the DVB-I service list entry point to the IP packetizer 2011 in the NIP transmitter, and the DVB-I service list server provides information (or service list information) about the DVB-I service list to the IP packetizer 2011 in the NIP transmitter.

The IP packetizer 2011 packetizes information about the DVB-I service list entry point into one or more IP packets and outputs an IP stream including the one or more IP packets to the GSE encapsulator 2012.

The IP packetizer 2011 packetizes information on the DVB-I service list into one or more IP packets and outputs an IP stream including the one or more IP packets to the GSE encapsulator 2012.

The IP packetizer 2011 packetizes a Network Information File (NIF) into one or more IP packets and outputs an IP stream including the one or more IP packets to the GSE encapsulator 2012. The IP packetizer 2011 may packetize a Service Information File (SIF) into one or more IP packets and output an IP stream including the one or more IP packets to the GSE encapsulator 2012.

The IP packetizer 2011 packetizes the multicast gateway profile transmitted from the multicast server into one or more IP packets and outputs an IP stream including the one or more IP packets to the GSE encapsulator 2012.

In an embodiment, each IP packet generated by the IP packetizer 2011 is a UDP/IP packet including a UDP header and an IP header.

GSE encapsulator 2012 groups the incoming IP streams into GSE packets. In one embodiment, the IP flow is included in the payload of the GSE packet.

The LLC builder 2013 in the NIP transmitter receives descriptors included in the NCD and LCD and ROHC-U descriptors, generates LLC data, and then outputs the data to the GSE wrapper 2012.

LLC data includes NCDs and LCDs.

According to an embodiment, the LLC data generated by the LLC builder 2013 may have a table structure (gse _table_structure ()) as shown in fig. 43.

In this case, three table structures (gse _table_structure ()) are created, and table_id fields in the corresponding table structures (gse _table_structure ()) indicate index data (e.g., 0xB 3), LCD (e.g., 0xB 4), and NCD (e.g., 0xB 5), respectively.

In the present disclosure, a table structure (gse _table_structure ()) including index data (llc_index), a table structure (gse _table_structure ()) including LCD, and a table structure (gse _table_structure ()) including NCD may be referred to as LLC data.

According to an embodiment, the ip_multicast_list_descriptor () of fig. 44 and the IPv6_multicast_list_descriptor () of fig. 45 are included in the target loop of the NCD.

As shown in fig. 43, LLC data is included in mandatory extension headers of GSE packets by GSE encapsulator 2012. In this case, the GSE packet does not have a PDU.

The GSE stream including the GSE packets generated by GSE encapsulator 2012 is sent to GSE decapsulator 2051 in the NIP receiver of the NIP gateway.

According to an embodiment, the GSE stream may be transmitted through a terrestrial or satellite broadcast system. In this case, GSE streams may be distinguished by Physical Layer Pipe (PLP) IDs for terrestrial broadcasting systems. For satellite broadcast systems, GSE streams may be distinguished by an Input Stream Identifier (ISI).

That is, in the unidirectional delivery structure, in order to transmit information (e.g., URL) about the DVB-I service list entry point provided by the DVB-I service list registry to the DVB-I client, the IP packetizer 2011 of the NIP transmitter may configure an IP stream including information about the DVB-I service list entry point configured in XML format, and the GSE encapsulator 2012 may configure a GSE stream including the IP stream and transmit it to the NIP gateway. The GSE decapsulator 2051 of the NIP gateway may then extract an IP stream including information on DVB-I service list entry points from the received GSE stream and output it to the IP filter 2052. The IP filter 2052 may extract information about DVB-I service list entry points from the IP stream and deliver it to DVB-I clients. In this case, the NIP gateway may perform the function of a local DVB-I service list registry.

In addition, in the unidirectional delivery structure, in order to transmit information on the DVB-I service list provided from the DVB-I service list server to the DVB-I client, the IP packetizer 2011 of the NIP transmitter may configure an IP stream including information on the DVB-I service list, and the GSE encapsulator 2012 may configure a GSE stream including the IP stream and transmit the GSE stream to the NIP gateway. The GSE decapsulator 2051 of the NIP gateway may then extract an IP stream including information on the DVB-I service list from the received GSE stream and output the IP stream to the IP filter 2052. The IP filter 2052 may extract information about the DVB-I service list from the IP stream and then deliver the information to the DVB-I client. In this case, the NIP gateway may perform the function of a local DVB-I service list server.

According to an embodiment, the IP filter 2052 may extract the NIF and/or SIF from the IP stream extracted by the GSE decapsulator 2051 and provide the NIF and/or SIF to the necessary blocks.

The multicast server may send multicast service data (e.g., media content) and signaling information for the multicast service to the multicast gateway via the M interface.

Here, the data transmitted via the M interface may include one or more multicast sessions for transmitting multicast service data and a multicast gateway configuration session for transmitting multicast gateway configuration information as follows.

Each multicast session may include a plurality of multicast transmission sessions. Each of the multicast transmission sessions may consist of a ROUTE session or a FLUTE session.

Each multicast transmission session may be identified by an IP address, UDP port, transmission Session ID (TSI), etc. Each multicast transmission session may be referred to as an IP multicast, a multicast stream, an IP multicast stream, or an IP stream.

In the unidirectional delivery structure, information related to the multicast gateway configuration session may be transmitted in an in-band multicast gateway configuration method.

According to an embodiment, the data constituting the multicast gateway configuration session may be a multicast gateway configuration file. As described above, the multicast gateway profile is configured as an IP flow through the IP packetizer 2011 and as a GSE flow and sent to the NIP gateway through the GSE encapsulator 2012.

In addition, each multicast transmission session transmitted from the multicast server through ROUTE or FLUTE may be composed of each IP stream. That is, the multicast transport session or the multicast gateway configuration session may each consist of an IP stream.

According to an embodiment, header compression may be selectively applied to each IP flow (i.e., IP multicast).

According to an embodiment, one or more IP flows to which header compression is applied are header compressed by the compressor 2014 through a ROHC scheme and then provided to the GSE encapsulator 2015, while one or more IP flows to which header compression is not applied are provided to the GSE encapsulator 2015.

According to an embodiment, a header_compression_flag field may be used to signal whether to compress the header on a per IP multicast basis. The header_compression_flag field is included in an IP multicast list (e.g., a multicast cycle of ip_multicast_list_descaler () of fig. 44 and a multicast cycle of IPv 6_multicast_list_descaler () of fig. 45).

That is, the header_compression_flag field indicates whether header compression is applied to the multicast stream (i.e., corresponding IP multicast or IP stream) identified by the multicast_stream_id field. For example, when the value of the header_compression_flag field is 0, it may indicate that header compression is not applied to a multicast stream (i.e., corresponding IP multicast or IP stream). When the value is 1, it may indicate that header compression is applied to the multicast stream (i.e., the corresponding IP multicast or IP stream).

Further, when the value of the header_compression_flag field is 1, signaling information (e.g., a robust header compression unidirectional mode (ROHC-U) descriptor) regarding configuration parameters related to header compression may be additionally transmitted. In this disclosure, the ROHC-U descriptor may be referred to as ROHC-U_multicast_descriptor or multicast_ROHC-U_descriptor.

According to an embodiment, the ROHC-U descriptor may be included in LLC data by an LLC builder 2013 and a GSE encapsulator 2012, and then encapsulated into at least one GSE packet and transmitted. That is, the present disclosure may provide for out-of-band (e.g., GSE-LLC) transmission of ROHC-U descriptors that include configuration parameters and context information.

A detailed description of information included in the ROHC-U descriptor will be provided later.

That is, in the unidirectional delivery structure, header compression may be selectively applied for each IP multicast (i.e., IP flows) including multicast service data of a multicast service and signaling information provided by a multicast server, and GSE flows including at least one IP flow to which header compression is applied and/or at least one IP flow to which header compression is not applied may be configured and transmitted to the NIP gateway. In this case, each GSE flow may include a plurality of IP multicasting. In case that the ROHC-based header compression is applied to the IP stream, the ROHC stream generated by the header compression is included in the corresponding GSE stream. According to an embodiment, the GSE stream may be transmitted via a terrestrial or satellite broadcast system. In this case, GSE streams may be distinguished based on PLP for terrestrial broadcasting systems. For satellite broadcast systems, GSE streams may be distinguished based on ISI. Then, the GSE decapsulator 2051 of the NIP gateway extracts at least one IP stream to which header compression is applied and/or at least one IP stream to which header compression is not applied from the received GSE stream. Then, at least one IP stream (i.e., ROHC stream) to which header compression is applied is output to the header decompressor 2055. The header decompressor 2055 header decompresses the header-compressed IP stream (i.e., ROHC stream) based on the ROHC-U descriptor supplied from the LLC parser 2053, and then outputs the decompressed stream to the IP filter 2056. Further, at least one IP flow to which header compression is not applied and extracted from the GSE flow is output to the IP filter 2056. Here, it is possible to check whether header compression is applied using a header_compression_flag field. According to an embodiment, LLC parser 2053 extracts LLC data from the GSE stream, and extracts header_compression_flag field from the LLC data. Then, when the value of the header_compression_flag field is 1, the parser extracts an ROHC-U descriptor from the LLC data and supplies the ROHC-U descriptor to the header decompressor 2055.

IP filter 2056 extracts one or more multicast sessions and multicast gateway configuration sessions from the incoming IP stream and outputs the one or more multicast sessions and the multicast gateway configuration session to the multicast gateway.

According to an embodiment, the multicast gateway receives one or more multicast transmission sessions encapsulated in IP multicast through a ROUTE session or a FLUTE session, and then provides the one or more multicast transmission sessions to a playback function via an L interface through an HTTP (S) (hypertext transfer protocol) (S) scheme or the like.

When the multicast gateway is configured for multicast services in an ISP network, it may be configured in a router or home gateway provided by the ISP operator. When the multicast gateway is configured for multicast services in a mobile network such as a 5G system, it may be configured in the mobile network. When the multicast gateway is configured for multicast services in a satellite broadcast network, it may be configured in a Set Top Box (STB) capable of receiving satellite broadcasts. When the multicast gateway is configured for multicast services in a terrestrial broadcast network, it may be configured in a broadcast receiver.

Fig. 48a and 48b are block diagrams illustrating a configuration of an entire system for multicast transmission/reception in a unidirectional delivery structure according to other embodiments. The systems of fig. 48a and 48b may be referred to as unidirectional delivery systems for transmitting/receiving multicast service data (e.g., multicast ABR content). Unidirectional delivery structures have the same meaning as unidirectional delivery systems.

Fig. 48a and 48b show data streams for transmitting GSE streams through a DVB-NIP based transmitter (NIP transmitter) and receiving GSE streams through a DVB-NIP based receiver (NIP receiver), according to embodiments.

In fig. 48a and 48b, the same reference numerals will be used for the same elements as those in fig. 47a and 47b, and redundant description thereof will be omitted.

In fig. 48a and 48b, an IP stream including a multicast gateway profile provided from a multicast server is output to the GSE encapsulator 2015, and an IP filter 2056 of an NIP receiver extracts the multicast gateway profile from the IP stream, unlike the configuration of fig. 47a and 47 b.

The operation of the transmitting device and the receiving device of fig. 47a and 47b or fig. 48a and 48b may be defined as follows.

The NIP transmitter may receive information about the DVB-I service list from the DVB-I service list server. In addition, it may encapsulate an IP stream including IP packets including multicast service data and multicast gateway configuration information into a GSE stream and transmit the GSE stream through PLP. In addition, it may generate LLC data including descriptors for GSE-LLC and ROHC-U descriptors, encapsulate the data into GSE streams, and send the streams through PLPs. In an embodiment, the PLP for transmitting the GSE stream including LLC data may be different from the PLP for transmitting the GSE stream including IP stream. Thus, the GSE stream may be identified by PLP ID.

The NIP transmitter may receive IP multicast including multicast service data from the multicast server based on the ROUTE session or the FLUTE session, and may receive an IP stream including multicast gateway configuration information. According to an embodiment, the NIP transmitter may generate the ROHC stream by performing IP header compression on a specific IP stream.

The NIP receiver may receive the GSE stream and parse the IP stream from the received GSE stream. In addition, it may deliver information about the DVB-I service list to the DVB-I client. The NIP receiver may extract an IP multicast including multicast service data and a multicast gateway configuration by filtering the IP stream and then deliver the IP multicast to the multicast gateway. Multicast configuration related operations may be handled based on the reference point M interface of the MABR.

The GSE stream according to an embodiment may be identical to the NIP stream or MPE stream. NIP stream is interpreted as a term referring to a stream comprising IP multicast data delivered by a DVB-NIP broadcast system.

Multicast service data transmitted on the broadcast channel is generated primarily by the multicast server, but may also be generated by the NIP signaling server associated with each NIP stream. Each NIP stream may have only a single multicast server connected to it. Each multicast server may create a multicast transmission session comprised of one or more multicast streams.

Next, ROHC-based header compression will be described.

The header compressor 2014 of the NIP transmitter may reduce the size of the header of the IP packet in the input IP stream based on the ROHC scheme. In addition, the header compressor 2014 may extract context information from the header-compressed IP packets and generate signaling information related to header compression. The header decompressor 2055 of the NIP receiver can reconstruct the original IP packet by restoring the header of the header compressed packet based on the signaling information and the context information. In this regard, the process of extracting context information from header-compressed IP packets and generating signaling information related to header compression is referred to as an adaptation process, and may be performed by a separate adaptation module.

In the present disclosure, for simplicity, an IP packet before compression is referred to as a data packet, and a packet compressed using the ROHC scheme is referred to as an ROHC packet (or a header-compressed data packet). In addition, a stream including IP packets before compression is referred to as an IP stream, an IP packet stream, an IP multicast stream, or an IP multicast, and a stream including ROHC packets is referred to as a ROHC packet stream (ROHC packet stream), a ROHC packet stream (ROHC packet flow), a ROHC IP stream, a ROHC stream, or a compressed IP stream.

According to an embodiment, a data packet, which is an IP packet before compression, is composed of a header and a payload, wherein the header includes an IP header and a UDP header.

During IP streaming, the IP version, source IP address, destination IP address, IP fragment flag, source port number, destination port number, etc. included in the information in the IP header and UDP header of the IP packet hardly change. In the present disclosure, as described above, a field carrying information which hardly changes during streaming is referred to as a static field. In addition, the information carried in the static field will be referred to as static information. In this disclosure, static information is used in the same sense as static chain information. In the ROHC compression scheme, after static information is transmitted once, additional transmission is not performed for a period of time. This is referred to as an initialization and refresh (hereinafter referred to as IR) state, and ROHC packets carrying static information in the header are referred to as IR packets.

In addition, separate additional transmissions are required for dynamic information that changes frequently but remains for some time. Dynamic information is carried in the dynamic field. In this disclosure, dynamic information is used in the same sense as dynamic chain information.

ROHC packets that carry dynamic information in the header are called IR-DYN packets. According to an embodiment, the IR packet also includes dynamic information. That is, since the IR packet and the IR-DYN packet contain all information of the existing header, their sizes are similar to those of the existing header.

Among ROHC packets, the remaining packets other than the IR packet and the IR-DYN packet will be referred to as compressed packets. According to an embodiment, the header of each compressed packet (or compressed packet) consists of only 1 byte of information or 2 bytes of information.

According to an embodiment, after performing header compression based on the ROHC scheme, an adaptive process of extracting context information from IR packets and/or IR-DYN packets and generating ROHC-U descriptors including the extracted context information and information (e.g., configuration parameters) related to header compression may be selectively performed.

According to an embodiment, separate flag information (e.g., adaptation_flag) may be used to signal whether to perform the adaptation process.

Next, a description will be provided of a case where the adaptive processing is performed. The adaptation process may be performed by the header compressor 2014 or may be performed by a separate adaptation module.

In addition, the adaptive process provides for out-of-band transmission of configuration parameters and context information between the compressor and the decompressor. That is, out-of-band transmission may be performed through GSE-LLC encapsulation of ROHC-U descriptors. In other words, the adaptation function is used to reduce decompression errors and channel change delays caused by the loss of context information.

In this disclosure, static chain information extracted from IR packets will be referred to as context information.

That is, IR packets are detected from an ROHC flow generated by applying header compression to an IP flow, and context information (i.e., static chain information) is extracted from the header of the detected IR packets. In an embodiment, the IR packets from which the context information is extracted are transformed into IR-DYN packets, and the transformed IR-DYN packets replace the original IR packets and are inserted into the ROHC stream in the same order. According to an embodiment, the extracted context information is included in an ROHC-U descriptor.

The ROHC stream from which the context information is extracted includes IR-DYN packets and compressed packets.

The ROHC flow from which the context information is extracted is encapsulated by the GSE encapsulator 2015 into one or more GSE packets, and the ROHC-U descriptor comprising the context information is comprised in the LLC data by the LLC builder 2013. GSE encapsulator 2012 then encapsulates the LLC data into at least one GSE packet.

The GSE stream including the GSE packet generated by the GSE encapsulator 2012 is sent to the GSE decapsulator 2051 in the NIP receiver of the NIP gateway, and the GSE stream including the GSE packet generated by the GSE encapsulator 2015 is sent to the GSE decapsulator 2054 in the NIP receiver of the NIP gateway.

According to an embodiment, the GSE stream may be transmitted through a terrestrial or satellite broadcast system. In this case, GSE streams may be distinguished by PLP IDs for terrestrial broadcasting systems. For satellite broadcast systems, GSE streams may be distinguished by ISI. For example, in a terrestrial broadcast system, a PLP for transmitting a GSE packet including an ROHC flow may be different from or the same as a PLP for transmitting a GSE packet including an ROHC-U descriptor.

When the adaptation process is not performed, the ROHC flow output to the GSE encapsulator 2015 includes at least one IR packet, one or more IR-DYN packets, and compressed packets. In this case, the ROHC-U descriptor may include information (e.g., information related to header compression) other than the context information.

Fig. 49 shows an exemplary syntax structure of an ROHC-U descriptor (ROHC-u_information ()) according to an embodiment. According to an embodiment, the ROHC-U descriptor may be referred to as ROHC-U information. Fig. 49 is an example for transmitting GSE streams via a terrestrial broadcast system. ISI may be used instead of PLP when GSE streams are transmitted via a satellite broadcast system.

The ROHC-U descriptor of fig. 49 may include num_plps fields.

The num_plps field indicates the number of PLPs signaled in the descriptor.

According to an embodiment, the ROHC-U descriptor may include as many first iteration statements as the value of the num_plps field.

The first iterative statement may include a plp_id field, a per_channel_configuration () and a num_contexts field.

The plp_id field identifies the PLP corresponding to the context signaled in this iterative statement of the "for" loop.

The per_channel_configuration () may include a max_cid field and a profile field.

The max_cid field indicates the maximum value of the context ID used according to the PLP identified by the plp_id field.

The profile field indicates the scope of the protocol (or layer) used to compress the IP packet.

Fig. 51 is a table showing an example of ROHC profile for DVB-GSE. In fig. 51, the value of the profile field is 0x0001, which indicates ROHC-based compression up to RTP, according to an embodiment. The value 0x0002 indicates ROHC-based compression up to UDP. The value 0x0003 indicates ROHC-based compression up to ESP. The value 0x0004 indicates ROHC-based compression up to IP.

The num_contexts field indicates the number of PLP-carried contexts (i.e., the number of compressed IP streams or the number of ROHC streams) identified by the plp_id field. The value of the num_contexts field cannot be greater than the value of the max_cid field.

According to an embodiment, the ROHC-U descriptor may include as many second iteration statements as the value of the num_contexts field.

The second iteration statement may include a context_id field, ip_stream_address (), and context_information (). According to an embodiment, ip_stream_address () may be referred to as mapping information, and context_information () may be referred to as context information.

The context_id field indicates a Context Identification (CID) of the compressed IP stream (i.e., ROHC stream).

The mapping information (ip_stream_address ()) may include an src_ip_addr field, a dest_ip_addr field, an src_udp_port field, and a dest_udp_port field. The mapping information provides a mapping between the IP stream and the context ID.

The src_ip_addr field, the dest_ip_addr field, the src_udp_port field, and the dest_udp_port field may indicate a source IP address, a destination IP address, a source UDP port number, and a destination UDP port number of a corresponding ROHC flow among ROHC flows delivered through PLPs identified by the plp_id field.

The context information (context_information ()) may include a static_chain_length field and a static_chain_byte () field. The context information is context information about the ROHC flow identified by the context_id field.

The static_chain_length field indicates the length of a field after static_chain_byte ().

The static_chain_byte () field may carry static information for initializing the ROHC-U decompressor. The size and structure of the fields depends on the context profile. The static_chain_byte () field may be defined as sub-header information of an IR packet.

According to an embodiment, since GSE streams are delivered to only one PLP, the number of PLPs identified by the num_plps field is equal to the number of GSE streams. Accordingly, the value of the plp_id field may be used as a value for identifying GSE flows and ROHC channels.

The fields, elements and attributes included in the ROHC-U descriptor described above may be omitted or replaced with other fields, elements and attributes, and additional fields, elements and attributes may be added according to embodiments.

Fig. 50a and 50b illustrate exemplary configuration block diagrams of a GSE layer system for transmitting GSE flows according to an embodiment. The diagrams of fig. 50a and 50b are mainly composed of an upper layer block 5100, a GSE layer block 5200, and a physical layer block 5300.

According to an embodiment, each data source in the upper layer block 5100 is multicast identified by a multicast_stream_id field. The data source may include at least multicast service data and multicast gateway configuration information. In addition, each data source may be identified by a source IP address, a destination IP address, a source UDP port number, and a destination UDP number. In the present disclosure, multicasting means transmitting data to a plurality of receivers simultaneously through an IP network, and also means transmitting a set of data to a plurality of receivers simultaneously through an IP network.

In this disclosure, multicasting is also referred to as IP multicast streaming, IP streaming, upper layer session, or multicast transmission session.

GSE layer block 5200 receives as input one or more multicasts from upper layer block 5100, generates one or more GSE streams, and then delivers the one or more GSE streams to physical layer block 5300. The physical layer block 5300 transmits one or more GSE streams via one or more PLPs. Each GSE flow includes one or more GSE packets.

In this case, the GSE stream is delivered to only one PLP. Accordingly, in order to deliver multiple GSE streams, the GSE layer block 5200 must include multiple GSE stream generators, and the physical layer block 5300 must also be configured to process data of multiple PLPs. For example, to generate and deliver k GSE streams (where k is greater than or equal to 2), k GSE stream generators and k PLPs are required.

In other words, each GSE stream output from each GSE stream generator of GSE layer block 5200 is delivered to its unique PLP. Accordingly, the PLP ID for identifying the PLP may be used as a GSE stream ID for identifying the corresponding GSE stream and a GSE stream generator ID for identifying the corresponding GSE stream generator.

In addition, in ROHC compression, the ROHC framework defines ROHC channels to identify compressed packet streams. In an embodiment of the present disclosure, a single ROHC channel is configured in a GSE flow. Accordingly, the PLP ID for identifying the PLP may be mapped to an ROHC channel number for identifying the ROHC channel.

That is, the ROHC channel, GSE stream, and PLP may be mapped in a 1:1:1 correspondence manner. Accordingly, the PLP ID for identifying the PLP may be used as an identifier for identifying the ROHC channel and an identifier for identifying the GSE flow.

According to an embodiment, each GSE-flow generator includes an IP header compressor configured to output ROHC flows and an encapsulation module configured to output GSE flows.

Next, header compression will be described based on the first GSE stream generator (GSE stream generator # 0).

The IP header compressor included in the first GSE stream generator may include an ROHC module and an adaptation module. The IP header compressor may correspond to the header compressor 2014 of fig. 47a and 47b or fig. 48a and 48 b. The ROHC module of the IP header compressor receives one or more IP packets in multicast and performs header compression. According to an embodiment, a value of a header_compression_flag field corresponding to one or more multicasts input to the ROHC module is 1.

When header compression is performed, ROHC packets corresponding to the IP packets before compression are generated. ROHC packets include IR packets, IR-DYN packets, and compressed packets. The stream comprising ROHC packets is called a ROHC stream (or compressed IP stream).

Then, the adaptation module extracts context information (e.g., static chain information in a header of an IR packet) from the ROHC stream according to adaptation_flag information, generates a ROHC-U descriptor including the extracted context information and information related to header compression, and outputs the descriptor to the GSE-LLC encapsulation module. The ROHC stream from which the context information is extracted is also output to the encapsulation module. That is, context information (i.e., static chain information) is extracted from a header of an IR packet among ROHC packets, and the IR packet from which the context information is extracted is converted into an IR-DYN packet. The transformed IR-DYN packets then replace the original IR packets and are output to the encapsulation module in the same order in the ROHC stream. That is, the ROHC stream output to the encapsulation module includes at least IR-DYN packets generated by header compression, transformed IR-DYN packets, and compressed packets.

According to an embodiment, adaptation flag information (adaptation_flag) indicates whether to perform adaptation processing (i.e., whether to extract context information). When the adaptation_flag indicates that the adaptation process is skipped (or omitted), the process of extracting the context information from the ROHC stream is skipped. In this case, the ROHC-U descriptor includes only information related to header compression. In this case, the ROHC flow output to the encapsulation module includes at least IR packets, IR-DYN packets, and compressed packets. According to an embodiment, adaptation_flag information may be signaled in the ROHC-U descriptor.

The GSL-LLC encapsulation module encapsulates GSL-LLC descriptors and ROHC-U descriptors for NCDs and LCDs into at least one GSE packet. In the present disclosure, GSL-LLC descriptors and ROHC-U descriptors for NCDs and LCDs are referred to as LLC data. In this case, according to an embodiment, LLC data including ROHC-U descriptors is included in mandatory extension headers of GSE packets.

The encapsulation module encapsulates the ROHC flow into one or more GSE packets.

In addition, the encapsulation module may generate one or more GSE packets that include one or more IP packets in multicast (i.e., IP packets with uncompressed headers). In this case, the value of the header_compression_flag field corresponding to one or more multicasts input to the encapsulation module is 0.

That is, the encapsulation module may include an encapsulator configured to generate one or more GSE packets including packets in the ROHC flow and an encapsulator including one or more GSE packets having IP packets that have not passed through the IP header compressor, or the encapsulation module may include at least one of the encapsulator.

In an embodiment, at least one GSE packet including an ROHC-U descriptor, one or more GSE packets including an ROHC flow, and/or one or more GSE packets including an IP flow that has not yet passed through an IP header compressor may be output to one GSE flow.

The GSE stream is delivered to the receiver via the corresponding PLP in the physical layer block 5300. In this case, PLP ID for identifying PLP is signaled in ROHC-U descriptor. For example, IP address/port information for identifying one or more compressed IP flows included in the GSE flow and mapping information for mapping PLPs to which the GSE flow is transmitted are signaled in the ROHC-U descriptor.

According to an embodiment, when the IP header compressor creates a header of an IR packet or an IR-DYN packet or a header of a compressed packet, the CID is assigned to the header.

CIDs are divided into small CIDs and 1-byte large CIDs. The small CID is again divided into a CID value of 0 and a CID value other than 0. When the CID value is not 0, the CID is composed of 4 Most Significant Bits (MSBs) indicating the presence of the CID and 4 Least Significant Bits (LSBs) signaling the actual CID value. When the CID value is 0, a field indicating the CID value is not present in the corresponding header. When the CID related field indicating the CID value is not present in the header of the ROHC packet, the receiver determines the CID of the packet to be 0.

As described above, PLPs are mapped to ROHC channels, and thus CIDs are separately managed at each PLP.

IP packets having the same combination of source IP address, destination IP address, source UDP port number, and destination UDP port number are considered the same IP flow. In addition, according to an embodiment, the same CID is assigned to an ROHC packet corresponding to an IP packet included in the same IP flow. In this case, according to an embodiment, the CID assigned to the IP flow is not assigned to other IP flows in the same ROHC channel. That is, CIDs are distinguished only within ROHC channels. For example, the IP stream #0 and the IP stream #1 included in the ROHC channel #0 must not be assigned the same CID, but the IP stream #0 included in the ROHC channel #0 and the IP stream #1 included in the ROHC channel #1 may be assigned the same CID. Here, assigning a CID to an IP flow means assigning a CID to each of headers of ROHC packets corresponding to the IP packets included in the IP flow. In this case, according to an embodiment, when the IP packets are included in the same IP flow, all CID values assigned to the header of the ROHC packet corresponding to the IP packets are the same. Thus, the CID may be used by a receiver to distinguish ROHC flows (i.e., compressed IP flows) that include ROHC packets.

For the second GSE stream generator (GSE stream generator # 1) and the third GSE stream generator (GSE stream generator #k) (which are not described above in order to avoid redundant description), reference is made to the description of the first GSE stream generator (GSE stream generator # 0).

According to an embodiment, the LLC data may include one or more ROHC-U descriptors. For example, LLC data generated by the first GSE flow generator may include a first ROHC-U descriptor generated by the first GSE flow generator and a second ROHC-U descriptor generated by the second GSE flow generator. As another example, the LLC data generated by the third GSE stream generator includes a third ROHC-U descriptor generated by the third GSE stream generator, and the LLC data is transmitted over the same PLP (plp#k) together with the third ROHC channel.

That is, signaling information may be transmitted to transmit IP multicast in the unidirectional delivery structure shown in fig. 47a and 47b or fig. 48a and 48b, respectively.

In this case, the signaling information may be transmitted through the same GSE stream as the media content or the multicast service data. Alternatively, the table (or file) including the signaling information may be transmitted through a GSE stream separate from the media content to ensure robustness to the signaling information. In this case, depending on the transmission system, the GSE stream may be identified using PLP (or PLP ID) or ISI.

Referring to fig. 50a and 50b as an example, a GSE stream #1 including an ROHC stream generated by a second GSE stream generator through header compression is transmitted through PLP #1, and a GSE stream #0 including an ROHC-U descriptor including information related to header compression and context information extracted from the ROHC stream is transmitted through PLP # 0. In this case, since GSE streams are mapped to PLPs in a 1:1 correspondence manner, PLP IDs for identifying PLPs may be used as identifiers for identifying GSE streams.

In fig. 50a and 50b, all or at least one IP header compressor of the plurality of GSE stream generators may operate, or none may operate.

Next, IP encapsulation of signaling information will be described. In the present disclosure, signaling information is used in the same sense as signaling data.

Fig. 52 illustrates an example of encapsulating signaling information into IP packets according to an embodiment. Here, according to an embodiment, the IP packet includes an IP header and a UDP header.

According to an embodiment, in order to identify (or filter) signaling information transmitted through a specific IP flow from among a plurality of IP flows received by an NIP gateway, the specific IP flow may include a fixed (or dedicated) IP address and a fixed (or dedicated) UDP port number. That is, the signaling information may be sent by the NIP sender as a payload of IP packets with a well-known IP address/UDP port number. In this case, the IP address may be "224.0.23.14", and the UDP port number may be "3937". In other words, the signaling information is encapsulated into an IP packet having an IP address of "224.0.23.14" and a UDP port number of "3937" and transmitted.

The signaling information may be referred to as an announcement channel, and may carry information required for the operation of the local IP system, according to an embodiment. The signaling information may carry a DVB-I service list, NIF and/or SIF, according to an embodiment. Each of the DVB-I service list, NIF and/or SIF included in or carried via the signaling information may be provided in the form of a signaling table (or signaling file). The signaling information may also include information about DVB-I service list entry points and/or multicast gateway configuration files, each of which is in the form of a signaling table (or file). The signaling information may also include NCD, LCD, or ROHC-U descriptors, respectively, in the form of signaling tables (or files). Here, the signaling table (or signaling file) included in the signaling information is merely an example for providing an understanding of the present disclosure. The signaling table (or signaling file) included in the signaling information is not limited to the above example.

That is, all IP packets including service information have the same IP address (e.g., fixed IP address "224.0.23.14") and UDP port number (e.g., fixed UDP port number "3937"). For example, in case the service information is assumed to include a DVB-I service list, NIF and/or SIF, all IP packets carrying the DVB-I service list, NIF and/or SIF have the same IP address and UDP port number.

Therefore, a method of identifying each signaling table included in an IP packet having an IP address of "224.0.23.14" and a UDP port number of "3937" is required.

To identify the signaling table included in the IP packet having the IP address of "224.0.23.14" and the UDP port number of "3937", a signaling header may be added to the IP packet having the IP address of "224.0.23.14" and the UDP port number of "3937". In this disclosure, this signaling header will be referred to as a common bit stream indicator. That is, the header of the IP packet having the IP address of "224.0.23.14" and the UDP port number of "3937" includes an IP header, a UDP header, and a common bit stream indicator.

According to an embodiment, the common bit stream indicator may comprise a table ID instead of the signaling file ID.

In addition, in order to quickly identify a signaling table (or signaling file) configured in an IP packet, a common bit stream indicator may be configured in a binary form.

According to an embodiment, an IPv6 based network may use the IP address "FF0X: 0:0:0:0:0:12d" to identify signaling information.

In addition, each signaling table (or signaling file) may be configured as an XML (extensible markup language) file, and may be compressed to achieve transmission efficiency. As the compression method, EXI (high-efficiency XML interchange format), gzip, zlib, or the like can be used. That is, signaling information including one or more signaling tables (or signaling files) is directly included or compressed and included in the payload of an IP packet having a fixed (or dedicated) IP packet address and a fixed (or dedicated) UDP port number.

For simplicity, the common bit stream indicator may be referred to as a binary signaling header or signaling header.

Fig. 53 shows an exemplary syntax structure of a Binary Signaling Header (binary_signaling_header ()) according to an embodiment.

In fig. 53, the table_id field is a unique id value of the correspondence table. That is, the table_id field represents an identifier for identifying the type of the correspondence table (or the correspondence file).

Fig. 54 is a table showing definitions of values of a signaling table (or signaling file) assigned to a table_id field to identify a corresponding IP packet directly included or compressed and included in a signaling header structure.

For example, when the value of the table_id field is 0x00, the table (or file) indicates a DVB-I broadcast service list entry point (technical operator). When the value is 0x01, the table (or file) indicates a DVB-I broadcast service list entry point (commercial operator). Further, when the value is 0x02, the table (or file) indicates a DVB-I broadcast list. When the value is 0x03, the table (or file) indicates a DVB-I playlist. In addition, when the value is 0x04, the table (or file) indicates a DVB-I broadcast content guide. When the value is 0x40, the table (or file) indicates the broadcast NIF technology network. In addition, when the value is 0x41, the table (or file) indicates the broadcast NIF operator network. When the value is 0x42, the table (or file) indicates the DVB-MABR gateway configuration instance file. When the value is 0x43, the table (or file) indicates timing information.

In fig. 53, a section_syntax_indicator field is an indicator defining a section format of a table (or file), and always has a fixed value of "1".

the table_length field indicates the length of a table (or file), and specifies the length in bytes from the portion after the table_length field to the last portion of the corresponding section.

The interactive_network_id field represents an identifier of a broadcast network for the current transmission.

The link_id field has an id value of a link to which information described in the current table is applied. For example, in the case of a terrestrial broadcast system, this field may have the same value as the PLP ID. In the case of a satellite broadcast system, this field may have the same value as ISI.

the table_compression field indicates how to compress the table constituting the payload of the IP packet.

For example, among the values of the table_compression field: 00 indicates no compression, and 01 indicates compression in the Efficient XML Interchange (EXI) format. Furthermore, 10 indicates compression according to gzip [ IETF RFC 1952], and 11 indicates compression according to zlib { IETF RFC 1950].

The version_number field indicates the version of the table.

The current_next_indicator field indicates whether the section table is currently applicable. For example, when the value of the current_next_indicator field is 1, it indicates that the section table is valid. When the value is 0, it indicates that the next transmitted section table is valid.

the table_number field indicates the number of a table included in the table. "0" is assigned to the first segment, which in turn increases.

The last_table_number field indicates the number of the last table.

Next, a multicast gateway configuration method in a unidirectional delivery environment will be described.

In-band multicast gateway configuration

According to an embodiment, to transmit multicast service data (e.g., multicast ABR service data) over a unidirectional link, an in-band multicast gateway configuration based on a multicast ABR architecture may be performed first.

According to an embodiment, the following operations may be performed to perform in-band multicast gateway configuration.

1) The multicast server and the multicast gateway need to have common information about one or more configured multicast transmission sessions. When receiving multicast service data from a multicast server in a unidirectional delivery environment, a multicast gateway may obtain information about a multicast transmission session to be received through a multicast session element.

2) The multicast gateway may begin receiving multicast service data (or referred to as multicast transport objects) from the multicast transport session before or after the playback function requests presentation of the manifest via the L-interface.

3) In order to acquire a multicast transmission object through a specific multicast transmission session within a currently configured multicast session, the multicast gateway subscribes to an IP multicast group indicated in a multicast transmission endpoint address.

According to an embodiment, a subscription procedure for a multicast transmission session may be performed before the session is in an active state. In this case, the multicast gateway may unsubscribe from the subscribed multicast transmission session when the subscribed multicast transmission session switches to an inactive state.

Next, a logical session will be described.

According to an embodiment, when the multicast gateway configuration method is used, not only a multicast session but also a separate session different from the multicast session may be defined. To this end, the M interface may configure the following logical session. According to an embodiment, the logical session may include a service list transfer session and/or a multicast gateway configuration session.

Service list transfer session

According to an embodiment, service list information may be sent from the service list registry to the application based on the architecture shown in fig. 47a and 47b or fig. 48a and 48 b. The service list information may include access information (e.g., URI, etc.) of the service.

According to an embodiment, when a unidirectional link is included between the service list registry and the application, the multicast service may send information to the multicast gateway via the M interface. In this case, the service list information may be delivered through the service list transmission session.

Multicast gateway configuration session

According to an embodiment, the multicast gateway configuration information provided from the multicast server is transmitted using an in-band configuration method. In the in-band configuration method, the multicast server may repeatedly send (carousel) the multicast gateway configuration instance document via the M interface.

According to other embodiments, the multicast gateway configuration information may be sent through a session that is logically or physically different from the multicast session sent via the M interface. Such a separate session may be referred to as a multicast gateway configuration transport session.

Not only multicast gateway configuration information but also presentation manifest media objects and initialization segment media objects may be sent through the multicast gateway configuration transfer session. The presentation manifest media object may comprise a master playlist of MPD or HLS of MPEG-DASH.

Fig. 55 and 56 illustrate an exemplary syntax structure of a multicast gateway configuration transmission session according to an embodiment. That is, multicastgateway configuration transport session is a container for multicast gateway configuration transport session parameters. The multicastgateway configuration transport session element may be configured as shown in fig. 55 and 56.

According to an embodiment, the multicastgateway configuration transport session may include transport security information, transport protocol information, endpoint address information, bit rate information, and Forward Error Correction (FEC) parameters.

In the element syntax of fig. 55 and 56, the elements "networksourceladdress", "Network DestinationGroupAddress" and "trafficdestinationport" included in the element "encompasse" may be defined as a source IP address, a destination (group) IP address and a UDP port number for transmitting the element "MulticastGatewayConfiguration TransportSession".

Next, a logical session configuration in the M interface will be described.

The signaling table described above may be transmitted over a particular session to the M interface of the multicast ABR.

Fig. 57 is a diagram illustrating an exemplary logical session configuration in an M interface according to an embodiment. That is, fig. 57 illustrates an example in which a multicast session, a multicast gateway configuration transmission session, and a service list transmission session are all included in one M interface.

Fig. 57 relates to an embodiment in the case where the multicast rendezvous service is included in a multicast gateway or configured in the same device.

According to an embodiment, the multicast server may not only configure a multicast session comprising a multicast transmission session for sending media objects (or referred to as multicast IP content), but also configure a multicast gateway to configure a transmission session and a service list transmission session.

According to an embodiment, a multicast gateway including a multicast rendezvous service may receive configuration information and media objects sent from a multicast server over all sessions.

In this case, the multicast gateway may complete the configuration through an internal operation of the multicast gateway based on configuration information transmitted through the multicast gateway configuration transmission session.

In addition, the multicast gateway may deliver service list information sent through the service list transfer session to an application that processes the corresponding data.

Fig. 58 is a diagram illustrating another exemplary logical session configuration in an M interface according to an embodiment. That is, fig. 58 illustrates an example in which a multicast session is included in one M interface and a multicast gateway configuration transmission session and a service list transmission session are included in the other M interface.

Fig. 58 is an embodiment where the multicast rendezvous service is included in a multicast gateway or configured in the same device.

According to an embodiment, the multicast server may not only configure a multicast session comprising a multicast transmission session for sending media objects, but also configure a multicast gateway configuration transmission session and a service list transmission session.

According to an embodiment, a multicast gateway receives a media object sent from a multicast server over a multicast transmission session. In addition, the multicast rendezvous service may receive configuration information sent from the multicast server over the multicast gateway configuration transmission session and deliver the configuration information to the multicast gateway. The multicast gateway may then complete the configuration through internal operations of the multicast gateway based on the configuration information.

In addition, the multicast rendezvous service may deliver service list information transmitted through the service list transfer session to an application that processes the corresponding data.

Fig. 59 is a diagram illustrating another exemplary logical session configuration in an M interface according to an embodiment. That is, fig. 59 illustrates an example in which a multicast session, a multicast gateway configuration transmission session, and a service list transmission session are respectively included in corresponding M interfaces.

Fig. 59 illustrates an embodiment in the case where the multicast rendezvous service is included in a multicast gateway or configured in the same device.

In addition, the service list receiver may deliver service list information transmitted through the service list transmission session to an application processing corresponding data.

According to an embodiment, an application controls a content playback function. For example, it may be an embedded control application (EPG application) of a TV or a set-top box or a third party application provided by a content provider. The interface used by the application to control playback of content may be implemented as a separate API or the like depending on each device. In addition, the interface used by the application to control content playback typically involves delivering a reference point (e.g., the URL of MPEG DASH MPD) of the presentation manifest to initiate playback of the individual linear services. The application may interact with the service management sub-function of the multicast gateway to discover the presence of linear services and to control the reception of services by the multicast gateway. Furthermore, an application may discover the presence of a linear service by individual interactions with application-specific service directory functions.

The apparatus according to the above-described embodiments may efficiently utilize various networks in broadcast and multicast transmissions based on operation/configuration and/or signaling information according to the embodiments.

Further, the method/apparatus according to the above-described embodiments may reduce network load in various streaming sessions related to various networks and/or apparatuses, thereby reducing implementation costs and efficiently providing ABR multicast services. To provide this effect, an architecture and flow according to an embodiment are required.

Operations according to embodiments described in the present disclosure may be performed by a transmitting apparatus/receiving apparatus including a memory and/or a processor according to embodiments. The memory may store a program for processing/controlling operations according to the embodiments, and the processor may control various operations described in the present specification. The processor may be referred to as a controller or the like. In an embodiment, the operations may be performed by firmware, software, and/or combinations thereof. The firmware, software, and/or combinations thereof may be stored in a processor or memory.

Fig. 60 illustrates a multicast transmission method according to an embodiment.

S6000: the multicast transmission method according to an embodiment may include transmitting multicast service data from a multicast server based on an interface.

S6010: the multicast transmission method may further include: information for multicast service data is generated.

Fig. 61 illustrates a multicast receiving method according to an embodiment.

S6100: the multicast receiving method according to an embodiment may include receiving multicast service data from a multicast server based on an interface.

S6110: the multicast receiving method may further include playing the multicast service by processing the multicast service data.

The multicast processing method according to fig. 60 and 61 may be performed in the multicast ABR structure shown in fig. 1 to 4 based on the flowchart shown in fig. 5 and the information for multicast shown in fig. 6 and 7.

The multicast processing method according to fig. 60 and 61 may process multicast service data based on the 5G network shown in fig. 8 to 10.

The multicast processing method according to fig. 60 and 61 may process multicast service data based on a plurality of networks shown in fig. 11 to 20.

The multicast processing method according to fig. 60 and 61 can process multicast service data based on a plurality of networks in the protocols and structures shown in fig. 21 to 26.

The multicast processing methods according to fig. 60 and 61 may generate and deliver the information for the multicast service shown in fig. 27 to 30, and the receiver may receive and play the multicast service data based on the information for the multicast.

The multicast processing method according to fig. 60 and 61 may generate, transmit, and process multicast service data in the systems shown in fig. 31 and 32.

The multicast processing method according to fig. 60 and 61 may include an operation of mapping between a multicast transmission session and a physical layer. In order to process a multicast signal through such inter-session mapping, mapping information for multicast is generated, transmitted, and received based on fig. 33 to 42.

Referring to fig. 34, an interface according to an embodiment may constitute a DVB-NIP standard broadcasting system. A multicast signal receiving apparatus that can receive multicast service data according to a local internet protocol, the multicast signal receiving apparatus comprising: a multicast gateway configured to receive multicast service data from a multicast server based on an interface; and a content playback unit configured to play the multicast service by executing the multicast service data.

Referring to fig. 35, an interface of an embodiment is configured according to the DVB-NIP protocol. The interface may include protocols including multicast transport session, user datagram protocol/internet protocol (UDP/IP), general Stream Encapsulation (GSE) layer, and physical layer.

Referring to fig. 41, 42, 44, or 45, embodiments may generate signaling information. The signaling information may be variously referred to as metadata, ABR transport session descriptors, IP multicast list descriptors, and the like. Logical Layer Control (LLC) information in the GSE layer may be sent. LLC information may include multicast list descriptors. The multicast list descriptor may include source IP address information, destination IP address information, source UDP port information, and destination UDP port information. The multicast list descriptor may also include a header_compression_flag to indicate whether header compression is performed for each IP multicast.

Referring to fig. 43, an LLC table for DVB-NIP may be defined. The reception apparatus according to an embodiment may receive Logical Link Control (LLC) data from the GSE layer, wherein the logical link control data may include Network Control Data (NCD) and Link Control Data (LCD). LLC data may also include ROHC-U descriptors. In addition, the NCD may include a multicast list descriptor for multicast, and the LCD may include a link identifier for the physical layer. Thus, a mapping between sessions may be indicated and multicast service data may be received.

Referring to fig. 50a and 50b, a GSE layer may be defined for DVB-NIP. In an embodiment, header compression of the IP flow may be selectively performed in the GSE layer. Header_compression_flag information may be used to signal whether header compression is performed for a particular IP stream (or IP multicast). According to an embodiment, header_compression_flag information may be included in the multicast list descriptor. The header-compressed IP stream and/or the non-header-compressed IP stream in the GSE layer are encapsulated into a GSE stream and then transmitted through a specific PLP.

Referring to fig. 47a and 47b or fig. 48a and 48b, an embodiment may include: a parser configured to parse LLC data; and a decompressor configured to receive a robust header compression (ROHC) stream included in the GSE stream and perform header decompression.

Referring to fig. 52 to 54, when signaling information including one or more signaling tables (or files) is transmitted in a specific IP stream, the signaling information is transmitted through an IP stream having a fixed (or dedicated) IP address and a fixed (or dedicated) UDP port number, so that the multicast gateway recognizes the IP stream, according to an embodiment. In addition, according to an embodiment, in order to identify each signaling table in the signaling information, the IP packets in the corresponding IP flow further comprise a signaling header, wherein the signaling header may comprise a table ID (or file ID). The signaling header is referred to as a common bit stream indicator or binary signaling header.

The receiving method according to an embodiment may include: receiving multicast service data from a multicast server based on the interface; and displaying the multicast service by processing the multicast service data.

The transmission method according to an embodiment may include: transmitting multicast service data from a multicast server based on an interface, wherein the interface may include a protocol including a multicast transmission session, a user datagram protocol/internet protocol (UDP/IP), a General Stream Encapsulation (GSE) layer, and a physical layer; and generating Logical Layer Control (LLC) data in the GSE layer.

Accordingly, problems associated with the absence of link technology between terrestrial broadcast and satellite broadcast and the absence of session information and interface configuration for multicast media transmissions can be solved. That is, to send DVB ABR multicast media objects in a unidirectional delivery network (such as the link between terrestrial broadcast and satellite broadcast defined in the DVB standard), an interface and signaling stream may be provided for interworking multicast transmission sessions with the broadcast stream.

Embodiments have been described in terms of methods and/or apparatus, and the description of methods and apparatus may be applied so as to be complementary to one another.

Although the drawings are described separately for simplicity, new embodiments may be devised by combining the embodiments shown in the respective drawings. A recording medium readable by a computer and recorded with a program for executing the above-described embodiments is also designed according to the needs of those skilled in the art and falls within the scope of the appended claims and their equivalents. The apparatus and method according to the embodiments may not be limited by the configuration and method of the above-described embodiments. Various modifications may be made to the embodiments by selectively combining all or some of the embodiments. Although the preferred embodiments have been described with reference to the accompanying drawings, those skilled in the art will appreciate that various modifications and changes can be made in the embodiments without departing from the spirit or scope of the present disclosure as described in the appended claims. These modifications cannot be individually understood from the technical idea or perspective of the embodiments.

The various elements of the apparatus of the embodiments may be implemented in hardware, software, firmware, or a combination thereof. The various elements of the embodiments may be implemented by a single chip (e.g., a single hardware circuit). According to embodiments, the components according to embodiments may be implemented as separate chips, respectively. According to an embodiment, at least one or more of the components of an apparatus according to an embodiment may comprise one or more processors capable of executing one or more programs. One or more programs may perform any one or more of the operations/methods according to embodiments, or include instructions for performing the operations/methods. Executable instructions for performing the methods/operations of an apparatus according to embodiments may be stored in a non-transitory CRM or other computer program product configured to be executed by one or more processors, or may be stored in a transitory CRM or other computer program product configured to be executed by one or more processors. In addition, the memory according to the embodiment may be used as a concept covering not only a volatile memory (e.g., RAM) but also a nonvolatile memory, a flash memory, and a PROM. In addition, it may also be implemented in the form of a carrier wave (such as transmission over the internet). In addition, the processor-readable recording medium may be distributed to computer systems connected through a network such that the processor-readable code is stored and executed in a distributed manner.

In this specification, the terms "/" and "," should be interpreted as meaning "and/or". For example, the expression "A/B" may mean "A and/or B". Further, "A, B" may mean "a and/or B. "furthermore," a/B/C "may mean" at least one of A, B and/or C ". Further, "a/B/C" may mean "at least one of A, B and/or C". In addition, in the present specification, the term "or" should be interpreted as meaning "and/or". For example, the expression "a or B" may 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 to indicate "additionally or alternatively".

Terms such as first and second may 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 element. For example, the first user input signal may be referred to as a second user input signal. Similarly, the second user input signal may be referred to as the first user input signal. The use of these terms should be construed as not departing from the scope of the various embodiments. The first user input signal and the second user input signal are both user input signals, but do not mean the same user input signal unless the context clearly indicates otherwise.

The terminology used to describe the embodiments is for the purpose of describing particular embodiments and is not intended to be limiting of the embodiments. As used in the description of the embodiments and the claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. 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 a drawing, number, step, element and/or component, and should be understood not to exclude the possibility of additionally the presence of a drawing, number, step, element and/or component. 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 relevant operation when a particular condition is met or interpreting a relevant definition in accordance with the particular condition.

Operations according to embodiments described in the present disclosure may be performed by a transmitting/receiving apparatus including a memory and/or a processor according to embodiments. The memory may store a program for processing/controlling operations according to the embodiments, and the processor may control various operations described in the present specification. The processor may be referred to as a controller or the like. In an embodiment, the operations may be performed by firmware, software, and/or combinations thereof. The firmware, software, and/or combinations thereof may be stored in a processor or memory.

The operations according to the above-described embodiments may be performed by the transmitting apparatus and/or the receiving apparatus according to the embodiments. The transmitting/receiving apparatus 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 embodiments; and a processor configured to control an operation of the transmitting/receiving device.

A processor may be referred to as a controller or the like and may correspond to, for example, hardware, software, and/or combinations thereof. Operations according to the above embodiments may be performed by a processor. In addition, the processor may be implemented as an encoder/decoder for the operation of the above-described embodiments.

Public mode

As described above, the related contents have been described in the best mode for carrying out the embodiment.

Industrial applicability

As described above, the embodiments may be applied to the multicast transmission/reception apparatus and system in whole or in part.

It will be apparent to those skilled in the art that various changes or modifications may be made to the embodiments within the scope of the embodiments.

Accordingly, the embodiments are intended to cover modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalents.

Claims

1. A method of transmitting a multicast signal in a multicast transmission signal system, the method comprising the steps of:

selectively performing header compression on an IP stream composed of internet protocol IP packets including multicast service data for a multicast service;

generating first signaling information including information related to the header compression while the header compression is performed on the IP stream;

generating second signaling information including information related to the multicast service; and

-transmitting said IP flow, said first signaling information and said second signaling information for selectively performing said header compression.

2. The method of claim 1, further comprising the step of:

extracting context information from a header-compressed IP stream generated by performing the header compression on the IP stream,

wherein the first signaling information further comprises the extracted context information.

3. The method according to claim 2,

wherein the header-compressed IP stream includes at least one initialization and refresh IR packet, at least one IR-dynamic IR-DYN packet, and a compressed packet, and

wherein the context information is static chain information included in a header of the at least one IR packet.

4. The method according to claim 2,

wherein the second signaling information includes the first signaling information, and

wherein the second signaling information further includes link control data and network control data.

5. The method according to claim 4, wherein the method comprises,

wherein the network control data includes at least identification information for identifying a multicast stream including the multicast service data, information for indicating whether to perform the header compression on the IP stream, and address and port information for identifying the IP stream.

6. The method of claim 1, further comprising the step of:

generates third signaling information including information related to system operation,

wherein the third signaling information comprises a plurality of signaling files, an

Wherein the third signaling information is included in at least one IP packet having a fixed IP address and a fixed port number.

7. The method according to claim 6, wherein the method comprises,

wherein the header of the at least one IP packet including the third signaling information further includes a signaling header, and

wherein the signaling header includes information identifying each of the plurality of signaling files.

8. The method of claim 1, wherein the step of transmitting comprises:

encapsulating the IP stream for selectively performing the header compression into a first generic stream encapsulation GSE stream;

encapsulating the first signaling information and the second signaling information into a second GSE stream; and

and transmitting the first GSE flow and the second GSE flow.

9. The method according to claim 8, wherein the method comprises,

wherein the first and second GSE flows are transmitted over different physical links.

10. A multicast transmission signal system for transmitting a multicast signal, the multicast transmission signal system comprising:

a header compressor configured to selectively perform header compression on an IP stream composed of internet protocol IP packets including multicast service data for a multicast service;

a first generator configured to generate first signaling information including information related to the header compression when the header compression is performed on the IP stream;

a second generator configured to generate second signaling information including information related to the multicast service; and

a transmitter configured to transmit the IP stream, the first signaling information, and the second signaling information for selectively performing the header compression.

11. The multicast transmission signal system of claim 10, the multicast transmission signal system further comprising:

a context information extractor configured to extract context information from a header-compressed IP stream generated by performing the header compression on the IP stream,

12. The multicast signaling system of claim 11,

13. The multicast signaling system of claim 11,

wherein the second signaling information includes the first signaling information,

wherein the second signaling information further includes link control data and network control data, and

14. The multicast transmission signal system of claim 10, the multicast transmission signal system further comprising:

a third generator configured to generate third signaling information including information related to system operation,

15. The multicast signaling system of claim 14,