Patent Description:
Typically, conventional broadcast networks take advantage of moving picture experts group-<NUM> transport stream (MPEG-<NUM> TS) to transmit media content. MPEG-<NUM> TS is used as a representative transmission technique for multiple broadcast programs (multiple encoded video bit streams) to transmit multiplexed bit streams in erroneous transmission environments. As an example, MPEG-<NUM> TS is appropriate for, e.g., digital TV broadcast in the multimedia era. However, MPEG-<NUM> TS has its own limitations in supporting multimedia services. For example, upon transmitting the transport protocol and Internet protocol (IP) specified for audio/video, MPEG-<NUM> TS may cause unnecessary overhead due to inefficiency in transmission attributable to uni-lateral communication and fixed frame sizes. Thus, the MPEG has proposed MPEG media transport (MMT) as a multimedia transmission technique to support multimedia services based on MPEG technology. In particular, the MMT standard has been suggested in order to overcome the limitations of MPEG-<NUM> TS.

The MMT standard is applicable for efficiently transmitting composite content over a hybrid network. Here, 'composite content' refers to a set of contents with multimedia components of videos/audios/applications/widgets. 'Hybrid network' means a mixed network of, e.g., a broadcast network and a telecommunications network.

Further, the MMT standard defines IP friendlier transmission techniques which are basic for transmission networks for multimedia services. In other words, there are ongoing research efforts in relation to the MMT standard in order to provide efficient MPEG transmission technology in varying, representatively IP-based, multimedia service environments.

<NPL>) discloses a Video Insertion, VI, message that is used for video insertion, such as a personalized advertisement.

<CIT> discloses a content delivery system and method that receives a request for a content stream that includes splice points. The method receives a playlist that includes an ordered list of media segment files that represent the content stream, and splice point tags, where generation of the media segment files aligns segment boundaries with the splice points in the content stream, and where each splice point tag is in a location in the playlist that corresponds to the position of one of the splice points in the content stream. The method identifies an insertion position in the playlist based on the location of the splice point tags, selects an advertisement segment, inserts the advertisement segment at the insertion position to create a modified playlist, removes the splice point tags from the modified playlist, and sends the modified playlist to the video display device.

<NPL>, discloses the modification of an asset in a MANE in the network before rendering at a client. The aim is to improve robustness or quality.

According to an embodiment of the disclosure, there is provided a method and device for providing media content.

According to an embodiment of the disclosure, there is provided a method and device for transmitting and receiving signaling information related to media content to provide the media content.

According to an embodiment of the disclosure, there is provided a method and device for modifying/replacing/overlaying particular media data of first media content, thereby providing second media content.

According to an embodiment of the disclosure, there is provided a method and device for transmitting and receiving information indicating that particular media data of first media content is modified/replaced/overlaid.

According to an embodiment of the disclosure, there is provided a method and device for updating relevant signaling messages where particular media data of first media content is modified/replaced/overlaid.

According to an embodiment of the disclosure, a method for providing media content comprises receiving a modification request message requesting to modify particular media data of at least part of the media content, updating a signaling message for consuming the media content based on the modification request message, and transmitting the updated signaling message to a receiving entity.

According to an embodiment of the disclosure, a device configured to provide media content comprises a transceiver configured to receive a modification request message requesting to modify particular media data of at least part of the media content and a controller configured to update a signaling message for consuming the media content based on the modification request message, wherein the transceiver is configured to transmit the updated signaling message to a receiving entity.

Hereinafter, embodiments of the present disclosure are described in detail with reference to the accompanying drawings. The same reference numerals are used to refer to same elements throughout the drawings. When determined to make the subject matter of the present disclosure unclear, the detailed of the known functions or configurations may be skipped. The terms as used herein are defined considering the functions in the present disclosure and may be replaced with other terms according to the intention or practice of the user or operator. Therefore, the terms should be defined based on the overall disclosure.

Before getting into the detailed description of the disclosure, particular terms or phrases used herein may be defined merely for ease of description.

As used herein, the terms "include" and "comprise" and their derivatives may mean doing so without any limitations. As used herein, the term "or" may mean "and/or. " As used herein, the phrase "associated with" and "associated therewith" and their derivatives may mean "include," "be included within," "interconnect with," "contain," "be contained within," "connect to or with," "couple to or with," "be communicable with," "cooperate with," "interleave," "juxtapose," "be proximate to, "be bound to or with, "have, or "have a property of. " As used herein, the term "controller" may mean any device, system, or part thereof controlling at least one operation. As used herein, the term "device" may be implemented in hardware, firmware, software, or some combinations of at least two thereof.

The term "controller" means a device, system, or par thereof, to control at least one operation. The device may be implemented in hardware, firmware, software, or a combination of some of at least two thereof. It should be noted that functions, whatever particular controller is associated therewith, may be concentrated or distributed or implemented locally or remotely. It should be appreciated by one of ordinary skill in the art that the definitions of particular terms or phrases as used herein may be adopted for existing or future in many cases or even though not in most cases.

Hereinafter, embodiments of the disclosure are described. The embodiments of the disclosure are described for MPEG media transport (MMT) broadcast systems. This is merely for ease of description purposes and should not be interpreted as limiting the disclosure to MMT broadcast systems.

<FIG> is a view illustrating an MMT data model according to the disclosure.

The MMT defines an MMT flow, called a package <NUM>, which is a set of encoded media data and its related information, i.e., metadata.

The package <NUM> includes at least one MMT asset <NUM>, <NUM>, and <NUM>, at least one piece of "transport characteristic" or "asset delivery characteristics (ADC) (<NUM> and <NUM>) information, and at least one piece of presentation information (PI) <NUM>. For reference, 'MMT asset' means multimedia data that can be used to produce a multimedia presentation, such as video, audio, text, file, or widget.

Each MMT asset <NUM>, <NUM>, and <NUM> may be divided into at least one media processing unit (MPU). <FIG> illustrates that MMT asset <NUM><NUM> is divided into multiple MPUs <NUM>, <NUM>,. 'MPU' refers to the unit of data in which an MMT stream is independently processed, i.e., transmitted or decoded. Meanwhile, one MPU can be split into multiple fragments, and each fragment is called a "MPU fragment unit (MFU).

An MMT transmitting entity splits and processes media data in MPU units, and an MMT receiving entity receives, as well as processes for playback, media data in MPU units. For reference, the MPU contains media data and various pieces of information related to the media data.

The transport characteristic information, or ADC <NUM> and <NUM>, contains information for providing the transport characteristics of the MMT asset per MMT asset. That is, the ADC <NUM> represents the transport characteristics of asset <NUM><NUM>, and the ADC <NUM> represents the transport characteristics of asset <NUM><NUM> and asset <NUM><NUM>.

The presentation information (PI) <NUM> contains information to describe temporal and spatial relationships between the plurality of assets <NUM>, <NUM>, and <NUM>.

<FIG> is a view schematically illustrating an example in which an MMT transmitting entity <NUM> and an MMT receiving entity <NUM> transmit and receive MMT packages according to the disclosure.

The MMT transmitting entity <NUM> (hereinafter, simply referred to as a "transmitting entity <NUM>") transmits packages, as MMT packet flows, to the MMT receiving entity <NUM> (hereinafter, simply referred to as a "receiving entity <NUM>"). Meanwhile, the transmitting entity <NUM> may be any entity to transmit MMT media data, e.g., an MMT broadcast server. The receiving entity <NUM> may be any entity to receive MMT media data, e.g., an MMT client terminal or user equipment (UE).

The transmitting entity <NUM> may gather contents from asset providers <NUM> and <NUM> based on the presentation information (PI) of the package provided by the package provider <NUM>. Here, the package provider <NUM> and the asset providers <NUM> and <NUM> may be located physically together.

The transmitting entity <NUM> may transmit the package, which contains the asset, transport characteristic information, and presentation information, via an MMT protocol (MMTP) (<NUM>). The transmitting entity <NUM> and the receiving entity <NUM> may transmit and receive signaling information via the MMTP (<NUM>). The signaling messages are transmitted and received to manage the delivery and consumption of the package.

For reference, the MMT protocol is briefly described. The MMT protocol is an application layer transport protocol to packetize and transmit MMT packages, and has been designed to efficiently and reliably transmit packages. The MMT protocol has enhanced features, such as media multiplexing and network jitter calculation. These features allow for efficient transmission of content consisting of media data encoded in various types. The MMT protocol may operate on a higher layer of the existing network protocol, e.g., UDP or IP. Further, the MMT protocol has been designed to support various applications.

If the transmitting entity <NUM> is an MMT broadcast server, and the receiving entity <NUM> is a UE, then the MMT broadcast server may transmit MMT media data to the UE via a base station, or a transmitting entity performing similar functions over the network. The transmitting entity performing similar functions to the base station over the network may be, e.g., an access point (AP) in a wireless LAN system. For ease of description, the term "base station" is used to encompass a base station in a cellular communication system and an AP in a wireless LAN communication system. In the MMT system, the above-described network entity is referred to as an MMT-aware network entity (MANE). " In the MMT system, the MANE is defined as a network entity able to be aware of the types and characteristics of media carried by the MANE using means provided by MMT technology. The MANE may obtain media-related information from, e.g., the headers of MMTP packets and the MMT signaling message, carried by the media. The media-related information enables media-aware operations.

Hereinafter, embodiments of the disclosure are described in detail.

The basic concept of the disclosure is that the network server receives first content from the broadcaster server and provides the same to the user while providing second content, e.g., a separate advertisement, to the user. Specifically, upon receiving a message requesting to change the media data of at least part of the first content while processing the signaling message related to the first content, the network entity updates the signaling message related to the change-requested media data and transmits the updated signaling message to the user, thereby providing the second content to the user. In some cases, however, the second content may be served overlaid on the first content. To that end, flag information (asset_modification_flag) is defined in the first content-related signaling message to indicate the modification to the media data, according to the disclosure. Further, according to the disclosure, a message (AssetChangeRequest_message) is newly defined in order to request to modify/replace/overlay the first content in relation to the second content.

Prior to the description of embodiments of the disclosure, the signaling message (or "signaling information") is briefly described. The media service provider produces and provides content resource information and media content signaling information to provide MMT-based media services. The MMT defines the signaling message to transmit and receive information necessary for the delivery or consumption of packages.

The signaling messages related to the consumption of the package include the following messages.

The signaling messages defined for package delivery are as follows.

According to an embodiment of the disclosure, among the signaling messages, the PA message may be used. Thus, the PA message is described below.

The PA message carries the PA table. The PA table contains information for all of the other signaling tables for packages. The PA message carries the MPI table and MP table for transferring the minimum information for package processing.

The MMT receiving entity should process the PA message before processing any other signaling messages.

The syntax of the PA message is as shown in Table <NUM> below.

The semantics of the PA message are defined as shown in Table <NUM> in the MMT standard specifications.

Meanwhile, the MP table contains list information about all of the assets constituting a particular package. The MP table is defined in the MMT standard specifications as shown in Table <NUM> below.

The syntax of the MP table defined in the MMT standard specifications is as shown in Tables <NUM> and 4B below.

The semantics of the MP table defined in the MMT standard specifications are as shown in Tables <NUM>, 5B, and 5C below.

Embodiments of the disclosure are described below with reference to <FIG>.

<FIG> is a view illustrating an MMT transmission/reception system including a MANE <NUM> according to an embodiment of the disclosure.

Compared to <FIG>, <FIG> illustrates the presence of a MANE <NUM> between a transmitting entity <NUM> and a receiving entity <NUM>. <FIG> further illustrates a third MMT transmitting entity (3rd party entity) <NUM> (hereinafter, simply referred to as a "third entity"), e.g., a local broadcast station. According to an embodiment of the disclosure, the MANE receives a package and a signaling message from the transmitting entity <NUM>. Here, the signaling message contains flag information that indicates modifying a particular asset in the package. The flag information is described below. For reference, the term "package", as used hereinafter, may be interchangeably used with "media content.

The MMT transmitting entity <NUM> produces MMT-based media content resource information and media content signaling information. Hereinafter, "MMT transmitting entity" may be simply referred to as a "transmitting entity.

The third entity <NUM> provides separate, MMT-based media content resource information and media content signaling information to allow the content provider or service provider to provide additional services, e.g., targeted advertising for particular users.

The MANE <NUM> gathers the MMT-based media content resource information, media content signaling information, and the separate MMT-based media content resource information and media content signaling information for providing additional services within the content and business network, updates, e.g., expands or edits, the existing MMT-based media content resource information and media content signaling information, and retransmits the updated information to the receiving entity <NUM>.

The MMT receiving entity <NUM> receives the MMT-based media content resource information and media content signaling information through the MANE <NUM>, and serves the media content to the user. Hereinafter, "MMT receiving entity" may be simply referred to as a "receiving entity.

The transmitting entity <NUM> produces MMT-based media content resource information and media content-related signaling information and transmits the information to the receiving entity <NUM> via the MANE <NUM> so that the service user can receive his desired information and use the service.

At this time, the content and service provider may provide additional services, e.g., targeted advertising or biased broadcasting, not via the transmitting entity <NUM> but via the third entity <NUM>. The MANE <NUM> receives the MMT-based media content resource information and media content signaling information from the transmitting entity <NUM> and the other MMT-based media content resource information and media content signaling information from the third entity <NUM> and expands or edits the media content provided from the transmitting entity <NUM>, thereby providing the same to the receiving entity <NUM>.

At this time, to provide an additional service, the content and service provider puts a message for the additional service in the media content-related signaling information transmitted from the transmitting entity <NUM> or adds information for the additional service to the MMT signaling message, e.g., PA message, defined in the existing MMT signaling message and provides the same to the MANE <NUM>, thereby allowing the MANE <NUM> to perform operations related to the additional service. As an example, an "asset_modification_flag" may be included in the MP table within the PA message of the MMT signaling message, according to the disclosure. As another example, an "asset_modificaiton_flag" may be included in a particular signaling message to carry the list information of all the assets constituting the package. The "asset_modification_flag" is a field able to indicate that a particular asset in the package is modified. The "asset_modification_flag" is described below in greater detail.

Meanwhile, to request the third entity <NUM> to provide the additional service to the user via the MANE <NUM>, there is a defined signaling message requesting to modify/replace/overlay at least part of the media content that the MANE receives from the transmitting entity <NUM> into/with/on the media content for the additional service. In this disclosure, this message is defined as an "asset change request (ACR)" message, which is described below in detail.

In other words, the third entity <NUM> transfers the media content signaling information and the media content resource information for the additional service to the MANE <NUM> via the "AssetChangeRequest" message. The third entity <NUM> may request to modify particular aseets of the assets in the package that the transmitting entity <NUM> transmits or to insert, replace, or overlay the particular assets with other media content by transferring the asset change request_message to the MANE <NUM>.

To modify/insert/replace/overlay the particular assets, the third entity <NUM> provides a package identifier (package_id), asset identifier (asset_id), or other resource information, thereby requesting the MANE <NUM> to modify/insert/replace/overlay the resource for the additional service for the particular assets. Hereinafter, "modify/insert/replace/overlay" may collectively be referred to as "modify/replace.

In an additional embodiment, the user's property information (e.g., user_preference_info), such as their gender or age, may be transmitted to the MANE <NUM> in the asset change request message. The user's property information may be used to provide a targeted service suited for the users corresponding to the user property information. In other words, upon receiving the user property information, the MANE <NUM> may transmit the user property information to the service provider while requesting an additional service (e.g., a targeted service) for the users corresponding to the property information.

Meanwhile, upon receiving the asset change request message, the MANE <NUM> updates the MP tables in all the PA messages related to the change-requested asset based on the asset change request message and transmits the updated result to the receiving entity <NUM>. At this time, the "asset_modification_flag" in the MP tables may be set to <NUM>, indicating that the asset has been modified/replaced. Further, upon receiving the asset change request message, the MANE <NUM> may update the particular signaling message to carry the list information of all the assets constituting the package based on the asset change request message and transmit the updated result to the receiving entity <NUM>. At this time, the MANE <NUM> may set the "asset_modification_flag" in the particular signaling message carrying the list information of all the assets constituting the package to <NUM>, thereby indicating that the asset has been modified/replaced. In other words, the MANE <NUM> modifies the MMT-based content resource information and media content-related signaling information received from the transmitting entity <NUM> using the asset change request information received through the third entity <NUM> and provides the modified MMT-based content resource information and media content signaling information to the receiving entity <NUM>, i.e., the service user, thereby providing the additional service to the user.

The content and service provider may provide the additional service, e.g., targeted advertising or biased broadcasting, via the transmitting entity <NUM>. The MANE <NUM> receives the MMT-based media content resource information and media content signaling information from the transmitting entity <NUM> and the other MMT-based media content resource information from the third entity <NUM> and expands or edits the media content provided from the transmitting entity <NUM>, thereby providing the same to the receiving entity <NUM>.

That is, the transmitting entity <NUM> transfers the media content resource information, which the third entity <NUM> has, to the MANE <NUM> through the "AssetChangeRequest" message. The third entity <NUM> may request to modify particular assets of the assets in the package that the transmitting entity <NUM> transmits or to insert, replace, or overlay the particular assets with other media content by transferring the asset change request_message to the MANE <NUM>.

To modify/insert/replace/overlay the particular assets, the transmitting entity <NUM> provides a package identifier (package_id), asset identifier (asset_id), or other resource information, thereby requesting the MANE <NUM> to modify/insert/replace/overlay the resource for the additional service for the particular assets. Hereinafter, "modify/insert/replace/overlay" may collectively be referred to as "modify/replace.

Meanwhile, upon receiving the asset change request message, the MANE <NUM> updates the MP tables in all the PA messages related to the change-requested asset based on the asset change request message and transmits the updated result to the receiving entity <NUM>. At this time, the "asset_modification_flag" in the MP tables may be set to <NUM>, indicating that the asset has been modified/replaced.

Further, upon receiving the asset change request message, the MANE <NUM> may update the particular signaling message to carry the list information of all the assets constituting the package based on the asset change request message and transmit the updated result to the receiving entity <NUM>. At this time, the MANE <NUM> may set the "asset_modification_flag" in the particular signaling message carrying the list information of all the assets constituting the package to <NUM>, thereby indicating that the asset has been modified/replaced.

In other words, the MANE <NUM> modifies the MMT-based content resource information and media content-related signaling information received from the transmitting entity <NUM> using the asset change request information received through the transmitting entity <NUM> and provides the modified MMT-based content resource information and media content signaling information to the receiving entity <NUM>, i.e., the service user, thereby providing the additional service to the user.

The receiving entity <NUM> may render the media content to provide the additional service as per the updated MP table. If rendering the additional service is terminated, the MANE restores the MP table updated based on the asset change request message with the MP table received from the transmitting entity <NUM> and sends the same back to the receiving entity <NUM>, providing the original media content to the receiving entity <NUM>.

<FIG> is a view illustrating basic operations of a MANE according to an embodiment of the disclosure.

In step <NUM>, a signaling message related to the first media content is received from the transmitting entity <NUM>. For reference, the transmitting entity <NUM> may directly transmit the first media content to the MANE <NUM>. Further, unless the first media content is directly transmitted to the MANE <NUM>, location information of the media content may be included in the MP table, allowing the MANE <NUM> or receiving entity <NUM> to implement the first media content. Meanwhile, the "asset_modification_flag" is newly defined in the MP table of the signaling message, according to the disclosure.

In step <NUM>, a modification request message is received to modify particular media data of the first media content. The modification request message contains the particular message-related information and information related to second content to be provided to the user. In this disclosure, an asset change request message is defined as the modification request message.

In step <NUM>, the signaling message related to the particular media data requested to be modified is updated based on the modification request message.

In step <NUM>, the updated signaling message is transmitted to the receiving entity <NUM>.

Meanwhile, the MANE <NUM> may not only update the signaling message related to the particular media data requested to be modified in step <NUM> but directly modify the modification-requested particular media data of the first media content into the second content as well. At this time, the MANE <NUM> transmits not only the updated signaling message, but also the first media content, which has been modified from the particular media data based on the modification request message, to the receiving entity <NUM> in step <NUM>.

<FIG> and <FIG> are views illustrating detailed operations of a MANE according to an embodiment of the disclosure.

<FIG> and <FIG> are shown on two sheets due to the sheet size although they are intended to be a single view.

In step <NUM>, the MANE receives an MMTP packet flow. In step <NUM>, the MANE determines whether a request to process, e.g., replace/insert/overlay, content, has been received. For example, the MANE determines whether it has received a particular signaling message to carry the list information of all the assets constituting the package containing the "asset_modification_flag" or the PA message containing the MP table containing the "asset_modification_flag", i.e., the flag information indicating that a particular asset may be modified/replaced. Without receiving the processing request, the procedure terminates. Upon receiving the processing request, the procedure goes to step <NUM>, transmitting a response message to the entity having transmitted the processing request. For reference, step <NUM> may be omitted depending on the configuration of the MMT system.

Thereafter, in step <NUM>, the MANE identifies the first package corresponding to the target for content processing in the received MMTP flow. In step <NUM>, the MANE determines whether it has received a request to process, e.g., replace/insert/overlay, content for the assets constituting the first package. Upon receiving the processing request, the MANE goes to step <NUM>, transmitting a response message to the requesting entity and identifying the first asset, which is the target for processing, in step <NUM>. Without receiving the processing request, the MANE immediately goes to step <NUM>. For reference, step <NUM> may be omitted depending on the configuration of the MMT system.

Meanwhile, in step <NUM>, the type of processing request is identified. That is, whether the processing request is replace/insert/overlay is identified. In step <NUM>, the MANE identifies the start time and duration of processing. Thereafter, in step <NUM>, the MANE modifies/replaces the first package to constitute the second package to be able to send the second asset instead of the first asset during the processing duration from the processing start time. For reference, in constituting the second package by modifying/replacing the first package to send the second asset instead of the first asset in step <NUM>, the MANE may modify the portion related to the first asset in the MMT signaling message related to the first package to be related to the second asset, thereby defining the same as the second package-related MMT signaling message.

Meanwhile, in step <NUM>, the MANE processes the modification/replacement of the content and then determines the time to resume the transmission of the first package. In step <NUM>, the MANE determines whether the processing end time has arrived, and if so, goes to step <NUM>, informing the relevant entity that the modification/replacement of the content has terminated. Unless the processing end time has arrived, the MANE goes to step <NUM>, sending out the second package. Meanwhile, in step <NUM>, the MANE resumes the prior first package transmission.

Thereafter, when the request to modify the additional service is terminated based on the asset change request message received from the third entity <NUM> or the transmitting entity <NUM> or the additional service is not provided any longer, it is transferred to the receiving entity <NUM> based on the MMT-based content resource information and media content signaling information received from the transmitting entity <NUM> and stored in the MANE <NUM>, thereby providing the media content service.

As set forth above, the multimedia transmission system according to an embodiment of the disclosure may modify/replace, in-real time, the video/audio assets constituting the service depending on the provider's intent.

In the multimedia transmission system according to an embodiment of the disclosure, the transmitting entity <NUM> continuously transfers the original assets to the MANE <NUM>, and the third entity <NUM> transfers "at least one asset to replace the original assets" (hereinafter, simply referred to as "replacement assets") to the MANE <NUM> during a particular time period. At this time, the replacement assets that the third entity <NUM> has transferred are used to replace the original assets in the MANE <NUM> or the receiving entity <NUM>.

When the MANE <NUM> replaces the original assets using the replacement assets, the MANE <NUM> may replace the MPUs constituting the original assets with the MPUs constituting the replacement assets or add the replacement assets as a new component of the package.

When the replacement is performed in MPU units, the MPUs constituting the replacement assets may be packetized into MMTP packets in the MANE <NUM>. At this time, information of the MMTP packet headers may be reset in the MANE <NUM> for continuity. The reset information may be at least one of a "timestamp," "packet_sequence_number," and "packet_counter.

When the MANE <NUM> adds the replacement assets as a new component for the package, the MANE <NUM> generates signaling information to inform the receiving entity <NUM> of the same. At this time, the signaling information contains at least one of information about the replacement assets and information about the relationship between the replacement assets and the original assets.

When the receiving entity <NUM> replaces the original assets using the replacement assets, the MANE <NUM> adds the replacement assets as a new component for the package and produces signaling information to inform the receiving entity <NUM> of the same and transfers the signaling information to the receiving entity <NUM>. At this time, the signaling information contains at least one of information about the replacement assets and information about the relationship between the replacement assets and the original assets. Meanwhile, according to another embodiment of the disclosure, the replacement assets may be transferred from the third entity <NUM> directly to the receiving entity <NUM> without passing through the MANE <NUM>.

In the multimedia transmission system according to an embodiment of the disclosure, the original assets may be buffered in the transmitting entity <NUM>, the MANE <NUM>, or the receiving entity <NUM> during the time period when the replacement assets should be played. At this time, the MANE <NUM> may reset the MMTP packet header information or signaling information to continuously provide the service after the buffering time. The reset MMTP packet header information contains at least one of a "timestamp," "packet_sequence_number," and "packet counter. " Further, the reset signaling information contains at least one of a "PA message" and an "MP table.

In an embodiment of the disclosure, the transmitting entity <NUM> may indicate which ones of the assets in one package, which the transmitting entity <NUM> transmits, are replaced by the third nodes and rendered by the user. In an embodiment of the disclosure, the information may be included in a particular signaling message to carry all the assets constituting the package or the MP table in the PA message, and the information is called an "asset_modification_flag", which is flag-type, one-bit information. The assets for which the asset_modification_flag has been set to '<NUM>' are permitted to be replaced by the MANE <NUM> or other third nodes, and the assets for which the asset_modification_flag has been set to '<NUM>' are not permitted to be replaced by the MANE <NUM> or the third nodes.

The syntax of the MP table in the PA message suggested according to an embodiment of the disclosure is shown in Tables <NUM> and <NUM> below. Tables <NUM> and <NUM> are shown on two sheets due to the limited sheet size although they are intended to be a single table.

The semantics of the MP table are as set forth in Table <NUM> above. However, in this disclosure, the "asset_modification_flag" set forth in Table <NUM> is newly suggested.

*asset_modification_flag: indicates whether the corresponding Asset can be replaced, modified, or changed by some <NUM>rd party entities at some entity such as MANE when rendered to MMT receiving entities. (asset_modification_flag - indicates whether the corresponding Asset can be replaced, modified, or changed by some <NUM>rd party entities at some entity such as MANE when rendered to MMT receiving entities.

Meanwhile, "AssetChangeRequest_message", which is newly suggested in the disclosure, is a message that the third entity <NUM>, e.g., a local broadcast station, transmits to the MANE <NUM>, requesting to modify/insert/replace/overlay at least one particular asset among the assets in one package that the transmitting entity <NUM>, e.g., a local broadcast station, transmits. Receiving the AssetChangeRequest_message, the MANE <NUM> updates the particular signaling message to carry all the assets constituting the package or the MP tables in all the PA messages containing the information about the particular asset based on the AssetChangeRequest_message. By so doing, rendering may be performed in such a manner that the MPU with a particular number or time indicated in the AssetChangeRequest_message transmitted from the third local broadcast station is modified/inserted/replaced/overlaid with other third media content, among such assets as broadcast programs that the broadcast station has transmitted.

The "AssetChangeRequest_message" is a message that the transmitting entity <NUM>, e.g., the broadcaster communicating with the third entity <NUM>, e.g., a local broadcast station, transmits to the MANE <NUM>, requesting to modify/insert/replace/overlay at least one particular asset among the assets in one package that the transmitting entity <NUM>, e.g., a local broadcast station, transmits. Receiving the AssetChangeRequest_message, the MANE <NUM> updates the particular signaling message to carry all the assets constituting the package or the MP tables in all the PA messages containing the information about the particular asset based on the AssetChangeRequest_message. By so doing, rendering may be performed in such a manner that the MPU with a particular number or time indicated in the AssetChangeRequest_message transmitted from the broadcast station is modified/inserted/replaced/overlaid with other third media content, among such assets as broadcast programs that the broadcast station has transmitted.

The syntax of the "AssetChangeRequest_message" is as shown in Table <NUM> below.

The semantics of the "AssetChangeRequest_message" is as shown in Table <NUM> below.

Referring to Table <NUM> above, the "AssetChangeRequest_message" may include at least one of the ID of the MMT packet to be replaced (Target_MMT_Package_ID), the ID of the MMT asset to be replaced (Target_asset_ID), the type of the replaced asset (Target_asset_type), information about the time when the media change occurs (Change_Time_Indicator), information about the duration of the media change (Duration), information as to, e.g., whether the type of media change is replace or overlay (Change_Type), information about whether the mode in which the media change occurs is time-based or MPU ID-based (Change_Indicate_Mode), information about the sequence number of the MPU in case it is MPU ID-based (MPU_sequence_number), and information about the position of the original one of the designated asset to be inserted/replaced (Designated_source_URL).

Receiving the AssetChangeRequest_message, the MANE <NUM> updates the particular signaling message to carry all the assets constituting the package or the MP table in the PA message related to the targeted asset and transmits an ACK message to the transmitting entity <NUM> or the third entity <NUM> which has transmitted the AssetChangeRequest_message. At this time, the operation of transmitting the ACK response message may be omitted depending on the MMT system. The particular signaling message to carry all the assets constituting the updated package or the updated PA message is transmitted to the receiving entity <NUM>.

Meanwhile, the MANE <NUM> updates the particular signaling message to carry all the assets constituting the package or the MP table in the PA message in the following order.

If the particular signaling message to carry all the assets constituting the package or the MP table in the PA message is updated and transmitted to the receiving entity <NUM>, and the modification/insertion/replacement/overlay for the target content is complete, the MANE <NUM> may restore the particular signaling message to carry all the assets constituting the package or the MP table in the original PA message before update and transmits the restored message to the receiving entity <NUM>, thus allowing the receiving entity <NUM> to receive the original content that the transmitting entity <NUM> has transmitted.

For reference, the MANE <NUM> receives the AssetChangeRequest_message, accordingly updates the MP table of the PA message, and transmits the same to the receiving entity <NUM>. Since the receiving entity <NUM> plays media according to the PA message, the operation of modifying/replacing the media, which the transmitting entity <NUM> provides, with the additional service, which the third entity <NUM> provides, may be performed not by the MANE but by the receiving entity.

The operation of modifying/replacing the media, which the transmitting entity <NUM> provides, with the additional service, which the third entity <NUM> provides, may be performed by the MANE.

<FIG> is a view illustrating a configuration of a MANE according to an embodiment of the disclosure.

A transceiver <NUM> transmits and receives media content and messages with an external entity. For example, in this disclosure, the transceiver <NUM> receives first media content and first media-related signaling messages. Further, the transceiver <NUM> receives a modification request message to modify particular media data of the first media content.

A controller <NUM> updates the signaling message related to the particular media data requested to be modified based on the modification request message. Further, the controller <NUM> may update the particular media data of the first media content, which is requested to be modified, based on the modification request message. The updated signaling message and media content are transmitted to the receiving entity <NUM> via the transceiver <NUM>.

<FIG> is a view illustrating operations of a receiving entity according to an embodiment of the disclosure.

The receiving entity receives a signaling message related to first media content in step <NUM> and renders the first media content based on the signaling information in step <NUM>.

The receiving entity receives the updated signaling message from the MANE to provide second media content in step <NUM> and renders the second media content using the updated signaling message in step <NUM>.

For reference, when the MANE updates not only the signaling message, but also the first media content, into the second media content, the signaling message and second media content updated in the MANE are received in step <NUM>, and the second media content is rendered using the updated signaling message in step <NUM>.

<FIG> is a view illustrating a configuration of a receiving entity according to an embodiment of the disclosure.

A transceiver <NUM> transmits and receives messages with an external entity. For example, the transceiver <NUM> receives a signaling message related to first media content and receives an updated signaling message from the MANE to provide second media content. As another example, to provide the second media content, the transceiver <NUM> receives the second media content and the signaling message updated in the MANE.

A controller <NUM> controls operations of the receiving entity. A rendering unit <NUM> renders the first media content based on the signaling message and the second media content using the updated signaling message.

Embodiments of the disclosure have been described above. The second content may be efficiently provided while the first content is provided to the receiving entity using the newly proposed "AssetChangeRequest_message" and the "asset_modification_flag" contained in the MP table of the PA message or the newly proposed MMT signaling message according to the disclosure.

Particular aspects of the disclosure may be implemented as computer readable codes in a computer readable recording medium. The computer readable recording medium is a data storage device that may store data readable by a computer system. Examples of the computer readable recording medium may include read only memories (ROMs), random access memories (RAMs), CD-ROMs, magnetic tapes, floppy disks, optical data storage devices, and carrier waves (such as data transmission over the Internet). The computer readable recording medium may be distributed by computer systems over a network, and accordingly, the computer readable codes may be stored and executed in a distributed manner. Functional programs, codes, and code segments to attain the disclosure may be readily interpreted by skilled programmers in the art to which the disclosure pertains.

The apparatuses and methods according to embodiments of the disclosure may be implemented in hardware, software, or a combination of hardware and software. Such software may be stored in a volatile or non-volatile storage device such as a read-only memory (ROM) or other storage devices, a memory, such as a random access memory (RAM), a memory chip, a device or an integrated circuit, or a storage medium, such as, e.g., a compact disc (CD), a digital video disc (DVD), a magnetic disk, or a magnetic tape, which allows for optical or magnetic recording while simultaneously read out by a machine (e.g., a computer). The methods according to embodiments of the disclosure may be implemented by a computer or a portable terminal including a controller and a memory, and the memory may be an exemplary machine-readable storage medium that may properly retain program(s) containing instructions for implementing the embodiments of the disclosure.

Accordingly, the present disclosure encompasses a program containing codes for implementing the device or method set forth in the claims of this disclosure and a machine (e.g., computer)-readable storage medium storing the program. The program may be electronically transferred via any media such as communication signals transmitted through a wired or wireless connection and the present disclosure properly includes the equivalents thereof.

The apparatuses according to embodiments of the disclosure may receive the program from a program providing device wiredly or wirelessly connected thereto and store the same. The program providing apparatus may include a memory for storing a program including instructions enabling a program processing apparatus to perform a preset content protection method and information necessary for the content protection method, a communication unit for performing wired or wireless communications with a graphic processing apparatus, and a controller transmitting the program to the transmitting/receiving device automatically or as requested by the graphic processing apparatus.

In conventional broadcast systems, service lists, e.g., electronic service guides (ESGs), are directly created by a particular broadcaster (e.g., KBS or MBC) and sent alongside content, or are produced and distributed to users by paid retransmission providers, such as multichannel video programming distributors (MVPDs) (e.g., SK broadband or Olleh KT) who receive content from the broadcaster and redistribute the content. In other words, users only receive ESGs that are created and distributed by a particular retransmission provider or terrestrial broadcasters to which they subscribe, and choose their desired broadcast programs or obtain information about future programs based on the received ESGs.

Recently, broadcast contents have been often provided in the form of IP-based Internet streams. If this trend continues and all broadcast contents are created as IP-based with the advent of, e.g., an all-IP era, then broadcast channels are expected to increase in number nearly indefinitely, unlike in the traditional method whereby broadcasting occurs with a fixed number of broadcast channels. This leads to the need for a scheme which can efficiently provide ESGs that various providers create.

With the explosive growth of wired/wireless Internet markets, we will see a diversity of Internet television platforms become a meaningful part of our lives. Among others, mobile data traffic will drastically increase. <NUM>% of mobile data traffic is expected to stem from smartphones, with about <NUM>% of all mobile data traffic around the year <NUM> being mobile video traffic.

Indeed, the South Korea-Russia World Cup match on June <NUM>, <NUM> is a good example of how powerful mobile broadcasting works. As the game was held during the morning rush hour of the day and a tremendous number of viewers flooded into high-definition live services that Naver and Daum provided, mobile data traffic soared as well. Thus, viewing on smartphones couldn't be seamless.

Increasing demand for live broadcast on mobile terminals has led mobile communication carriers to need to efficiently manage mobile traffic while developing relevant additional services.

Upon generating media content, conventional hypertext transfer protocol (HTTP)-based streaming schemes produce media resource distinction information along with metadata. In such cases, upon converting into HTTP-based files to stream out, e.g., <NUM> minute-long media content over the Internet, information about the content server which is able to receive the media content is stored in the metadata in the form of, e.g., a uniform resource locator (URL), and the same is transmitted together on the receiver part.

The receiver receives the metadata and sends a request for the user's desired streaming service to the HTTP-based media content server through the media resource information (e.g., URL) stored in the metadata.

In the contents delivery network (CDN) environment, when one multimedia receiver and one multimedia transmitter initiate a session through one network and server and provide multimedia service depending on the network condition of the service provider, such a case may occur in which it is required to change the transmission server or session to continue the multimedia service, depending on the requirements of the receiver or transmitter.

Conventional streaming-based HTTP schemes, upon generating media content, produce media resource information along with metadata. Such schemes bring about various issues in the environment to use dynamic media resource distinction information in the actual real-time streaming environment.

First, media resource information, which conventional HTTP schemes adopted, e.g., URL information, do not take advantage of the actual address, e.g., Internet protocol (IP) address, of the media content server and, to access the server, they are thus required to find the actual address by requesting, e.g., the domain name server (DNS), thus causing a delay.

Further, the address of the server is created along with the content during a predetermined file period, making it impossible to update, in realtime, the media resource information due to the dynamic channel change--this renders it difficult to make dynamic channel and media content sever modifications in one program while using the streaming service in practice.

Lastly, when the address of the media content server is modified while in the conventional HTTP-based streaming service, the service currently being used cannot last, and serving on the media content server requires re-reception of the address of the media content server via the initial access process.

Since the conventional CDN-adopting multimedia service environment also produces a media resource together with metadata upon creating media content, the conventional CDN environment had difficulty in dynamic media resource allocation that varies the transmission server and session depending on the requirements of the receiver or transmitter in the realtime streaming environment.

Meanwhile, the above-described information is provided only as background information for a better understanding of the disclosure. No determinations and claims are made as to whether what has been described in this section may be applicable as the prior art related to the disclosure.

According to an embodiment of the disclosure, there is provided a method and device for providing user-centered, integrated broadcast service information in a broadcast system.

According to an embodiment of the disclosure, there is provided a method and device for providing location information of a broadcast service to provide broadcast service information in a broadcast system.

According to an embodiment of the disclosure, there is provided information that is contained in a program constituting channels depending on the type of broadcast channels in a broadcast system.

According to an embodiment of the disclosure, there is proposed a device and method for transmitting/receiving content-related information in a multimedia system.

According to an embodiment of the disclosure, there is proposed a device and method for managing media resources based on service circumstances in a multimedia system.

According to an embodiment of the disclosure, there is proposed a device and method for efficiently managing media resources by providing media content signaling information and media content resource information depending on service circumstances (e.g., the number of users) when providing a media content service, actually and in realtime, by providing dynamic media resource distinction information appropriate for, e.g., the number of service users, user environment, or location, in an existing static media resource allocation environment using a MPEG media transport (MMT)-based media content streaming service.

<FIG> is a view illustrating the concept of providing broadcast service information according to an embodiment of the disclosure.

According to the disclosure, broadcast service information is provided to users in the form of a single piece of integrated broadcast service information using a plurality of pieces of broadcast service information. Referring to <FIG>, broadcast service information pieces <NUM>, <NUM>, and <NUM> created by different operators may be integrated into a standardized service list descriptor <NUM> by an MMT entity <NUM> and may then be transferred to a service provider via a lower layer. This may prevent the broadcast service information from depending upon a particular broadcaster. Further, terminals, albeit unable to directly receive broadcast service information through broadcast channels, may provide their users with desired broadcast service information. Hereinafter, embodiments of the disclosure are described.

Hereinafter, the terms "(MMT) service descriptor," "(MMT) service list descriptor," and "descriptor" may be interchangeably used as having the same meaning.

<FIG> is a view illustrating an MMT service descriptor data model according to an embodiment of the disclosure.

Referring to <FIG>, one MMT service descriptor <NUM> includes a plurality of MMT channels <NUM>, <NUM>, <NUM>,. , and one MMT channel includes a plurality of MMT packages <NUM>, <NUM>, <NUM>, <NUM>,. One package corresponds to one content program (e.g., a TV show, news, or baseball game). One MMT channel corresponds to an aggregation of a plurality of broadcast content programs (e.g., MBC, SBS, Netflix, or Hulu).

One MMT service descriptor may be provided by a particular broadcaster. Or, the particular broadcaster may provide a plurality of MMT service descriptors. An MMT receiving entity may obtain location information (e.g., a URL) about the descriptor determined by the provider and may obtain the MMT service list descriptor from the URL. The URL may exist in the MMT transmitting entity and be provided from the MMT transmitting entity to the MMT receiving entity, or the URL may exist in a separate server to provide the MMT service list descriptor and be provided to the MMT receiving entity.

At this time, the MMT channel may be a linear broadcast channel or a nonlinear broadcast channel. The linear broadcast channel refers to a channel consisting programs already scheduled for broadcast. For the linear broadcast channel, one package adds time property information of the particular time when the package broadcasts. For example, the package may include the property information of the start time (StartTime) and end time (EndTime) of the broadcast of the package.

The MMT receiving entity may obtain MMT service list descriptors including lists of MMT services from a plurality of sources (descriptor URLs) and, when the obtained MMT service list descriptors are merged and provided to the user, the information provided to the user may play the role of a sort of ESG.

That is, the MMT service list descriptor serves to provide information about the MMT service that a certain service provide provides in the form of an MMT protocol. One MMT service list descriptor consists of a plurality of MMT channels, which are logical units each formed of an aggregation of a plurality of MMT packages. MMT package corresponds to a particular program, such as news, a sports game, or a movie, and one MMT package has its unique ID property value called an MMT package indentifier (MMT_Package_id) to differentiate from other MMT packages. When a particular MMT package is chosen, the MMTP session may be provided through a separate SDP file (SDP URI element provides location information), an "in-lined SDP" (the CDATA field in the Descriptor XML document provides information) embedded in the descriptor, an MMT PA message, and an MMT PA table (MMT_PA_URL element provides information). When some channel is constituted of linear contents, each MMT package has its unique property property value, such as startTime and endTime.

The MMT service descriptor schema is described below.

An MMT service consists of package units, and one package includes a plurality of assets. One broadcast channel may be formed of an aggregation of a plurality of packages, and a list of the packages may be provided to the user as service list (i.e., a sort of EPG) information.

Tables <NUM> and <NUM> below present an example of the MMT service descriptor schema. Tables <NUM> and <NUM> are shown on two sheets due to the limited paper size although they are intended to be a single table.

The components of the MMT service descriptor schema are described in Table <NUM> below.

In the MMT service descriptor schema, "descnptorURL" is the address where the MMT service descriptor is located. The MMT receiving entity may obtain a plurality of URLs and store them therein. For example, the user may figure out the URLs of the descriptor through a certain route and store the URL information of their preferred service provider. Or, the URLs of the descriptor may be provided as information about a separate means capable of providing service list information within the service list, e.g., EPG, which is transferred via a separate broadcast physical channel. The MMT receiving entity sends a request for the descriptor at the addresses of the URLs of the descriptor to obtain the MMT service descriptor. Upon receiving descriptors as requested by the MMT receiving entity, corresponding to the request, the MMT receiving entity merges the plurality of descriptors received and provides them to the user.

Meanwhile, channelType provides type information about the channel, which provides the type information of the physical transmission channel necessary to consume the service (MMT package) described in the current channel. Upon merging the descriptors, the MMT receiving entity may consider the channel type based on whether the physical channels are available. If only broadband channels are available, then the MMT receiving entity merges only channels whose channelType is <NUM> and provides the merged channels.

Now described is the structure of the MMT receiving entity according to an embodiment of the disclosure.

<FIG> is a view illustrating a structure of an MMT receiving entity according to an embodiment of the disclosure.

<FIG> assumes the situation in which an MMT service descriptor-storing server (e.g., an MMT transmitting entity or a separate server) transmits a plurality of MMT service descriptors <NUM>, <NUM>, and <NUM> to an MMT receiving entity <NUM>, and the MMT receiving entity <NUM> processes the received MMT service descriptors <NUM>, <NUM>, and <NUM>. The components of the MMT receiving entity <NUM> are described below.

The MMT receiving entity <NUM> includes an MMT session initiator <NUM>, a descriptor URL register <NUM>, a descriptor extractor <NUM>, an MMT descriptor merger <NUM>, a broadcast ESG manager <NUM>, user preference storage <NUM>, a descriptor acquisition manager <NUM>, and an MMT service list presentation engine <NUM>.

The MMT session initiator <NUM> extracts MMT session information of a particular program (i.e., package) chosen by the user from the service list shown to the user through the MMT service list presentation engine <NUM> and processes the MMT session to be able to receive, from the MMT transmitting entity, and process the MMT package using the extracted MMT session information.

The descriptor URL register <NUM> stores URL information (i.e., DescriptorURL) about where the MMT service list descriptor is located.

The MMT service list descriptor information may be provided in the following scheme.

The MMT receiving entity <NUM> may obtain the descriptor information from the user's desired MMT service list descriptor information provider and previously store it in the descriptor URL register <NUM>.

The MMT service list descriptor may be directly stored in a separate application installed by the user and provided. The MMT service list descriptor may also be transmitted to the MMT receiving entity from a server over the Internet.

Further, the MMT service list descriptor may also be provided through additional URL (Alternative URL) information normally received from the broadcast channel through the broadcast ESG manager <NUM>. For reference, the broadcaster or service provider may routinely provide the additional URL information through the broadcast channel in preparation for when the broadcast service itself is unavailable, e.g., the situation in which the MMT receiving entity cannot extract the ESG due to, e.g., a failure in the reception on the broadcast channel.

The descriptor extractor <NUM> receives a plurality of descriptors from an MMT service descriptor storage server <NUM> over the Internet using the MMT service list descriptor URL information (DescriptorURL) transferred from the descriptor URL register <NUM>. The descriptors may be received via various transport protocols, e.g., HTTP as an example according to the disclosure.

Which one of the plurality of descriptors is to be received may be determined by a preset user preference, and the plurality of descriptors received are delivered to the MMT descriptor merger <NUM>.

The MMT descriptor merger <NUM> merges a plurality of MMT service list descriptors received from the plurality of MMT service descriptor servers. Meanwhile, which descriptor (e.g., KBS or MBC) is to be received, and from where (e.g., KBS or a third party provider), may be determined by the user and stored in the user preference storage <NUM>, and the MMT service list descriptors may be merged based on the preference information into a unitary merged MMT service list descriptor that may then be provided to the user.

The broadcast ESG manager <NUM> extracts the service list information (ESG) that such a typical broadcast system, such as an advanced television systems committee (ATSC) <NUM> or digital video broadcasting (DVB), provides in a separate scheme through the lower layer, i.e., broadcast physical/transport (PHY/MAC) layer. When the terminal falls within the broadcast channel coverage for some reason, and thus there is a problem with broadcast reception, the status information (e.g., broadcast ESG cannot be provided) of the broadcast channel is provided instead of the ESG information, allowing the descriptor acquisition manager <NUM> to determine which route of ESG (or service descriptor) should be shown to the user.

The user preference storage <NUM> contains the user's preferred MMT service descriptor, channel, package, or such information. The above pieces of information may be used to determine which descriptor should be provided to the user.

The descriptor acquisition manager <NUM> determines what route is to be used when the MMT receiving entity provides the user with the service list information. The route for providing the service list that is provided may be determined based on the information delivered from the broadcast ESG manager <NUM> or the user preference storage <NUM>. For example, broadcast systems such as ATSC <NUM> or DVB extract service list information (ESG) from the lower broadcast physical/transport (PHY/MAC) layer. However, broadcast reception-incapable terminals, e.g., mobile terminals, cannot even start a broadcast service because they lack a method for receiving ESG. In this case, the descriptor acquisition manager <NUM> provides the user with the MMT service list information delivered from the MMT descriptor merger <NUM>, allowing a broadcast service to commence for the user.

The MMT service list presentation engine <NUM> renders the service list information obtained through the descriptor for the user, allowing the user to choose and determine his desired particular program (i.e., MMT package).

For reference, the session information of the particular program (i.e., MMT package) chosen by the user may be in the form of one of a MMT package access (PA) table, an MMT PA message, an inlined session description protocol (SDP), and a separate SDP file, and the session information is transferred to the MMT session initiator <NUM>. The session information is information necessary to start a session to be able to receive desired content via the MMT.

For reference, the MMT PA table is a table containing all pertinent signaling information necessary to consume the MMT package and includes pieces of information that should first be processed in order to obtain the package and show the obtained package to the user. The syntax and semantics information of the MMT PA are as defined in the MMT specifications below. Meanwhile, the MMT PA table may also be transferred in the form of a separate signaling message (PA signaling message).

Table <NUM> below represents the syntax of the PA table.

The semantics of the elements in Table <NUM> above is the same as that shown in Table <NUM> below.

Now described are operations of the MMT receiving entity according to an embodiment of the disclosure.

<FIG> is a view illustrating operations of an MMT receiving entity according to an embodiment of the disclosure.

In step <NUM>, the MMT receiving entity obtains URLs of one or more MMT service descriptors and stores them therein. In step <NUM>, the MMT receiving entity obtains and stores user preference descriptor information. In step <NUM>, the MMT receiving entity receives MMT service descriptors using the obtained descriptor URLs. In step <NUM>, the MMT receiving entity determines whether an ESG is receivable through a broadcast channel, and if receivable, goes to step <NUM> to receive an ESG through the broadcast channel, and then goes to step <NUM>. Unless an ESG is receivable through the broadcast channel, the MMT receiving entity immediately goes to step <NUM>.

In step <NUM>, the MMT receiving entity determines the type of the receiving channels and, in step <NUM>, classifies them into particular channel types depending on whether the terminal's physical channels are available. In step <NUM>, the MMT receiving entity aggregates the descriptors for each of the same type of channels into an aggregate descriptor and, in step <NUM>, displays the aggregate descriptor to the user. In step <NUM>, when the user chooses a particular program (package) in the descriptor, the MMT receiving entity initiates an MMT session to receive the chosen package in step <NUM> and controls the initiated session, and the MMT receiving entity receives, through the MMTP, the package chosen through the session in step <NUM>.

Now described are operations of an MMT transmitting entity according to an embodiment of the disclosure.

<FIG> is a view illustrating operations of an MMT transmitting entity according to an embodiment of the disclosure.

In step <NUM>, the MMT transmitting entity lists the MMT packages constituting a particular channel.

In step <NUM>, the MMT transmitting entity determines whether the channel is intended for linear broadcasting. If the channel is intended for linear broadcasting, the MMT transmitting entity goes to step <NUM>, putting time property information (StartTime and EndTime) of the particular time when the package is broadcast in the package constituting the channel, then to step <NUM>. If the channel is intended for non-linear broadcasting, the MMT transmitting entity immediately goes to step <NUM>. In step <NUM>, the MMT transmitting entity stores the MMT service descriptor and, in step <NUM>, transmits the MMT service descriptor. Then, the MMT transmitting entity proceeds to step <NUM>, updating the MMT service descriptor as necessary. Embodiments of the disclosure have been described above. In conventional broadcast systems (e.g., ATSC <NUM>), broadcast reception-incapable terminals cannot receive any ESG, and are thus unable to even start a broadcast service.

However, broadcast-telecommunications-integrated hybrid broadcast systems (e.g., ATSC3. <NUM> or DVB), which have been recently rising, should serve mobile terminals or other various devices unlike conventional TV-centered broadcast systems. In such a hybrid broadcast service for serving mobile terminals, terminals may be located out of broadcast coverage, in which case the terminals may not be able to extract the ESG. This may lead to the situation in which the broadcast service is impossible to receive despite broadband channels being available. Embodiments of the disclosure may provide users with a user-centered integrated ESG in broadcast-telecommunications integrated hybrid broadcast systems.

According to an embodiment of the disclosure, there is proposed a device and method for efficiently managing media resources by providing media content signaling information and media content resource information depending on service circumstances (e.g., the number of users) when providing a media content service, actually and in realtime, by providing dynamic media resource distinction information appropriate for, e.g., the number of service users, user environment, or location, in an existing static media resource allocation environment using a MPEG media transport (MMT)-based media content streaming service. As proposed to conventional over-the-top (OTT) service providers or communication carriers to reduce network traffic, content delivery network (CDN) servers or content servers may be installed in their networks. Conventional mobile broadcasting, which has a central server accessed by users, places separate edge servers for receiving necessary data near the origin server in order to prevent data transmission from slowing down due to increasing use of mobile data and the resulting simultaneous access to the server by many people. At this time, managing mobile data traffic load, e.g., per-edge server overload or access delay, is significant.

The disclosure relates to transmitting composite multimedia data over a hybrid network including a broadcast network, telecommunication network, and other networks and proposes a device and method for transmitting composite multimedia data by adopting an MPEG media transport (MMT) scheme.

Meanwhile, devices and methods proposed according to an embodiment of the disclosure are applicable to digital multimedia broadcasting (DMB) services, digital video broadcasting-handheld (DVP-H), advanced television systems committee-mobile/handheld (ATSC-M/H) service or other mobile broadcast services, internet protocol television (IPTV) services or other digital video broadcast systems, moving picture experts group (MPEG) media transport (MMT) systems, evolved packet system (EPS), long-term evolution (LTE) mobile communication systems, LTE-advanced (LTE-A) mobile communication systems, high speed downlink packet access (HSDPA) mobile communication systems, high speed uplink packet access (HSUPA) mobile communication systems, <NUM>rd generation partnership project <NUM> (3GPP2) high rate packet data (HRPD) mobile communication systems, 3GPP2 wideband code division multiple access (WCDMA) mobile communication systems, 3GPP2 code division multiple access (CDMA) mobile communication systems, institute of electrical and electronics engineers (IEEE) <NUM> communication systems or other communication systems, mobile internet protocol (Mobile IP) systems or other various communication systems.

First, in an MMT-based media content streaming service, MMC media content-related content signaling information, which the content provider provides, e.g., MMC media content-related media content signaling information, such as MMT_general_location_info, or media resource allocation information, which the service provider provides, e.g., valid time, transmission access type, or other media resource allocation information, are merged to provide a media content streaming service based on dynamic media resource distinction information upon using the media content service.

To use service in the conventional CDN environment, the user device first accesses the server of the provider that provides a user's desired media service to fetch the address of the CDN server providing the media service. The user device accesses the managing server (e.g., CDN Fram) managing CDN information based on the received CDN server address, receiving the media service server address fitting the reception environment of the service user (e.g., the service user's location). The service user may be able to use the media service based on the media service server address received from the CDN managing server. As such, CDN is technology enabling quick and stable transmission of massive content online, which may distribute content to the CDN servers of major ISPs and allows the user to receive content from the closest server on the network routes, thereby preventing traffic from concentrating on a particular server and distributing traffic to local servers.

According to an embodiment of the disclosure, in the CDN environment, MMT media content-related media content signaling information and media resource allocation information are given to the user, e.g., the user device, the network status and circumstance are grasped, and various pieces of information for access are provided to the user, thus contributing to efficiently providing media service.

At this time, according to an embodiment of the disclosure, the process of communicating with the service provider's server to receive CDN server information and communicating with the CDN managing server to obtain the media server's address is instead performed by a DRI server in order to figure out the server address of the user's desired media service. Here, 'DRI server' means a server that receives, in realtime, the media service from the service provider, sends a request for corresponding information to the CDN managing server, stores the actual server address of each media service in the form of a reception message, and provides the media content resource allocation information to the user through a DRI message. Further, the DRI server figures out the address of the server providing media content signaling information of the media and provides the media content signaling information to the user via a DSI message.

Tables <NUM> and <NUM> represent basic configurations of the DRI message and DSI message.

For example, upon accessing the service, the service user receives the DRI message and DSI message that the content and service provider provides and then identifies the message version, thus determining whether to update with respect to the existing message. At this time, 'DRI message' means media resource allocation information that the DRI server receives while communicating with the CDN server and service user server, and 'DSI message' means the signaling information of the media content. Thereafter, the service user receives media content signaling information using the MMC media content-related media content signaling information, i.e., DSI message, which has been received through the content and service provider. Further, the user receives, through the DRI message, the media resource allocation information which the content and service provider provides and sends a request for media content to, and receives the media content from, the media content server.

At this time, upon providing media content resource allocation information and media content signaling information, the content and service provider puts priority on media content signaling servers and media content resource servers, which the user may access based on or considering, e.g., the user's information or network context, and transfers the information to the user through the DRI message and DSI message.

<FIG> shows an example of operations of the receiver after the user receives the DRI message. The user may receive media content from a primary_media_location through the message. When the media content server lacks the requested media content when the request for the information is sent to the primary_media_location or the server does not operate, a request for the media content may be sent to an Alternative_media _location and the media content may be received therefrom. If neither the primary_media_location server nor the Altemative_media_location server operates or the media content is not there, it sends a request for the desired media content to the server based on server information provided from an origin_media_location and receives the media content. Here, the priority of the media content resource allocation information provided through the DRI message is provided by the DRI server through, e.g., the service user's location and network status information. Here, the priority of media content resource allocation information means resource allocation information to designate the server, which may provide the most optimal service to the service user, as the primary_location server and designates the next best server providing the media service as the Altemative_location or origin_location server based on the information of the content and service provider's server, allowing the service user to take advantage of the same.

Also upon receiving the media content signaling information, the service user receives media content signaling information based on the DSI message received through the DRI server. <FIG> illustrates an example of the operation of the receiver to receive media signaling information after the user receives the DSI message.

The user sends a request for the media content signaling information to the media server based on the DSI message received from the DRI server. At this time, the request of the information is made based on the pre-designated priorities in the DSI message. It accesses the media server address of the content and service provider first provided to the primry_signaling_location and requests media content signaling. If the primary_signaling_location fails to receive the information or is providing media content signaling information older in version than the existing media content signaling information, a request is sent through the alternative_signaling_location, and upon failing to receive the signaling information even through the alternative_signaling_location, it may receive the medai content signaling information through the server address being provided from the origin_signaling_location. At this time, the primary_signaling_location, the alternative_signaling_location, and the origin_signaling_location provide the media content signaling information, subjected to the access priorities, using, e.g., the service user's location and content information based on the information that the DRI server has received through the content and service provider's server.

Table <NUM> above represents the DRI message according to an embodiment of the disclosure.

As set forth in Table <NUM> above, the parameters contained in the DRI message as proposed according to an embodiment of the disclosure mean as follows.

message_id - indicates DRI message ID. The length of this field is <NUM> bits.

version - indicates the version of MRI messages. MMT receiving entity may check whether the received message is new or not. The length of this field is <NUM> bits.

length - indicates the length of MRI messages. The length of this field is <NUM> bits. It indicates the length of the MRI message counted in bytes starting from the next field to the last byte of the MRI message. The value '<NUM>' shall not be used.

valid_time_start - indicates a UTC time in NTP format corresponding to transmission session valid start time. This field is the <NUM> bits MSB from the full resolution NTP timestamp.

valid_time_duration - indicates a UTC time in NTP format corresponding to transmission session valid stop time. This field is the <NUM> bits MSB from the full resolution NTP timestamp.

number_of_assets - provides the number of Assets whose information is provided by MP table.

location_count - provides the number of location information for an Asset. Set to '<NUM>' when an Asset is delivered through one location. When bulk delivery is achieved, in which MPUs contained in an Asset are delivered through multi-channels, not '<NUM>' is set. When one Asset is delivered over multiple.

asset_id - indicates the asset_id as defined in <NUM>. of another Asset on which the dependent Asset associated with this descriptor depends. The order of the id-s provided in this descriptor is such that the concatenation of MPUs as defined in section <NUM>. <NUM> leads to a valid MPU and follows the media dependency hierarchy.

update_asset_primary_location - provides the location of the primary address from which an MMT receiving entity can get the Asset.

number_of_alternative - provides the number of alternative address.

update_asset_Alternative_location - provides the location of an alternative address from which an MMT receiving entity can get the Asset.

update_asset_origin_location - provides the location of the origin address from which an MMT receiving entity can get the Asset.

MMT_general_location_info_ - provides the location information of Asset. General location reference information for Asset defined in <NUM>. <NUM> is used. Only the value of location_type between '0x00' and '0x06' shall be used for an Asset location.

Transmission_access_type - indicates type of transmission access channel of media content delivery as shown in Table AMD1.

Table <NUM> above represents the DSI message according to an embodiment of the disclosure.

As set forth in Table <NUM> above, the parameters contained in the DSI message as proposed according to an embodiment of the disclosure mean as follows.

Alternative_signaling_location - provides the location of an alternative address from which an MMT receiving entity can get the signaling information. number of alternative - provides the number of alternative address.

Origin_signaling_location - provides the location of an alternative address from which an MMT receiving entity can get the signaling information.

Specific processes curtain control device are described below.

First, a specific process in which the media content server lacks desired information is described below.

When the service user accesses the service and uses the media service, the service user sends a request for media content resource allocation information and media content signaling information to the DRI server. The DRI server receives, in realtime, the media service information from the service provider, sends a request for the information to the CDN managing server, receives each actual piece of media service resource allocation information and the media content signaling providing server address, stores them in the form of messages, and provides the user with the media content resource allocation information through the DRI message and DSI message. By way of the DRI message and DSI media content signaling information, the service user receives the media content resource and media content signaling and uses the service.

As illustrated in <FIG>, the service user sends a request for service to the media server using the media content resource allocation information. At this time, each piece of media content resource allocation information and media content signaling information are determined for priority of access depending on the service provider's server and network context. The DRI server transmits, to the user through the DRI message, the media content resource allocation information to receive the media content resource. The media content resource allocation information in the DRI message has the following priority. The server closest to the user within the CDN network may be assigned as the primary_media_location media server, and the next best server may be designated as the alternative_media_location, the content provider's server, i.e.,. the origin _media_location capable of providing the media content in any circumstances. The service user first sends a request for the media content resource to the primary_media_location for requesting the media resource in the DRI message.

Upon failing to receive the media content from the primary_media_location, the user accesses the content provided from the alternative_media_location or the media content server of the media service provider to request the media service. Upon failing to receive the information from the primary_media_location and the alternative_media_location media servers, the user receives the media content from the corresponding server using the address of the origin_media_location. When the alternative_media_location provides the media content of a different form (resolution or codec) from that of the content, although it is the prior media service that the media service user is receiving from the primary_media_location, the user may send a request for the media content to the origin_media_location and use the service.

To use the media service, the service user needs to receive not only the media content resource but also media content signaling information. The media content signaling information may be transferred to the service user through the DSI message. The media content signaling information is requested based on the priority that the content or service user has preset depending on the service provider's server and network context and the user's context for the information in the DSI.

To use the media service, the service user sends a request for media content signaling information to the content and service provider's server based on the primary_signaling _location information in the DSI message and receives the signaling information of the media content. Upon failing to receive the signaling information from the primary_signaling _location or if the received information is not the latest information or is a different version from the previously received media content signaling information, the service user again sends a request for media content signaling information to the alternative_signaling_location and receives the same from the altemative_signaling_location. Upon failing to receive the media content signaling information despite the above two requests, the user sends a request for the media content signaling information to the origin_signaling_location and receives the same from the origin_signaling_location. Here, the origin_signaling_location means the server of the service provider or content provider. This server is a media server that should provide the media content resource and media content signaling information if it is providing a media content server.

Second, an operation process is described below in the case in which a media content service is provided over different heterogeneous networks.

Upon using a media content service from the content and service provider, media content may be received through the different heterogeneous networks depending on the network context and the service user's environment. In this case, the media service may be provided through the different heterogeneous networks using the media content signaling information and media content resource allocation information in the DSI and DRI messages provided from the DRI server.

For example, when the primary receiving server information in the DSI and DRI messages is set to the service provider's server, and the alternative server's information is set to the content provider's server, the content provider server may be located inside or out the service provider's network.

When the first media service user accesses the service in area <NUM> of <FIG>, the user receives the DRI and DSI messages for his desired media content server information and uses the media service based on the media content resource allocation information and media content signaling information. In this case, the user accesses the server of the service provider assigned to the primary_media_location and primary_signaling_location to receive media content, using the service. However, when the service provider's server cannot provide service while the service is in use, the user may request that the server allow the user to seamlessly use the media content service using the server of the content provider assigned to the alternative_media_location and alternative_signaling_location and the transmission channel defined in the transmission_access_type.

Further, the media content signaling information, which is transmitted only through Wifi or broadcast network, i.e., heterogeneous networks, may be provided through the alternative_signaling_location or origin_signaling_location, thereby offering additional information to enable access to a third service provider's media content signaling server and hence allowing for the reception of the service which used to be provided over the heterogeneous network.

For example, the service user in area <NUM> of <FIG>, who is using a communication carrier's service in the LTE environment, may send a request for information to, and receive the information from, the alternative_signaling_location or origin_signaling_location, which possesses broadcast channel signaling information, to use a broadcast channel being provided on other channel, receiving broadcast channel information which is being provided in the broadcast environment and using the broadcast service using the resource allocation information.

A specific operation process wherein media content service information is modified in the middle of service is described below.

First, when the service user accesses the service and uses the media service, the service user sends a request for media content resource allocation information and media content signaling information to the DRI server. The service user receives the media content resource and media content server using the DRI message and the DSI message. When the service provider modifies the media content resource allocation server and media content signaling information depending on the network context and service user's environment while corresponding information is requested based on the media content resource allocation information and media content signaling access priority and the service is in use, existing service users may not continue to use the service due to a discrepancy between the media content signaling information and the media content resource information received from the new server.

For example, the content and service provider may determine temporarily modifying the service user's service, e.g., modifying the resolution, when too many users come into the service or due to a temporary network performance shutdown around the user. When something in the communication environment goes wrong, e.g., due to poor Wifi or temporary traffic congestion, the content and service provider may temporarily downgrade the LTE service quality from FHD to HD in order to carry on the seamless service. In such a case, the media content resource may be received from the alternative _media__location which the content and service provider provides. The user sends a request for media content signaling information fitting the media content and updated by the alternative_signaling_location or origin signaling _location according to the given access priority in the DSI message and is seamlessly served based on the information.

Further, as an example, in the CDN environment, the media servers located near a crowded area are designated as the primary_media_location and primary_signaling_location according to the number of media service users, thereby providing seamless service to the users in the hot spot area. When the nearby media servers cannot continue to provide the media service due to a diminishing number of service users or in the service provider's context, media server information of the nearby media servers is provided through the alternative_media _location, alternative_signaling_location or origin _media_location or origin_signaling_location, thereby providing the media content resource and media content signaling information of the media service.

According to an embodiment of the disclosure, the content and service provider may dynamically allocate media resources depending on the network context and service user's environment, thus allowing for efficient network management and seamless streaming upon providing media content in realtime or non-realtime.

According to an embodiment of the disclosure, the service provider allows for efficient realtime streaming and use of a media content service between heterogeneous networks by assigning priorities to servers for receiving media content signaling information.

Meanwhile, although not shown separately, the transmitting device, receiving device, origin server, alternative server, primary server, DRI/DSI server, client, or other entities in the multimedia system according to an embodiment of the disclosure may each include a transmitter, a controller, a receiver, and a storage unit.

The controller controls the overal operation of any one of the entities, e.g., the transmitting device, receiving device, origin server, alternative server, primary server, DRI/DSI server, and client. In particular, the controller controls the entity to perform operations related to transmitting/receiving content-related information in the multimedia system according to an embodiment of the disclosure. Here, the operations related to transmitting/receiving content-related information in the multimedia system, as performed by the entity, according to an embodiment of the disclosure, are the same as those described above in connection with <FIG>, and no detailed description thereof is given herein.

The transmitter transmits various signals and messages to at least one other entity under the control of the controller. Here, various signals and messages transmitted by the transmitter are the same as those described above in connection with <FIG>, and no detailed description thereof is repeated.

The receiver receives various signals and messages from at least one other entity under the control of the controller. Here, various signals and messages received by the receiver are the same as those described above in connection with <FIG>, and no detailed description thereof is repeated.

Further, the storage unit stores various data and various programs to perform operations related to transmitting/receiving content-related information in the multimedia system, according to an embodiment of the disclosure, as performed by the entity, as described above in connection with <FIG> and stores data that is created upon performing operations related to transmitting/receiving content-related information in the multimedia system, according to an embodiment of the disclosure, as performed by the entity, as described above in connection with <FIG>.

Meanwhile, although the entity has been described above to be implemented with separate units, e.g., the transmitter, controller, receiver, and storage unit, the entity may also be implemented with a combination of at least two of the transmitter, controller, receiver, and storage unit.

Although the entity has been described above to be implemented with separate units, e.g., the transmitter, controller, receiver, and storage unit, the entity may also be implemented as a single processor.

According to an embodiment of the disclosure, content-related information can be transmitted/received in a multimedia system. According to an embodiment of the disclosure, a multimedia system can manage media resources based on service contexts.

Claim 1:
A method for providing a Moving Pictures Experts Group, MPEG, Media Transport, MMT, media content, the method comprising:
receiving (<NUM>), by an MMT aware network entity, MANE (<NUM>), an MMT media content and a signaling message related to the MMT media content from an MMT sending entity (<NUM>), the signaling message including a flag indicating that particular media data in the MMT media content is replaced or modified or changed[claim <NUM>];
receiving (<NUM>), by the MANE (<NUM>), a modification request message to request to modify particular media data of at least part of the MMT media content, the modification request message including at least one of information related to the particular media data to be modified and change type information of the particular media data [claim <NUM>];
updating (<NUM>), by the MANE (<NUM>), the information related to the particular media data in the signaling message based on the modification request message; and
transmitting, by the MANE, the updated signaling message to an MMT receiving entity (<NUM>).