HK1222503B - Delivery of targeted media content - Google Patents

Description

Delivery of targeted media content

Related applications

This application claims the benefit of priority to U.S. Provisional Patent Application No. 61/898,425 filed on October 31, 2013 (Attorney Docket No. P61993Z), U.S. Provisional Patent Application No. 61/879,014 filed on September 17, 2013 (Attorney Docket No. P61026Z), and U.S. Non-Provisional Patent Application No. 14/487,349 filed on September 16, 2014 (Attorney Docket No. P66302), and incorporates the contents of these applications by reference.

Background Art

The development of multimedia services (including streaming and conversational services) is one of the key drivers of the evolution towards new mobile broadband technologies and standards. Mobile devices are increasingly consuming digital video content. Many video applications are widely used on mobile devices in daily life. For example, online video streaming includes popular services such as YouTube and Hulu. Video recording and video conferencing include services such as Skype and Google Hangout. In 2011, YouTube had over one trillion global views. Ten percent of these views were made via mobile phones or tablets. As more smartphones, tablets, and other mobile computing devices are purchased, their use for video recording and video conferencing will increase dramatically. This high consumer demand for multimedia services, combined with advances in media compression and wireless network infrastructure, will benefit future cellular and mobile broadband systems by improving their multimedia service capabilities and delivering high Quality of Experience (QoE) to consumers, thereby ensuring ubiquitous access to video content and services from any location, at any time, and using any device or technology.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present disclosure will be apparent from the following detailed description taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the present disclosure; and wherein:

FIG1 illustrates a block diagram of a Media Presentation Description (MPD) metadata file configuration according to an example;

FIG2 illustrates a block diagram of Hypertext Transfer Protocol (HTTP) streaming according to an example;

3 illustrates a block diagram of an energy-characterization-aware radio access network (RAN) architecture for Hypertext Transfer Protocol (HTTP-based) video streaming according to an example;

FIG4 shows a diagram of a broadcast multicast service center (BMSC) according to an example;

FIG5 shows a diagram of a Multimedia Broadcast and Multicast Service (MBMS) User Service Description (USD) according to an example;

6 is a diagram illustrating the insertion of advertisements into a media content stream for multiple users, according to an example;

7 depicts a diagram of descriptors included in a Multimedia Broadcast and Multicast Service (MBMS) User Service Description (USD), according to an example;

FIG8 depicts the functionality of circuitry of a user equipment (UE) operable to receive a multimedia broadcast multicast service (MBMS) of targeted media content;

FIG9 depicts a flow chart of a method for receiving target media content according to an example;

FIG10 depicts the functionality of circuitry of a user equipment (UE) operable to support streaming of media content; and

FIG11 shows a diagram of a wireless device (eg, UE) according to an example.

Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. However, it will be understood that the scope of the invention is not intended to be limited thereby.

DETAILED DESCRIPTION

Detailed description

Before disclosing and describing the present invention, it should be understood that the present invention is not limited to the specific structures, processing steps or materials disclosed herein, but extends to equivalents as will be recognized by those skilled in the art. It should also be understood that the technology employed herein is for the purpose of describing specific examples only and is not intended to be limiting. The same reference numerals in different figures represent the same elements. The numbers provided in the flow charts and steps are provided for clarity of illustration of the steps and operations and do not necessarily indicate a particular order or sequence.

Example Embodiments

The following provides a preliminary overview of the technology embodiments, followed by a more detailed description of specific technology embodiments. This preliminary summary is intended to help readers understand the technology more quickly, but is not intended to identify the key features or essential features of the technology, nor is it intended to limit the scope of the claimed subject matter.

Techniques are described for receiving targeted media content in a broadcast environment at a Multimedia Broadcast Multicast Service (MBMS) client on a user equipment (UE) and playing the targeted media content in a media content stream for consumption at the UE. The MBMS client may receive a User Service Description (USD) containing Media Presentation Description (MPD) information from a server (e.g., an advertising server). The MPD information describes the targeted media content (e.g., a file or session of the targeted media content). The targeted media content may include advertisements. For example, the USD may include group identification (ID) elements for individual files and sessions of the targeted media content. The group ID element may be a descriptor for the individual files and sessions of the targeted media content. For example, the group ID element may identify the targeted media content as being related to cars, movies, or electronics. Furthermore, the MBMS client may receive a USD containing MPD information for streaming media content, such as a live video broadcast or a television (TV) broadcast (e.g., a news broadcast or a football match). The streaming media content may be received from a Broadcast Multicast Service Center (BMSC). An MBMS client can listen to a broadcast channel and determine to cache certain target media content items (e.g., advertisements) based on a group ID element associated with the target media content item (e.g., advertisement) and a user profile associated with the UE. The user profile may include a description of the viewing habits and/or demographic information of the user of the UE. In other words, the user profile may identify the type of target media content that the user of the UE is interested in.

The MBMS client can cache target media content items having group ID elements corresponding to the interests defined in the user profile. The MBMS client can insert the MPD information of the cached target media content items into the MPD information associated with the streaming content to create a merged MPD. The merged MPD can describe the segments to be obtained for both the streaming content and the target media content. Based on the merged MPD, the streaming content and the target media content can be received at the UE. The UE's Dynamic Adaptive Streaming over HTTP (DASH) client can perform playback using the streaming content and the target media content. In one example, the target media content item can be played at a predefined placeholder while the streaming content is being provided. As an example, the streaming content can periodically include an empty 30-second time slot, in which the target media content item is played via the UE's DASH client.

Hypertext transfer protocol (HTTP) adaptive streaming (HAS) can be used as the form of multimedia delivery of internet video.Due to the extensive adoption of the underlying protocol (comprising transmission control protocol (TCP)/internet protocol (IP)) of HTTP and HTTP, the delivery based on HTTP can provide the simplicity of reliability and deployment.Delivery based on HTTP can make simple and effortless stream service become possibility by avoiding network address translation (NAT) and firewall traversal problem.Delivery based on HTTP can also provide the ability of using standard HTTP server and cache rather than dedicated stream server.Due to the state information that is minimum or reduces on the server side, delivery based on HTTP can provide scalability.

When using HAS to deliver Internet multimedia content, the video client operating on the mobile device can be configured to perform a major role in rate adjustment by selecting and requesting an appropriate video presentation level for obtaining data from a specified resource (e.g., a multimedia server) from a video server using HTTP GET or partial GET commands. The video client first establishes a certain level of buffer before starting to play streaming media content (e.g., audio or video). This phase is called the start phase. After this, the client starts to play the buffered multimedia content. The quality and resolution of the multimedia playback at the client device depends on the available link bandwidth. The video client typically estimates the available link bandwidth only based on higher layer throughput predictions (e.g., HTTP-level video streaming throughput) or Transmission Control Protocol (TCP) throughput.

Multimedia streaming in high-mobility environments can be challenging when fluctuations in network conditions (i.e., network volatility) reduce the communication data rate associated with the multimedia content. When an overloaded network causes the communication data rate to decrease, the end-user quality of experience (QoE) can also decrease. For example, multimedia content received at a mobile device may have a lower resolution or quality and/or the multimedia content may be periodically interrupted or paused when being provided over an overloaded network.

Due to inefficient bandwidth utilization and poor end-user quality of experience, the use of progressive download-based streaming techniques in mobile networks with limited resources may be undesirable. As discussed in detail below, hypertext transfer protocol based streaming services (e.g., Dynamic Adaptive Streaming over HTTP (DASH)) can be used to address the weaknesses of progressive download-based streaming.

The multimedia content streamed to a client (e.g., a user equipment (UE)) may include multiple multimedia content segments. Each of the multimedia content segments may include a different encoding version, with the different encoding versions representing multimedia content at different quality levels. The different encoding versions may allow the client to seamlessly adapt to changing network conditions. For example, when the network condition is good (i.e., the network condition is above a predetermined threshold), the client may request a multimedia content segment with a higher video quality. When the network condition is poor (i.e., the network condition is below a predetermined threshold), the client may request a multimedia content segment with a lower video quality. As a result, when the network condition is poor, the client is still able to receive the multimedia content segment (albeit at a lower quality), thereby reducing the possibility of interrupting the adaptive media stream.

In DASH, the client can select the multimedia content segment with the highest bit rate so that the multimedia content segment can be downloaded in time at the client for media playback without causing re-buffering events in the media playback. In other words, the client may not select a multimedia content segment that is so high that the adaptive media stream is periodically interrupted to cache or preload a portion of the media content onto the client before resuming media playback at the client. In one example, poor network conditions can reduce the quality of the media content stream. Poor network conditions can include zero coverage, bandwidth mutations, packet loss, large delay variations, etc. Although adaptive streaming technology can take current network conditions into account when calculating available throughput and determining an appropriate stream bit rate based on the available throughput, smooth media playback at the client may not be guaranteed during network mutations and/or poor network conditions.

Therefore, to maintain a desired quality of experience for adaptive media streaming at the client, the client's planned route and current network conditions along the planned route can be used to strategically cache multimedia content segments at the client, resulting in smoother streaming playback and improved quality of experience at the client. The client can select a planned route (i.e., the geographic route the client will traverse). The client can stream media content (e.g., a movie) while traversing the planned route. In one example, the client can include a mobile device located within a moving vehicle or a computing device within the vehicle. The client can receive current network conditions for the planned route from a channel information database (CID). The current network conditions may include certain locations along the planned route (e.g., tunnels, bridges, remote areas) with corresponding network conditions below a predetermined threshold. The client can request additional media content segments of the media content (e.g., additional segments of a movie) from a media content server and then store the additional media content segments in a cache. When the client arrives at a location along the planned route with network conditions below the predetermined threshold, the client can play the media content stored in the cache. As a result, substantially continuous media playback can be provided at the client even when current network conditions along the planned route fall below the predetermined threshold.

Wireless Multimedia Standards

There are already multiple multimedia standards that have been developed to enable multimedia to be transmitted to, from, or between mobile computing devices. For example, in streaming video, the Third Generation Partnership Project (3GPP) has developed Technical Specification (TS) 26.234 (e.g., Version 11.0.0), which describes a packet-switched streaming service (PSS) based on the Real-Time Streaming Protocol (RTSP) for unicast streaming of on-demand or live content. In addition, 3GPP TS 26.247 (e.g., Version 11.0.0) describes streaming services based on the Hypertext Transfer Protocol (HTTP), including progressive download and Dynamic Adaptive Streaming over HTTP (DASH). The 3GPP-based Multimedia Broadcast and Multicast Service (MBMS) specification TS 26.364 (e.g., Version 11.0.0) specifies streaming and downloading technologies for multicast/broadcast content distribution. In this way, a DASH/PSS/MBMS-based mobile computing device (e.g., user equipment (UE)) decodes and renders the streamed video at the UE device. In all of these specifications, support for the 3GP file format in 3GPP TS 26.244 (e.g., version 11.0.0) is mandated to support file download and HTTP-based streaming use cases.

An example of a standard for conversational video communications (e.g., video conferencing) is provided in 3GPP TS 26.244 (e.g., 11.0.0). This standard describes Multimedia Telephony Service over IMS (MTSI), which allows for the delivery of advanced multimedia conversational services and content over a network based on the Internet Protocol (IP) Multimedia Subsystem (IMS). IMS is standardized in 3GPP TS 26.140 (e.g., 11.0.0). An MTSI-based transmitter UE terminal can capture and record video, and then transmit the video to an MTSI-based receiver UE terminal over the 3GPP network. The receiver UE terminal can then decode and render the video. 3GPP TS 26.140 also enables video sharing using Multimedia Sharing Service (MMS), which provides support for the 3GP file format.

The above standards are provided as examples of wireless multimedia standards that can be used to transmit multimedia files to, from, or between multimedia devices. These examples are not intended to be limiting. Additional standards can be used to provide streaming video, conversational video, or video sharing.

Streaming standards

A more detailed description of HTTP streaming, and more specifically of the DASH standard, is provided herein in connection with embodiments of the present invention. The detailed description is not intended to be limiting. As will be further explained in the following paragraphs, embodiments of the present invention can select and/or transmit multimedia with a desired energy characterization by enabling a mobile device, or a server in communication with a mobile device, to be used to efficiently transmit multimedia files to, from, and/or between multimedia devices. Multimedia can be transmitted using standardized or non-standardized communication schemes.

Hypertext Transfer Protocol (HTTP) stream can be used as the form of multimedia delivery of internet video.In HTTP stream, multimedia file can be divided into one or more fragments and use HTTP protocol to be delivered to client.Due to the extensive adoption of the underlying protocol (comprising Transmission Control Protocol (TCP)/Internet Protocol (IP)) of HTTP and HTTP, the delivery based on HTTP can provide the simplicity of reliability and deployment.Delivery based on HTTP can make the stream service of simplification become possible by avoiding Network Address Translation (NAT) and firewall traversal problem.Delivery based on HTTP or streaming can also provide the ability of using standard HTTP server and cache rather than dedicated stream server.Due to the state information that is minimum or reduces on the server side, the delivery based on HTTP can provide scalability.The example of HTTP streaming technology can comprise the smooth streaming of Microsoft IIS, the real-time streaming of Apple HTTP and the dynamic streaming of Adobe HTTP.

DASH is a standardized HTTP streaming protocol. As shown in Figure 1, DASH can specify different formats for Media Presentation Description (MPD) metadata files 102, which provide information about the structure and different versions of the media content representations stored in the server and the format of the segments. The MPD metadata file contains information about the initialization of the media player and the media segments (for example, the media player can view the initialization segment to determine the container format and media timing information) to ensure that the segments are mapped to the media representation timeline for switching and synchronous presentation with other representations. DASH technology has been standardized by other organizations (for example, the Moving Picture Experts Group (MPEG), the Open IPTV Forum (OIPE), and Hybrid Broadcast Broadband Television (HbbTV)).

A DASH client can receive multimedia content by downloading segments via a series of HTTP request-response transactions. DASH can provide the ability to dynamically switch between different bitrate representations of media content as the bandwidth available to the mobile device changes. Thus, DASH can allow for rapid adaptation to changing network and wireless link conditions, user preferences, and device capabilities, such as display resolution, the type of central processing unit (CPU) employed, available memory resources, and so on. The dynamic adaptation of DASH can provide users with better quality of experience (QoE), with shorter startup delays and fewer rebuffering events compared to other streaming protocols.

In DASH, the media presentation description (MPD) metadata 102 can provide information about the structure and different versions of the media content representation stored in the web/media server 212, as shown in Figure 2. In the example shown in Figure 1, the MPD metadata is temporarily divided into time periods with a predetermined length (in this example, for example, 60 seconds). Each time period may include multiple adaptation settings 104. Each adaptation setting can provide information about one or more media components with several encoding options. For example, the adaptation setting 0 in this example may include various differently encoded audio options, such as different bit rates, mono, stereo, surround sound, etc. In addition to providing audio of different qualities for multimedia presentation on the time period ID, the adaptation settings can also include audio in different languages. The different options provided in the adaptation settings are called representations 106.

In FIG1 , an adaptive setup 1 is shown providing video at different bit rates (e.g., 5 megabits per second (Mbps), 2Mbps, 500 kilobits per second (kbps), or trick modes). Trick modes can be used to seek, fast forward, rewind, or otherwise change a position in a multimedia stream file. In addition, the video can also be available in different formats (e.g., two-dimensional (2D) or three-dimensional (3D) video). Each representation 106 may include segment information 108. The segment information may include initialization information 110 and actual media segment data 112. In this example, an MPEG 4 (MP4) file is streamed from a server to a mobile device. Although MP4 is used in this example, a variety of different codecs may also be used, as previously discussed.

Multimedia in an adaptive setting can also be divided into smaller segments. In the example of FIG1 , the 60-second video segment of adaptive setting 1 is further divided into four sub-segments 112 of 15 seconds each. These examples are not intended to be limiting. The adaptive setting and the actual length of each media segment or sub-segment depend on the type of media, system requirements, possible interference types, etc. Actual media segments or sub-segments can have a length of less than one second to several minutes.

As shown in FIG2 , the MPD metadata information can be transmitted to a client 220, such as a mobile device. The mobile device can be a wireless device configured to receive and display streaming media. In one embodiment, the mobile device can perform only a portion of this function, such as receiving the streaming media and then transmitting the streaming media to another device or display device for rendering. The mobile device can be configured to run the client 220. The client can request segments using an HTTP GET 240 message or a series of partial GET messages. The client can control the streaming session, such as managing timed requests and smooth playback of a series of segments, or potentially adjusting the bit rate or other properties to react to changes in the wireless link, device status, or user preferences.

Figure 2 shows a framework for DASH-based streaming. A media encoder 214 in a web/media server 212 can encode input media from an audio/video input 210 into a format that can be stored or streamed. A media segmenter 216 can be used to split the input media into a series of segments 232 that can be provided to a web server 218. A client 220 can request new data in a segment using an HTTP GET message 234 sent to a web server (e.g., an HTTP server).

For example, the web browser 222 of the client 220 may request multimedia content using an HTTP GET message 240. The web server 218 may provide the client with an MPD 242 of the multimedia content. The MPD may be used to convey the index of each fragment and the corresponding location of the fragment, as shown in the associated metadata information 252. The web browser may pull the media from the server fragment by fragment according to the MPD 242, as shown in 236. For example, the web browser may request the first fragment using an HTTP GET URL (frag 1 req) (244). A uniform resource locator (URL) or global resource locator may be used to tell the web server which fragments the client is to request (254). The web server may provide the first fragment (i.e., fragment 1 246). For subsequent fragments, the web browser may request fragment i using an HTTP GET URL (frag i req) (248), where i is the integer index of the fragment. As a result, the web server may provide fragment i (250). The fragments may be presented to the client via the media decoder/player 224.

FIG3 illustrates the flow of multimedia content 312 between an HTTP server 310 providing the multimedia content and a 3GPP client 338 operating on a mobile device (e.g., a UE 336). The HTTP server may be connected to a public or private network 322 (or the Internet), which in turn communicates with a core network 324 of a wireless wide area network (WWAN). In one embodiment, the WWAN may be a 3GPP LTE-based network or an IEEE 802.16-2009-based network. The core network may access a wireless network 330 (e.g., an evolved packet system (EPS)) via a radio access network (RAN). The RAN 332 may provide the multimedia content to the client operating on the UE 336 via a node (e.g., an evolved Node B (eNB) 334).

In one example, HTTP server 310 may be coupled to a channel information database 350. Channel information database 350 may include current network conditions for multiple geographic locations. The multiple geographic locations may include specific roads, streets, communities, geographic regions, bridges, tunnels, etc. The current network conditions may be based on real-time monitoring of the current network conditions for the multiple geographic locations. Thus, as the current network conditions change, channel information database 350 may be dynamically updated. Alternatively, the current network conditions may be inferred based on historical network condition information for the multiple geographic locations. In another example, the current network conditions may be determined using crowdsourced network condition information.

Enhanced Multimedia Broadcast Multicast Service (eMBMS)

The continued commercialization of LTE networks has led to increased interest in the deployment of enhanced Multimedia Broadcast and Multicast Services (eMBMS). The LTE version of Multimedia Broadcast Multicast Service (MBMS) is eMBMS. MBMS is a point-to-multipoint interface specification designed to provide efficient delivery of broadcast and multicast services. MBMS can be applied to mobile television (TV) and radio broadcasting, as well as file delivery and emergency alerts. With the first deployment of eMBMS expected in 2014, it is important to enhance the performance and availability of core MBMS user service features. MBMS, as specified in 3GPP TS 26.346 Version 6-12, is a point-to-multipoint system used on cellular networks operating in accordance with one of the cellular standards promulgated by 3GPP. MBMS is designed for efficient delivery of popular media content to multiple receivers based on broadcast and multicast technologies. At the service layer, MBMS is based on the User Datagram Protocol (UDP) at the transport layer and defines a delivery protocol for both streaming of multimedia content and reliable downloading of files using the Real-time Transport Protocol (RTP) for streaming and File Delivery over Unidirectional Transport (FLUTE) for file delivery.

MBMS access clients can receive media data and metadata from a server (called a Broadcast Multicast Service Center (BMSC)) via User Service Discovery (USD) signaling. MBMS has been used as an evolved MBMS (eMBMS) mode in the development of 3GPP-based Long Term Evolution (LTE) standards corresponding to 3GPP Release 8 and higher. The MBMS download transport technology is designed to deliver an arbitrary number of objects to a relatively large number of receivers via MBMS. MBMS download defines several technologies to increase reliability, such as FEC and file repair. The download transport technology allows the delivery of DASH segments and media presentation descriptors.

MBMS download transport is an attractive alternative to HTTP-based unicast download transport. Advantages include supporting new non-real-time service types, providing content that complements MBMS streaming services, and leveraging the increasing storage capacity of devices. The DASH segment format (although primarily targeted at unicast transport over HTTP) is agnostic as to whether the delivery environment is unicast or multicast. The MBMS User Service specification TS 26.364 indicates the possibility of sending DASH-formatted content over the FLUTE protocol using MBMS download transport. As defined in RFC 3926, FLUTE allows for the delivery of segments over MBMS such that clients observe them as being delivered over HTTP/TCP. An HTTP-URL is assigned to each object delivered in FLUTE, and the HTTP-URL maps to the segment URL in the MPD; that is, the content location element in the file transfer table (FDT) of the object delivered via FLUTE matches the segment URL in the MPD. The UE can identify the received DASH representation based on a comparison of the HTTP URL contained in the MPD with the URL information contained in the FLUTE packets.

Figure 4 illustrates the MBMS-based Broadcast Multicast Service Center (BMSC) sub-functional architecture and the associated interfaces between the UE and the BMSC. The BMSC or BM-SC can communicate with and/or control content providers/Broadcast Multicast Sources. The BM-SC can provide MBMS delivery functionality. MBMS is further described in 3GPP TS 26.364.

FIG5 shows a diagram of a Multimedia Broadcast and Multicast Service (MBMS) User Service Description (USD). The BM-SC announces available MBMS services via one or more instances of User Service Descriptions (USD) organized into service bundles. MBMS user services are described by metadata (objects/files) delivered using a download transfer method or using an interactive announcement function. MBMS user service discovery or announcement involves delivering segments of metadata to multiple receivers in an appropriate manner. The metadata itself describes the details of the service. Metadata management information includes (one or more) metadata envelope objects (in XML format) that allow for identification, versioning, updating, and time validity of metadata segment objects.

As shown in Figure 5, the metadata included in the USD provided to the receiver may include: metadata slice objects describing the details of a single or a bundle of MBMS user services, (one or more) metadata slice objects describing the details of an MBMS user service session, (one or more) metadata slice objects describing the details of the associated delivery method, (one or more) metadata slice objects describing the details of service protection, metadata slice objects describing the details of the FEC repair data stream, metadata slice objects providing media presentation description (of DASH content), (one or more) metadata slice objects providing initialization fragments (of DASH content), (one or more) metadata fragment objects providing scheduling information description, (one or more) metadata slice objects providing filtering data for MBMS user services within a service bundle at the level of a single session of a given user service or a single file content within a user service.

The growth of video delivery services (e.g., streaming, download, broadcast, TV, etc.) has driven advertisers to better target users with personalized ads, increasing the likelihood that users will view their ads and their relevance to their needs/interests (i.e., not skipped or not viewed). In broadcast networks (e.g., those based on e-MBMS), from an ad insertion perspective, ads are typically inserted before the broadcast and delivered via the broadcast just like the main video content. This offers little opportunity for targeted advertising to achieve a better return on investment, as all users will receive the same ads, leaving no room for personalization. Therefore, as described in more detail herein, the delivery of ads via e-MBMS can be personalized to the user.

In one configuration, personalized advertisements can be inserted into media content streams in real time. For example, two major football teams in a densely populated city will play against each other in a derby at the weekend. Since a large number of fans are expected to be interested in the game, the operator plans to provide services to its subscribers via MBMS. The game content will be broadcast using the DASH format based on the download transmission technology based on FLUTE. The operator plans to deliver different targeted advertisement sets to club fans (i.e., to be played during game breaks, etc.) to promote the products of each football club's fan shop. Since it is expensive in terms of bandwidth to pre-insert different advertisements at the server for each stream to broadcast multiple event streams of main content, the operator decided to broadcast a single main event stream together with different advertisement sets, leaving the advertisement insertion to the client. In other words, the client can insert advertisements belonging to a certain set into predefined placeholders within the streaming content (i.e., a single main event stream).

In another configuration, personalized advertisements can be inserted into the media content stream from a cache. An operator can offer its MBMS-capable subscribers an advertisement delivery service enabled by content caching capabilities in the UE, which are currently available via memory/storage capabilities in mobile devices. The advertisement content can be based on the DASH file format. An MBMS client device of a user subscribing to the service can join a broadcast-multicast session (e.g., ideally scheduled at a time with no traffic or congestion) and cache advertisements relevant to the user's preferences/interests. During a subsequent live event, the user can watch one of these pre-cached advertisements instead of watching the advertisements in the main content stream. In addition to enabling advertisement personalization, this is particularly desirable when the client experiences poor network conditions during the broadcast of advertisements within a live stream.

Therefore, personalized advertisement insertion can be supported in MBMS and eMBMS. The main broadcast content (i.e., streaming content) and the target media content files (e.g., advertisements) can be broadcast separately to the client, and the insertion of the target media content files can be enabled at the client. With respect to live events, the delivery of personalized advertisements to the client can be scheduled towards timely insertion into the main broadcast content. If pre-cached advertisements are authorized and meet certain criteria (e.g., the advertisements are obtained earlier from the operator network), the insertion of these advertisements can replace the advertisements in the main broadcast stream. In addition, the UE can selectively cache the broadcasted advertisements based on classification information according to user preferences.

In one example, the MBMS client of the UE may listen to a broadcast channel for target media content. The target media content may be broadcast from a broadcast multicast service center (BMSC). Each target media content item may be associated with a group identification (ID) element and/or a descriptor. The group ID element and/or the descriptor may identify a category associated with the target media content item. For example, a first group ID element may identify that a first target media content item is related to a car, and a second group ID element may identify that a second target media content item is related to sports. Other examples of group ID elements may include social groups, occupations, ethnic groups, etc. The target media content items marked with a group ID element may be media content files, or alternatively, the target media content items may be media content sessions, where a media content session is a plurality of media content files.

In one example, an MBMS client may determine a group ID element for each target media content item to be broadcast according to a user service description (USD). The MBMS client may receive a USD from the MBMS before transmitting the target media content item, wherein the USD describes the target media content item to be broadcast. The USD may include group information or a group filter containing a group ID element describing the target media content item. The group filter or group information may be part of a filter description metadata segment in the USD. In other words, the USD is similar to an electronic service guide. The USD may describe the broadcast channel, the target media content items to be delivered to each broadcast channel, the time at which each target media content item is delivered, a characterization of each target media content item (e.g., a descriptor or group ID element), etc. The group ID element may indicate that a specific target media content item is related to one of a car, a video game, a music player, etc.

In another example, the USD may signal such classification/category information in a specific USD element. For example, the schedule description element may include a fileSchedule element, which may contain details about the files being broadcast (i.e., target media content items). In addition, descriptors of classification and category information for advertisements may be included in the fileSchedule element to differentiate on a file-by-file basis within the context of the broadcast advertisement files, i.e., each broadcast advertisement file may be associated with a descriptor of the category/category to which the advertisement belongs.

Furthermore, the MBMS client can maintain a database of classification and categorization information regarding the types of target media content that users are interested in. In other words, the MBMS client can maintain a user profile for each user of a UE that indicates the user's viewing habits and demographic information. As a non-limiting example, the user profile may indicate that the user prefers advertisements related to sports, cars, and politics. Furthermore, demographic information may identify the user's gender, age, geographic location, and so on.

When the BMSC broadcasts target media content files, the MBMS client can selectively cache target media content files (i.e., DASH segments of advertisements) that are of interest to the user of the UE. The MBMS client can look for broadcast files with descriptors (as indicated in the USD) that match the user interests in the user profile. Similarly, the MBMS client can select target media content files with group ID elements that match the group ID elements contained in the user profile. In other words, the MBMS client can selectively receive content with group filter values that are known to match the user profile. In one example, the MBMS client can select target media content sessions (i.e., multiple media content files) with group ID elements that correspond to the user profile. The MBMS client can store the selected media content files in a cache, and the MBMS client can then play the media content files for consumption at the UE during a media content stream (e.g., a football game, a news broadcast).

In one example, a user profile descriptor (i.e., a descriptor or group ID element) for classification and category information for a given session can be included in a session schedule element in the USD, along with a set of start and stop times, to distinguish the broadcast content files in the session on a time slot-by-time slot basis as indicated by the start and stop times. That is, content files broadcast at a given time interval can be associated with the user profile descriptor of the category/classification to which the target user belongs. In another example, the presentation format of the target media content file can be based on the determination of a set of keywords that describe the target media content. These determined context information keywords can be stored locally in a database maintained by the MBMS client and matched with keywords representing advertising content. Target media content (e.g., advertisements) whose content description keywords match the content information keywords are identified as target media content to be inserted and presented to the user.

Because the targeted media content files are broadcast, the MBMS client may be able to receive all broadcast media content files. However, the MBMS client may parse the header of the targeted media content files and determine that the UE's user is not interested in targeted media content files of that type. Therefore, the MBMS client may ignore targeted media content files that do not correspond to the user profile. As a non-limiting example, if the user profile associated with the UE indicates that the UE is a 65-year-old male, the UE's MBMS client may choose to ignore advertisements with a group element ID indicating that the advertisement is for children's action toys.

In one example, the set of advertising content can be broadcast to MBMS clients via a separate session. The advertising content can be broadcast before the main content is broadcast, for example, during periods of logistics volume or low congestion. The advertising content can be delivered to the MBMS clients along with metadata corresponding to remote elements describing the advertising content and metadata containing classification and category information about the advertisement (e.g., sports, music, cars, appliances, computers, food, etc.). The classification and category information can include a group ID element or descriptor that is attached to each advertisement with a uniform resource indicator (URI) and a value equal to the context of the advertisement. In one example, a relatively large number of users may wish to receive and cache each classification/category of advertisements in order to tailor the delivery of advertisements via broadcast.

Subsequently, the MBMS client can receive streaming content (e.g., a main content broadcast of a football game). The streaming content can include real-time video or television (TV) broadcast. The streaming content can be broadcast to a group of users. The streaming content can contain predefined placeholders for target media content files (e.g., advertisements). For example, the MBMS client can know the streaming content being received based on the USD. The MBMS client can receive the USD from the BMSC in advance. The USD can describe the broadcast content of the broadcast session and all broadcast channels. In other words, the USD can describe the streaming content as well as the target media content files (e.g., advertisements). Since the streaming content can be content in the DASH format, the MPD of the DASH format content can be included in the USD. The MPD can be an Extensible Markup Language (XML) file.

In order to play both streaming media content and target media content at the UE, an MPD identifying segments associated with the streaming media content and target media content associated with the user profile (e.g., target media content stored in the UE's cache) can be created. In the MPD of the streaming content, a time period or placeholder can point to a remote element via XLINK, where the remote element includes information about the target media content file (e.g., advertising content). The remote element can be an element that is not fully contained in the MPD, but is referenced by an HTTP-URL using a simplified profile of XLINK in the MPD. In other words, in order to insert the target media content file into the streaming content, XLINK can be used to refer to an external DASH segment or DASH scene in the MPD.

In the first MPD of streaming content (e.g., a first XML file), a second MPD (i.e., a second XML file) of target media content associated with a user profile can be referenced using XLINK. Remote elements from the second MPD can be inserted into the first MPD, resulting in a larger MPD. In other words, two XML files can be merged to create a larger MPD. The purpose here is advertising insertion, because advertisements are usually transmitted from different servers. Advertisements are managed separately from streaming content. In order to insert advertisements into streaming content (e.g., an ongoing DASH stream), XLINK can be used to refer to external DASH segments of advertisements. The second MPD associated with the external DASH segment (i.e., the MPD of the target advertising content) can be inserted and merged with the first MPD of the streaming content to create a larger MPD or a merged MPD. The merged MPD can provide an overall content description for both the streaming content and the target media content (e.g., advertisements associated with the user profile). Therefore, the UE can use the merged MPD to play both the streaming content and the target media content.

In one example, a DASH client on a UE may receive an MPD for streaming content from an MBMS client on the UE. The DASH client may retrieve and play media content segments (associated with the main content playback) based on the MPD for the streaming content. When the DASH client finds an XLINK attribute pointing to a remote element (e.g., a placeholder) in the MPD, the DASH client may request the remote element from the MBMS client on the UE. The MBMS client may select one of the cached remote elements (i.e., a remote element describing advertisement content) and provide it to the DASH client. For example, the MBMS client may select one of the remote elements corresponding to a user profile. The DASH client may receive the remote elements from the MBMS client and then reassemble the remote elements into the MPD for the streaming content. In other words, the MPD may be reconstructed to include the MPD for the remote element (i.e., an MPD describing the target media content to be played along with the streaming content). For example, the MPD associated with the remote element may be merged with the original MPD. The DASH client may begin retrieving the segments described by the remote elements (i.e., segments corresponding to personalized advertisements) based on the reconstructed MPD. The DASH client may retrieve the segments from the MBMS client's cache and provide these segments for display on the UE. Based on the reconstructed MPD, the DASH client can play both the streaming content and the target media content.

Because different user profiles can be associated with different UEs, each MPD can be constructed differently depending on which advertisements correspond to the user profile. For example, a first MBMS client in a first UE may receive an MPD that describes DASH segments of an action movie being broadcast. A second MBMS client in a second UE may receive the same MPD. In other words, both UEs may be receiving a broadcast of an action movie. However, the user profile associated with the first UE may indicate that the user likes car advertisements. Therefore, the first MBMS client may reconstruct the MPD such that the remote elements referenced in the reconstructed MPD are related to car advertisements. On the other hand, the user profile associated with the second UE may indicate that the user likes children's toys. Therefore, the second MBMS client may reconstruct the MPD such that the remote elements referenced in the reconstructed MPD are related to toy advertisements. Based on the user profile, users watching the same action movie (i.e., the main content stream) may receive different targeted media content, such as car advertisements or toy advertisements. Each UE can search for different remote elements (e.g., corresponding to advertisements of interest to the user) among the broadcast remote elements and insert those remote elements into its own construction of the MPD.

In one configuration, considering a live broadcast event setting, the main content stream and the advertisement stream may be broadcast simultaneously to the MBMS client of the UE. In other words, in this configuration, the MBMS client may not receive advertisements during traffic or non-congested periods before the main content stream is broadcast. The advertisement stream may be associated with a relatively lower rate compared to the main content because the advertisement stream is not consumed immediately at the UE. The MBMS client of the UE may cache the advertisements for timely insertion into the main content. The advertisements may be transmitted in parallel with the main content, and the MBMS client is expected to receive both. The BM-SC may schedule the delivery of the main content transmission and the advertisements so that the advertisements arrive in a timely manner to be inserted into the main content. In the event that an XLINK-based remote element pointing to the advertisement may appear, since the BM-SC controls the MPD update, the BM-SC can ensure the reception of the advertisement before updating the MPD and the XLINK-based remote element.

In one example, a remote element can be parsed when the DASH client receives one or more elements verbatim in the HTTP response body as a result of issuing an HTTP GET request to that URL. Attributes and elements obtained from the remote element can be added to the element of the MPD containing the @xlink:href and can be merged with those already present in the MPD. If the same attribute exists in both the MPD and the remote element, the attribute value can be the same. If they are different, the value of the attribute in the MPD can take precedence over the value of the attribute in the remote DASH element.

In one configuration, operators can pre-broadcast advertisements, and each MBMS client can retrieve and cache advertisements of interest for later viewing, for example, during a live event using DASH. Each broadcast advertisement is also accompanied by a remote element (for insertion into the DASH content) and descriptor metadata containing classification and category information about the advertisement, allowing the MBMS client to selectively receive and cache each advertisement.

FIG6 is a diagram 600 illustrating the insertion of advertisements into a media content stream for multiple users. A broadcast multicast service center (BMSC) 602 can broadcast multiple time periods of a media content stream. For example, a main content stream can be divided into five time periods of DASH content, namely, time period 1 through time period 5. The time periods in the main content stream can be described in a media presentation description (MPD). A multimedia broadcast and multicast service (MBMS) client of a user equipment (UE) can receive the media content stream from the BMSC 602 according to the MPD.

The MBMS client can listen to a broadcast channel for advertisements broadcast from the MBSC 602 before or simultaneously with the media content stream. For example, the advertisements may include five separate advertisements, namely, Advertisement 1 through Advertisement 5. Each advertisement may be accompanied by a remote element and a descriptor. Based on the user profile associated with the user of the UE, the MBMS client can determine which advertisements to receive and cache at the MBMS client. Thus, the MBMS client can cache advertisements with descriptors corresponding to the user profile and ignore advertisements with descriptors that do not correspond to the user profile. Depending on the user profile, different MBMS clients may determine to cache different types of advertisements.

The UE's DASH client can play the broadcasted main content and advertisements according to the MPD. As an example, the MPD can contain a remote element via an XLINK between period 2 and period 3. The remote element can refer to an advertisement to be inserted between period 2 and period 3 during the media content stream. The DASH client can request the remote element from the MBMS client. In response, the MBMS client can provide the DASH client with a remote element corresponding to the user profile. The DASH client can then look up the advertisement content associated with the remote element and play the advertisement content together with the media content stream. As a non-limiting example, a first DASH client can play period 1, period 2, advertisement 4, period 4, and period 5. A second DASH client can play period 1, period 2, advertisement 3, period 4, and period 5. Depending on the user profile, different DASH clients can play different types of advertisements.

FIG7 is an exemplary descriptor 700 that may be included in a Multimedia Broadcast and Multicast Service (MBMS) User Service Description (USD). The descriptor may also be referred to as a user profile descriptor. The descriptor may be associated with a target media content file broadcast from a BMSC. The descriptor may describe a classification or category of the target media content file. For example, the descriptor may indicate that a target media content file is related to a car advertisement or a mobile phone advertisement. The descriptor may be an XML structure that is inserted into a sessionSchedule element or a fileSchedule element of a USD. The descriptor may include multiple fields, such as those related to access control, identity, interests, context, terminal profile, preferences, and information.

Another example provides functionality 800 of circuitry comprising a user equipment (UE) of a multimedia broadcast multicast service (MBMS) client operable to receive targeted media content, as illustrated in the flowchart of FIG8 . The functionality may be implemented as a method or the functionality may be executed as instructions on a machine, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The circuitry may be configured to receive first metadata from a server via MBMS, the first metadata comprising group information for one or more files or sessions corresponding to the targeted media content and media presentation description (MPD) information associated with the files or sessions, wherein each file or session in the group information is associated with a group identification (ID) element included in the group information, as in block 810. The circuitry may be configured to receive second metadata in a user service description (USD) via MBMS, the USD comprising MPD information for the streaming media content, as in block 820. The circuitry may be configured to identify a user profile associated with a user of the UE, wherein the user profile comprises a group ID element associated with the user, as in block 830. The circuitry may be configured to select target media content corresponding to a file or session having a group ID element included in the user profile, as in block 840. The circuitry may be configured to insert target MPD information of the selected target media content having the group ID element included in the user profile into the MPD information of the streaming media content to generate a merged MPD, as in block 850. The circuitry may be configured to receive the selected target media content via the MBMS client according to the merged MPD, as in block 860. The circuitry may be configured to receive the streaming media content via the MBMS client according to the merged MPD, as in block 870. Furthermore, the circuitry may be configured to perform playback at the UE using the selected target media content and the streaming media content, as in block 880.

In one example, the target media content includes an advertisement. In another example, the group ID element associated with the user in the user profile is related to one of the following: the user's viewing habits or demographic information describing the user. In another example, the circuitry may be further configured to: store the selected target media content received via the MBMS client in a cache at the UE; and perform playback at the UE using the selected target media content stored in the cache at the UE.

In one configuration, the circuitry may be further configured to receive the selected target media content and streaming media content from a broadcast multicast service center (BMSC). In another configuration, the circuitry may be further configured to receive first metadata from an advertising server via MBMS. In one example, the first metadata received from the server is included in an MBMS User Service Description (USD) that describes the target media content and a group ID element associated with the target media content file. In another example, the UE includes an antenna, a touch-sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, and internal memory or a non-volatile memory port.

Another example provides a method 900 for receiving targeted media content, as shown in the flowchart of FIG9 . The method can be executed as instructions on a machine, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The method may include the operation of receiving, via a Multimedia Broadcast Multicast Service (MBMS) client in a user equipment (UE), first metadata from a server, the first metadata including group information for one or more files or sessions corresponding to the targeted media content and media presentation description (MPD) information associated with the files or sessions, wherein each file and session in the group information is associated with a group identification (ID) element included in the group information, as in block 910. The method may include identifying a user profile associated with a user of the UE, wherein the user profile includes a group ID element associated with the user, as in block 920. The method may include selecting the targeted media content corresponding to the file or session having the group ID element included in the user profile, as in block 930. The method may include receiving, via the MBMS client in the UE, the selected targeted media content, as in block 940. Additionally, the method may include storing the selected target media content in a cache at the UE, as in block 950 .

In one configuration, the method may include: receiving second metadata in a user service description (USD) via MBMS, the USD including MPD information of streaming content; inserting target MPD information of selected target media content having a group ID element included in a user profile into the MPD information of the streaming content to generate a merged MPD; receiving the streaming content via an MBMS client according to the merged MPD; and performing playback at a UE using the streaming content and the selected target media content stored in a cache at the UE.

In one example, the targeted media content includes an advertisement. In another instance, a group ID element associated with a user in a user profile is associated with one of: viewing habits of the user or demographic information describing the user. In another example, the method may include receiving the selected targeted media and streaming media content from a broadcast multicast service center (BMSC).

In one configuration, the file or session corresponding to the target media content includes a file or session in a Dynamic Adaptation over Hypertext Transfer Protocol (DASH) streaming format. In another configuration, the method may include receiving first metadata from an advertising server via MBMS. In another configuration, the first metadata received from the server is included in an MBMS User Service Description (USD) that describes the target media content and a group ID element associated with the target media content file.

Another example provides functionality 1000 of circuitry of a user equipment (UE) operable to support media content streaming, as shown in FIG10 . The functionality may be implemented as a method or the functionality may be executed as instructions on a machine, wherein the instructions are included on at least one computer-readable medium or a non-transitory machine-readable storage medium. The circuitry may be configured to receive, via a multimedia broadcast multicast service (MBMS) client of the UE, a first user service description (USD) segment, the first USD segment including group information for one or more files or sessions corresponding to an advertisement and media presentation description (MPD) information associated with the files or sessions, wherein each file or session in the group information is associated with a group identification (ID) element included in the group information, as in block 1010. The circuitry may be configured to receive, via the MBMS client of the UE, a second USD segment from a broadcast multicast service center (BMSC), the second USD segment including MPD information for streaming media content, as in block 1020. The circuitry may be configured to identify a user profile associated with a user of the UE, wherein the user profile includes a group ID element associated with the user, as in block 1030. The circuitry may be configured to select an advertisement corresponding to a file or session having a group ID element included in the user profile, as in block 1040. The circuitry may be configured to insert target MPD information of the selected advertisement having the group ID element included in the user profile into the MPD information of the streaming content to generate a merged MPD, as in block 1050. The circuitry may be configured to receive the selected advertisement via the MBMS client of the UE according to the merged MPD, as in block 1060. The circuitry may be configured to receive the streaming content from the BMSC via the MBMS client according to the merged MPD, as in block 1070. Furthermore, the circuitry may be configured to perform playback at the UE using the selected advertisement and the streaming content, wherein the advertisement is played between the streaming content, as in block 1080.

In one example, the file or session corresponding to the advertisement includes a file or session in a Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) format. In another example, the circuitry may be further configured to: store the selected advertisement received via the MBMS client in a cache at the UE; and perform playback at the UE using the selected advertisement stored in the cache at the UE. In another example, playback occurs at a Dynamic Adaptive Streaming over Hypertext Transfer Protocol (DASH) client of the UE.

Figure 11 provides an example diagram of a wireless device (e.g., a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile communication device, a tablet, a mobile phone, or other type of wireless device). The wireless device may include one or more antennas configured to communicate with a node or transmitting station (e.g., a base station (BS), an evolved Node B (eNB), a baseband unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a central processing module (CPM), or other type of wireless wide area network (WWAN) access point). The wireless device may be configured to communicate using at least one wireless communication standard, including 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The wireless device may communicate using separate antennas for each wireless communication standard or a shared antenna for multiple wireless communication standards. The wireless device may communicate within a wireless local area network (WLAN), a wireless personal area network (WPAN), and/or a WWAN.

FIG11 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output of the wireless device. The display screen can be a liquid crystal display (LCD) screen or other type of display screen (e.g., an organic light emitting diode (OLED) display). The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display functions. A non-volatile memory port can also be used to provide data input/output options to the user. The non-volatile memory port can also be used to expand the storage capacity of the wireless device. A keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.

Various techniques or aspects or portions thereof may take the form of program code (i.e., instructions) embodied in a tangible medium (e.g., a floppy disk, a compact disc read-only memory (CD-ROM), a hard drive, a non-transitory computer-readable storage medium, or any other machine-readable storage medium), wherein when the program code is loaded into a machine (e.g., a computer) and executed by the machine, the machine becomes an apparatus for implementing the various techniques. Circuitry may include: hardware, firmware, program code, executable code, computer instructions, and/or software. A non-transitory computer-readable storage medium may be a computer-readable storage medium that does not include signals. In the case of a programmable computer executing program instructions, the computing device may include: a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be: random access memory (RAM), erasable programmable read-only memory (EPROM), a flash drive, an optical drive, a magnetic hard drive, a solid-state drive, or other media for storing electronic data. Nodes and wireless devices may also include: a transceiver module (i.e., a transceiver), a counter module (i.e., a counter), a processing module (i.e., a processor), and/or a clock module (i.e., a clock) or a timer module (i.e., a timer). One or more programs that can implement or use the various techniques described in this application can use application programming interfaces (APIs), reusable controls, etc. These programs can be implemented in high-level programming languages or object-oriented programming languages to communicate with computer systems. However, as needed, the program(s) can be implemented in assembly language or machine language. In any case, the language can be a compiled language or an interpreted language and can be combined with hardware implementations.

It should be understood that in order to more particularly emphasize the implementation independence of many of the functional units described in this specification, these units have been labeled as modules. For example, a module can be implemented as a hardware circuit comprising: custom very large scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors (e.g., logic chips, transistors, or other discrete components). A module can also be implemented in a programmable hardware device (e.g., a field programmable gate array, programmable array logic, programmable logic device, etc.).

Modules can also be implemented in software to be executed by various types of processors. An identified module of executable code may, for example, include one or more physical or logical blocks of computer instructions, which may be organized, for example, as objects, procedures, or functions. However, the executable code of an identified module need not be physically located together, but may include different instructions stored in different locations that, when logically combined together, constitute the module and achieve the stated purpose of the module.

In fact, the module of executable code can be a single instruction, also can be a lot of instructions, even can be distributed on several different code segments, between different programs and across several storage devices.Similarly, operational data can be identified and described in the module in the present application, and can be implemented and organized in the data structure of any appropriate type in any suitable form.Actionable data can be collected as a single data set, or can be distributed on different locations (comprising being distributed on different storage devices), and can only exist as the electronic signal on system or network at least in part.These modules can be passive or active, comprise the agent that can be operated as the execution desired function.

References in this specification to "an example" or "exemplary" mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "in an example" or the word "exemplary" in various places in this specification are not necessarily all referring to the same embodiment.

As used in this application, multiple projects, structural elements, constituent elements and/or materials can be presented in a common list for use. However, these lists should be interpreted as if each element of the list is independently identified as a separate and unique component. Therefore, in the absence of contrary instructions, the independent elements of the list should not be interpreted as the substantial equivalents of any other elements of the same list based only on their presentation in a common group. In addition, various embodiments of the present invention and examples can be mentioned together with the replacement of its various components in this application. It should be understood that these embodiments, examples and replacement selections should not be interpreted as substantial equivalents to each other, but should be interpreted as separation of the present invention and autonomous representation.

In addition, the features, structures or characteristics can be combined in one or more embodiments in any appropriate manner. In the following description, a lot of specific details (e.g., examples of layouts, distances, network examples, etc.) are provided to provide a comprehensive understanding of embodiments of the present invention. However, those skilled in the relevant art will recognize that the present invention can be implemented without one or more specific details, or implemented with other methods, components, layouts, etc. In other examples, well-known structures, materials or operations are not shown or described in detail to avoid obscuring aspects of the present invention.

Although the above examples illustrate the principles of the present invention in one or more specific applications, it is apparent to those skilled in the art that many modifications may be made to the form, use, and details of the implementation without the assistance of the inventors without departing from the principles and concepts of the present invention. Therefore, the present invention is not intended to be limited except as set forth in the appended claims.

Claims (17)

1. A user equipment (UE) including a multimedia broadcast multicast service (MBMS) client operable to receive target media content, the UE having circuitry configured to perform the following operations: The first metadata is received from the server via MBMS. The first metadata includes group information of one or more files or sessions corresponding to the target media content and media presentation description (MPD) information associated with the files or sessions, wherein each file and session in the group information is associated with a group identifier (ID) element contained in the group information. The second metadata in the User Service Description (USD) is received via the MBMS, the USD including MPD information of the streaming media content; A user profile is identified as associated with a user of the UE, wherein the user profile includes a group ID element associated with the user; Select the target media content that corresponds to the file or session that has the group ID element included in the user profile; The target MPD information of the selected target media content, which has the group ID element included in the user profile, is inserted into the MPD information of the streaming media content to generate a merged MPD. According to the merged MPD, the selected target media content is received via the MBMS client and stored in the cache at the UE, wherein the group ID element associated with the user in the user profile is related to the user's viewing habits or demographic information describing the user; The streaming media content is received via the MBMS client according to the merged MPD; and Playback is performed at the UE using the selected target media content and the streaming media content stored in the cache at the UE. 2. The UE as claimed in claim 1, wherein the target media content includes advertisements. 3. The UE of claim 1, wherein the circuitry is further configured to receive the selected target media content and the streaming media content from a Broadcast Multicast Service Center (BMSC). 4. The UE of claim 1, wherein the circuitry is further configured to receive the first metadata from the advertising server via MBMS. 5. The UE of claim 1, wherein the first metadata received from the server is included in an MBMS User Service Description (USD), the MBMS User Service Description describing the target media content and the group ID element associated with the target media content file. 6. The UE as claimed in claim 1, comprising an antenna, a touch-sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, and an internal memory or non-volatile memory port. 7. A method for receiving target media content, the method comprising: The Multimedia Broadcast Multicast Service (MBMS) client in the user equipment (UE) receives first metadata from the server. The first metadata includes group information of one or more files or sessions corresponding to the target media content and media presentation description (MPD) information associated with the files or sessions, wherein each file and session in the group information is associated with a group identifier (ID) element contained in the group information. A user profile is identified as associated with a user of the UE, wherein the user profile includes a group ID element associated with the user; Select target media content corresponding to a file or session that has a group ID element included in the user profile, wherein the group ID element associated with the user in the user profile is related to the user's viewing habits or demographic information describing the user; The selected target media content is received via the MBMS client in the UE; The selected target media content is stored in the cache at the UE; The second metadata in the User Service Description (USD) is received via the MBMS, the USD including MPD information of the streaming media content; The target MPD information of the selected target media content, which has the group ID element included in the user profile, is inserted into the MPD information of the streaming media content to generate a merged MPD. The streaming media content is received via the MBMS client according to the merged MPD; and Playback is performed at the UE using the selected target media content and the streaming media content stored in the cache at the UE. 8. The method of claim 7, wherein the target media content includes advertisements. 9. The method of claim 7, further comprising receiving the selected target media content and the streaming media content from a Broadcast Multicast Service Center (BMSC). 10. The method of claim 7, wherein the file or session corresponding to the target media content includes a file or session in the Dynamic Adaptive Streaming (DASH) format based on the Hypertext Transfer Protocol. 11. The method of claim 7, further comprising receiving the first metadata from the advertising server via the MBMS. 12. The method of claim 7, wherein the first metadata received from the server is included in an MBMS User Service Description (USD), the MBMS User Service Description describing the target media content and the group ID element associated with the target media content file. 13. A user equipment (UE) operable to support media content streaming, the UE having circuitry configured to perform the following operations: The UE receives a first User Service Description (USD) fragment via its Multimedia Broadcast Multicast Service (MBMS) client. The first USD fragment includes group information for one or more files or sessions corresponding to an advertisement and Media Presentation Description (MPD) information associated with the files or sessions. Each file and session in the group information is associated with a group identifier (ID) element contained in the group information. The UE receives a second USD fragment from the Broadcast Multicast Service Center (BMSC) via its MBMS client. The second USD fragment includes MPD information of the streaming media content. A user profile is identified as associated with a user of the UE, wherein the user profile includes a group ID element associated with the user; Select an advertisement that corresponds to a file or session that has a group ID element included in the user profile, wherein the group ID element associated with the user in the user profile is related to the user's viewing habits or demographic information describing the user; The target MPD information of the selected advertisement, which has the group ID element included in the user profile, is inserted into the MPD information of the streaming content to generate a merged MPD. The selected advertisement is received via the MBMS client of the UE according to the merged MPD, and the selected advertisement is stored in the cache at the UE; According to the merged MPD, the streaming content is received from the BMSC via the MBMS client; and Playback is performed at the UE using the selected advertisement and the streaming content stored in the cache at the UE, wherein the advertisement is played between the streaming content. 14. The UE of claim 13, wherein the file or session corresponding to the advertisement comprises a file or session in a dynamically adaptive streaming DASH format based on the Hypertext Transfer Protocol. 15. The UE of claim 13, wherein the playback occurs at the UE's Hypertext Transfer Protocol-based Dynamic Adaptive Streaming (DASH) client. 16. A computer-readable storage medium having instructions stored thereon, the instructions, when executed by one or more processors of a user equipment (UE) including a multimedia broadcast multicast service (MBMS) client operable to receive target media content, causing the UE to: The first metadata is received from the server via MBMS. The first metadata includes group information of one or more files or sessions corresponding to the target media content and media presentation description (MPD) information associated with the files or sessions, wherein each file and session in the group information is associated with a group identifier (ID) element contained in the group information. The second metadata in the User Service Description USD is received via MBMS, wherein the USD includes MPD information of the streaming media content; A user profile is identified as associated with a user of the UE, wherein the user profile includes a group ID element associated with the user; Select target media content corresponding to a file or session that has a group ID element included in the user profile, wherein the group ID element associated with the user in the user profile is related to the user's viewing habits or demographic information describing the user; The target MPD information of the selected target media content, which has the group ID element included in the user profile, is inserted into the MPD information of the streaming media content to generate a merged MPD. According to the merged MPD, the selected target media content is received via the MBMS client and stored in the cache at the UE; The streaming media content is received via the MBMS client according to the merged MPD; and Playback is performed at the UE using the selected target media content and the streaming media content stored in the cache at the UE. 17. A computer-readable storage medium having instructions stored thereon, which, when executed by one or more processors, cause the method according to any one of claims 7-12 to be performed.