HK1242878A1 - Media content streaming - Google Patents

Abstract

Technology for receiving media content is disclosed. Media content segments can be received on a broadcast channel via a multimedia broadcast multicast service (MBMS) client in a user equipment (UE) while the MBMS client is operating in a first streaming mode. The UE can determine that a MBMS decoder buffer level and a broadcast channel condition associated with the broadcast channel do not comply with a defined threshold. The UE can switch from operating in the first streaming mode to a second streaming mode based on the MBMS decoder buffer level and the broadcast channel condition not complying with the defined threshold.

Description

Media content streaming

Background

The growth of multimedia services, including streaming and conversational services, is one of the key drivers for the development of new mobile broadband technologies and standards. In mobile devices, digital video content is being consumed more and more. There are many video applications in daily life that are widely used on mobile devices. For example, online video streams include popular services such as YouTube and Hulu. Video recording and video conferencing include services such as Skype and Google Hangout. In 2011, YouTube has a global view volume of over 1 trillion. Ten percent of these browsing volumes are accessed through mobile phones or tablet computers. As more smart phones, tablet computers, and other mobile computing devices are purchased, the use of video recordings and video conferencing by these devices will grow dramatically. Given that such high consumer demand for multimedia services is coupled with the development of media compression and wireless network architectures, the assumption is of interest that the multimedia service capabilities of future cellular and mobile broadband systems are enhanced and that a high quality of experience (QoE) is provided to the consumer, thereby ensuring that video content and services can be universally applicable accessed from any location, at any time, using any device and technology.

Drawings

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

fig. 1 shows a diagram of a Broadcast Multicast Service Center (BMSC) according to an example;

fig. 2 shows a diagram of a Multimedia Broadcast Multicast Service (MBMS) User Service Description (USD) according to an example;

fig. 3 is a flow diagram illustrating switching of a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) between a broadcast streaming mode and a unicast streaming mode according to an example;

fig. 4 is a flow diagram illustrating a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) switching between a broadcast streaming mode and a unicast streaming mode according to an example;

fig. 5 is a flow diagram illustrating a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) switching between a broadcast streaming mode and a unicast streaming mode according to an example;

fig. 6 is a flow diagram illustrating a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) switching between a broadcast streaming mode and a unicast streaming mode according to an example;

fig. 7 illustrates functionality of circuitry of a User Equipment (UE) including a Multimedia Broadcast Multicast Service (MBMS) client operable to receive media content, according to an example;

fig. 8 illustrates functionality of circuitry of a User Equipment (UE) including a Multimedia Broadcast Multicast Service (MBMS) client operable to receive media content, according to an example;

FIG. 9 shows a flow diagram of a method for receiving multimedia content, according to an example;

fig. 10 shows a diagram of a wireless device (e.g., 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. It will nevertheless be understood that no limitation of the scope of the technology is thereby intended.

Detailed Description

Before the present technology is disclosed and described, it is to be understood that the present technology is not limited to the particular structures, process steps, or materials disclosed herein, but extends to equivalents thereof which may be recognized by those ordinarily skilled in the pertinent art. It is also to be understood that the terminology used herein is for the purpose of describing particular examples only and is not intended to be limiting. Like reference symbols in the various drawings indicate like elements. The numbering provided in the flow diagrams and processes is provided for clarity of illustration of actions and operations and does not necessarily indicate a particular order or sequence.

Example embodiments

An initial overview of technical embodiments is provided below, followed by a more detailed description of specific technical embodiments that follows. This preliminary summary is intended to assist the reader in understanding the present technology more quickly, and is not intended to identify key features or essential features of the present technology, nor is it intended to be limiting as to the scope of the claimed subject matter.

A technique is described for switching between a broadcast streaming mode and a unicast streaming mode, and vice versa, at a Multimedia Broadcast Multicast Service (MBMS) client of a User Equipment (UE). When the MBMS client operates in a broadcast streaming mode, the UE may receive media content segments on a broadcast channel through the MBMS client. The UE may detect when the MBMS decoder buffer level and/or the broadcast channel condition of the broadcast channel do not meet a defined threshold. In other words, the UE may detect when the broadcast channel quality may deteriorate beyond a defined threshold. In addition, the UE may detect when certain media content segments are not properly transmitted to the UE (i.e., media content segments are missing). Thus, the UE may switch from operating in a broadcast streaming mode with the MBMS client to a unicast streaming mode. Switching from a broadcast streaming mode with relatively poor channel conditions to a unicast streaming mode may reduce re-buffering events and improve quality of experience (QoE) for users. The UE may remain in unicast streaming mode until the MBMS decoder buffer level and/or broadcast channel conditions improve. In other words, the UE may switch back to the broadcast streaming mode when the buffer level of the MBMS decoder and/or the broadcast channel condition of the broadcast channel meet defined thresholds. Further, the UE may switch back to the broadcast streaming mode when a previously lost media content segment is transmitted to the UE. Switching back to the broadcast streaming mode within the shortest time period may prevent the network from becoming overloaded with a relatively large number of repeated unicast packets. Accordingly, the MBMS client may switch between operating in the broadcast streaming mode and operating in the unicast streaming mode accordingly to optimize network resources and user experience.

Hypertext transfer protocol (HTTP) adaptive streaming (HAS) may be used as a form of multimedia delivery of internet video. HTTP-based delivery may provide reliability and ease of deployment due to widespread adoption of HTTP and underlying protocols for HTTP, including Transmission Control Protocol (TCP)/Internet Protocol (IP). HTTP-based delivery may allow for simple and easy streaming services by avoiding problems with Network Address Translation (NAT) and firewall traversal. HTTP-based delivery or streaming may also provide the ability to use standard HTTP servers and caches instead of dedicated streaming servers. HTTP-based delivery may provide scalability due to minimal or reduced state information on the server side.

When using HAS to deliver internet multimedia content, a video client operating on a mobile device can be configured to play a major role in rate adaptation by using HTTP GET or partial GET commands to select and request the appropriate video presentation level from a video server to retrieve data from a specified resource (e.g., a multimedia server). A video client establishes a buffer to a certain level before starting playback of streaming media content, such as audio or video. This phase is called the start-up phase. After which the client starts playing back the buffered multimedia content. The quality and resolution of multimedia playback at the client device depends on the available link bandwidth. The video client typically estimates the available link bandwidth based only on higher layer throughput estimates (e.g., video stream throughput at the HTTP layer) or based on Transmission Control Protocol (TCP) throughput.

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

Due to inefficient bandwidth utilization and poor end user quality of experience, it may not be desirable to use progressive download based streaming technology in mobile networks with limited resources. As will be discussed in more detail below, hypertext transfer protocol (HTTP) -based streaming services (e.g., dynamic adaptive streaming over HTTP (dash)) may be used to overcome the weaknesses of progressive download-based streaming.

Multimedia content streamed to a client, such as a User Equipment (UE), may include a plurality of multimedia content segments. These multimedia content segments may each include different encoded versions of multimedia content representing different quality levels. These different encoded versions may allow clients to seamlessly adapt to changing network conditions. For example, when the network conditions are good (i.e., the network conditions are above a predetermined threshold), the client may request a multimedia content segment with higher video quality. When the network conditions are poor (i.e., below a predetermined threshold), the client may request a multimedia content segment with lower video quality. In this way, when the network conditions are poor, the client can still receive the multimedia content segments (despite the poor quality), and the likelihood that the adaptive media stream is interrupted can be reduced.

In DASH, the client may select the multimedia content segments with the highest bit rate so that they can be downloaded at the client in time for media playback without causing a re-buffering event in the media playback. In other words, the client may not select multimedia content segments of that high bitrate, which would cause the adaptive media stream to be periodically interrupted to buffer or pre-load a portion of the media content onto the client before resuming media playback at the client. In one example, adverse network conditions may degrade the quality of the media content stream. Adverse network conditions may include no coverage, sudden bandwidth changes, packet loss, large delay variations, and the like. While adaptive streaming techniques may take into account current network conditions when calculating available throughput and determining an appropriate streaming bit rate based on the available throughput, smooth media playback may not be guaranteed during sudden network changes and/or adverse network conditions.

Thus, to maintain a desired quality of experience for the adaptive media stream at the client, the client's planned route and current network conditions on the planned route may be used to strategically cache multimedia content segments at the client, resulting in smoother media playback and higher quality of experience. The client may select the planned route (i.e., the geographic route the client will be traveling through). The client may stream media content (e.g., a movie) while traveling on the planned route. In one example, the client may comprise a mobile device located within a moving vehicle or a computing device of the vehicle. The client may receive current network conditions for the planned route from a Channel Information Database (CID). The current network conditions may include certain locations (e.g., tunnels, bridges, remote areas) on the planned route having corresponding network conditions below a predetermined threshold. The client may request additional media content segments of the media content (e.g., additional segments of a movie) from the media content server and then store the additional media content segments in the cache. The client may play back the media content stored in the cache when the client reaches those locations on the planned route where the network conditions are below a predetermined threshold. In this way, substantially continuous media playback may be provided at the client even during times when current network conditions on the planned route are below a predetermined threshold.

Wireless multimedia standard

A number of multimedia standards 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. Furthermore, hypertext transfer protocol (HTTP) -based streaming services are described in 3GPP TS 26.247 (e.g., release 11.0.0), including progressive download and dynamic adaptive streaming over HTTP (DASH). The 3 GPP-based Multimedia Broadcast and Multicast Service (MBMS) specification TS26.346 (e.g., release 11.0.0) specifies streaming and downloading techniques for multicast/broadcast content distribution. In this way, a DASH/PSS/MBMS-based mobile computing device, such as a User Equipment (UE), decodes and presents streaming video at the UE device. Support for the 3GP file format in 3GPP TS 26.244 (e.g., release 11.0.0) is required in all of these specifications to support file download and HTTP-based streaming usage scenarios.

One example of a standard for conversational video communication (e.g., video conferencing) is provided in 3GPP TS 26.114 (e.g., 11.0.0). The standard describes an IMS-based Multimedia Telephony Service (MTSI) that allows advanced multimedia session services and content to be delivered over an Internet Protocol (IP) multimedia subsystem (IMS) -based network. IMS is standardized in 3GPP TS26.140 (e.g. release 11.0.0). MTSI-based sender UE terminals may capture and record video and then transmit the video to MTSI-based receiver UE terminals over a 3GPP network. The recipient UE terminal may then decode and present the video. 3GPP TS26.140 also allows video sharing to be implemented using multimedia sharing service (MMS), where support for 3GP file formats is provided.

The above-described standards are provided as examples of wireless multimedia standards that may be used to transfer multimedia files to and/or from multimedia devices. These examples are not intended to be limiting. More standards may be used to provide streaming video, conversational video or video sharing.

Enhanced multimedia broadcast multicast service (eMBMS)

The continued commercialization of LTE networks has made increased interest in the deployment of enhanced multimedia broadcast 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 may be applied to mobile Television (TV) and radio broadcasting, as well as file transfer and emergency alert. Since the first deployment of eMBMS was in 2014, it is important to enhance the performance and availability of core MBMS user service features. The MBMS as specified in 3GPP TS26.346 release 6-12 is a point-to-multipoint system used on a cellular network operating according to one of the cellular standards promulgated by the 3 GPP. MBMS is designed to efficiently deliver popular media content to multiple recipients based on broadcast and multicast techniques. At the service layer, MBMS defines transport protocols for streaming of multimedia content and reliable downloading of files based on the User Datagram Protocol (UDP) of the transport layer, and for streaming using the real-time transport protocol (RTP) and file delivery over unidirectional transport (FLUTE).

The MBMS access client may receive media data and metadata from a server called a Broadcast Multicast Service Center (BMSC) through User Service Discovery (USD) signaling. MBMS has been adopted as an evolved MBMS (embms) mode in the development of the 3 GPP-based Long Term Evolution (LTE) standard corresponding to 3GPP release 8 and later. MBMS download delivery techniques are designed to deliver an arbitrary number of objects to a relatively large population of recipients via MBMS. MBMS downloading defines several techniques to improve reliability, such as FEC and file repair. Download delivery techniques allow for delivery of DASH segmentation and media presentation descriptions.

MBMS download delivery is an attractive service alternative for offloading (offload) HTTP-based unicast download delivery. Advantages include allowing support for new non-real time service types, providing content that supplements MBMS streaming services, and taking advantage of the ever-increasing storage capacity on the device. The DASH segment format, although primarily used for unicast transmission using HTTP, is not clear whether the segment format is unicast or multicast for the delivery environment. The MBMS user service specification TS26.346 indicates the possibility of delivering DASH formatted content using MBMS download transport in conjunction with the FLUTE protocol. FLUTE allows segments to be delivered over MBMS, as defined in RFC3926, so that clients see those segments being delivered over HTTP/TCP. An HTTP-URL is assigned to each transported object in the FLUTE, and the HTTP-URL maps the segment URL in the MPD, i.e. the content-location element in the File Delivery Table (FDT) for the objects transported based on FLUTE matches the segment URL in the MPD. The UE may identify the received DASH representation based on a comparison of the HTTP URL contained in the MPD and the URL information included in the FLUTE packet.

Fig. 1 shows an MBMS-based Broadcast Multicast Service Center (BMSC) sub-functional architecture and associated interfaces between UEs and BMSCs. The BMSC or BM-SC may communicate with and/or control the content provider/multicast broadcast source. The BM-SC may provide MBMS delivery functionality. MBMS is also described in 3GPP TS 26.346.

Fig. 2 shows a diagram of a Multimedia Broadcast and Multicast Service (MBMS) User Service Description (USD). The BM-SC advertises the available MBMS services through one or more instances of a User Service Description (USD) organized as a service package. The MBMS user service is described by metadata (objects/files) transmitted by means of a download transmission method or by means of an interactive announcement function. MBMS user service discovery or announcement involves transmitting fragments of metadata to multiple recipients in an appropriate manner. The metadata itself describes the details of the service. The metadata management information is constituted by a metadata envelope object (in XML format) that allows authentication, version management, update, and time validity management of the metadata fragment object.

As shown in fig. 2, the metadata included in the USD provided to the recipient may include: metadata fragment objects describing details of a single MBMS user service or MBMS user service package, metadata fragment object(s) describing details of an MBMS user service session, metadata fragment object(s) describing details of an associated delivery method, metadata fragment object(s) describing details of service protection, metadata fragment object(s) describing details of an FEC repair data stream, a metadata fragment object(s) providing a media presentation description (for DASH content), a metadata fragment object(s) providing an initialization segment (for DASH content), a metadata fragment object(s) providing a scheduling information description, a metadata fragment object(s) providing filtering data for an MBMS user service within a service package at the level of individual sessions of a given user service or individual file content within a user service.

MBMS may provide efficient delivery of broadcast and multicast services such that network resources (e.g., core network resources or radio network resources) can be shared among a group of users requesting the same media content. MBMS services use streaming technology to provide continuous transmission, such as mobile television services. However, MBMS transmissions differ from point-to-point unicast transmissions in that unicast transmissions include the ability to retransmit data that was not correctly received. For example, for unicast transmissions, automatic repeat request (ARQ) is used to verify that each packet was successfully received at the UE. The UE may send an Acknowledgement (ACK) after each packet is successfully received at the UE. If the packet is not received, the UE may send a Negative ACK (NACK), and the packet may be retransmitted to the UE. Therefore, unicast transmissions are relatively reliable. In contrast, MBMS transmissions generally do not allow for acknowledgement of received packets. Furthermore, MBMS transmissions generally do not support resending packets on demand (i.e., if the packets are not successfully received). Application layer forward error correction (AL-FEC) is used in MBMS to improve the transmission reliability depending on the user channel. However, if the AL-FEC fails to recover the received source chunk or media content segment (which may include several frames), the MBMS client in the UE cannot request retransmission of the last source chunk or media content segment. The MBMS client may not be able to receive the MBMS stream if the channel condition of the MBMS client is relatively poor. Accordingly, as will be described in more detail below, the MBMS client may temporarily switch the broadcast session to the unicast session based on the channel conditions to improve reliability and user satisfaction.

Fig. 3 is an exemplary flow chart illustrating a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) switching between a broadcast streaming mode and a unicast streaming mode. The MBMS client may start operating in a broadcast streaming mode. The MBMS client may receive media content packets over a broadcast channel while operating in a broadcast streaming mode. The MBMS client may detect when the MBMS decoder in the MBMS client fails to operate correctly. In addition, the MBMS client may detect when the MBMS decoder buffer level at the UE falls below a defined threshold (which may result in a buffer event at the MBMS client). In one example, when a broadcast channel condition associated with the broadcast channel deteriorates (e.g., falls below a defined threshold), the MBMS decoder buffer level may fall below the defined threshold. In another example, the MBMS client may detect when a media content segment is not correctly received at the MBMS client or some of the media content segment is missing. In at least one of the above scenarios, the MBMS client may temporarily switch from operating in a broadcast streaming mode to operating in a unicast streaming mode.

The MBMS client may operate in unicast streaming mode until the MBMS decoder buffer level and/or broadcast channel conditions are above a defined threshold. In other words, the MBMS client may continue to operate in unicast streaming mode until the broadcast channel improves to a defined level. In addition, the MBMS client may detect when a previously lost media content segment is received at the MBMS client. At this point, the MBMS client may switch back to the broadcast streaming mode. In other words, during unicast streaming mode, the MBMS client may switch back to broadcast streaming mode when the MBMS decoder buffer level and/or broadcast channel conditions reach a defined threshold. The MBMS client may similarly switch back to the unicast stream mode, as previously described.

By allowing the MBMS client to switch between broadcast streaming mode and unicast streaming mode accordingly based on the network channel conditions, the quality of experience of the client may be improved and the buffering time of the client may be minimized. When the MBMS decoder buffer level and/or broadcast channel conditions are above defined thresholds, the MBMS client generally operates in broadcast streaming mode by default to conserve network resources. Utilization of network resources may be optimized by minimizing the amount of time that the MBMS client operates in unicast streaming mode. However, MBMS clients are allowed to operate in unicast streaming mode for multiple time periods (i.e., based on relatively poor network conditions) to improve broadcast quality and user satisfaction. Although MBMS is described as one example technique that may be used to implement switching techniques between broadcast and unicast, the techniques described herein may be applied to other similar protocols that support broadcast and unicast streaming.

Fig. 4 is an exemplary flow chart illustrating a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) switching between a broadcast streaming mode and a unicast streaming mode. The MBMS client may start operating in a broadcast streaming mode. The MBMS client may receive media content packets over a broadcast channel while operating in a broadcast streaming mode. The MBMS client may determine whether the MBMS decoder buffer level is below a defined threshold. The MBMS client may switch from the broadcast streaming mode to the unicast streaming mode if the MBMS decoder buffer level is below a defined threshold. If the MBMS decoder buffer level is not below the defined threshold, the MBMS client may determine whether the number of lost media content packets (or missing media content packets) is greater than the defined threshold. In other words, the MBMS client may determine whether the number of media content packets that were not successfully transmitted to the MBMS client is greater than a defined threshold. The defined threshold may be a specific number of lost video frames. Alternatively, the defined threshold may be dynamically set based on the size of the last source chunk received at the MBMS client. If the number of lost media content packets is less than the defined threshold, the MBMS client may continue to operate in the broadcast streaming mode. The MBMS client may switch from the broadcast streaming mode to the unicast streaming mode if the number of lost media content packets is greater than a defined threshold.

When operating in unicast streaming mode, video frames from the MBMS decoder buffer and the unicast buffer may be combined in a higher level buffer and then played at the MBMS client. Further, while operating in unicast streaming mode, the MBMS client may determine whether the MBMS decoder buffer level is above a defined threshold. The defined threshold may be a static level or a dynamic level. If the MBMS decoder buffer level is below the defined threshold, the MBMS client may continue to operate in unicast streaming mode. If the MBMS decoder buffer level is above the defined threshold, the MBMS client may determine whether a block error rate (BLER) or a Packet Error Rate (PER) meets the defined threshold. The BLER may indicate a number of erroneous blocks in a defined number of source blocks and the PER may indicate a number of erroneous packets in the defined number of packets. If the BLER and/or PER do not meet the defined threshold, the MBMS client may continue to operate in unicast streaming mode. If the BLER and/or PER meet the defined thresholds, the MBMS client can switch back to the broadcast streaming mode. By observing BLER and PER, the MBMS client can avoid unnecessarily decoding the incoming source blocks when operating in unicast streaming mode. The MBMS client may similarly switch back to unicast stream mode when operating in broadcast mode, as previously described.

In one example, the MBMS client may simply switch to a unicast streaming mode when the broadcast channel conditions are poor, and then switch back to the broadcast streaming mode when the MBMS client receives a previously lost data packet and/or the MBMS buffer is refilled to a defined level of data packets when the broadcast channel conditions improve based on BLER and PER. The MBMS buffer may be refilled to a defined level so that the MBMS client may switch back to the broadcast streaming mode substantially without a possible re-buffering situation. A combination of the above metrics may be used when switching between broadcast streaming mode and unicast streaming mode, and vice versa.

Fig. 5 is an exemplary flow chart illustrating a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) switching between a broadcast streaming mode and a unicast streaming mode. The MBMS client may start operating in a broadcast streaming mode. The MBMS client may receive media content packets over a broadcast channel while operating in a broadcast streaming mode. The MBMS client may determine whether the MBMS decoder failed decoding. If the MBMS decoder does not fail decoding, the backoff flag B may be set to 0 and the MBMS client may continue to operate in the broadcast stream mode. If the MBMS decoder decoding fails, the MBMS client may determine whether the number of consecutive lost source blocks at the MBMS client is greater than a defined integer m. Backoff if the number of consecutive lost source blocks is greater than a defined integer mThe flag B may be set to 1. The back-off time T may be 2T and T_MAXOf where T is_MAXIs a predefined value. When m consecutive source blocks are lost for multiple occurrences, the backoff time T may be set to 2T (as long as 2T is less than T)_MAX) As will be discussed in more detail below. If this is not the case, the back-off time T may be set to T_MAX。

Based on whether the number of consecutive lost source blocks is greater than or less than a defined integer m, the MBMS client may then determine whether the number of lost groups of pictures (GoP) is greater than the defined integer m. The group of pictures may specify the arrangement order of intra frames and inter frames. The group of pictures may be a set of consecutive pictures within the encoded video stream. In one example, the GoP may be lost when the corresponding source block is lost. If the number of lost GoPs is greater than the defined integer m, the MBMS client may switch to unicast streaming mode. If the number of missing GoPs is not greater than the defined integer m, the MBMS client may determine whether the number of frames buffered in the MBMS decoder buffer (f) is less than a defined threshold (f)_MIN). If the number of buffered frames in the MBMS decoder is greater than a defined threshold (f)_MIN) The MBMS client may continue to operate in the broadcast streaming mode. If the number of buffered frames in the MBMS decoder is less than a defined threshold (f)_MIN) The MBMS client may switch to the unicast streaming mode.

In one example, the MBMS client may switch to a unicast streaming mode based on a combination of a weighted source block sliding window and an MBMS decoder buffer level of the MBMS client. A weighted source tile sliding window may monitor the n most recently received source tiles. For example, each source block entry in a time window may be weighted by the number of groups of pictures (gops) contained within the source block. The sliding window may be reset each time the MBMS client switches back to the broadcast streaming mode. The use of a sliding window may reduce handover sensitivity and allow handovers to be performed when actual network conditions change, without performing handovers due to occasional changes that may be misleading. When the number of lost gops is high relative to the source block, the network conditions may be assumed to be unfavorable. Network conditions may be assumed to be favorable when the number of lost gops is low relative to the source block.

The MBMS client may monitor the number of frames (f) in the MBMS decoder buffer. When a source block is lost, the MBMS client may switch to unicast streaming mode if the loss of the source block results in a total of m gops in the sliding window being lost, where m is a defined integer. Furthermore, if the number of frames (f) in the MBMS decoder buffer is less than a certain threshold (f)_MIN) The MBMS client may switch to unicast streaming mode, where f_MINMay be a predefined value or a dynamic value based on the size of the source tile. Thus, the MBMS client may switch to the unicast streaming mode based on the weighted source block sliding window and/or the MBMS decoder buffer level of the MBMS client.

Referring again to fig. 5, the MBMS client may operate in a unicast streaming mode. While in unicast streaming mode, the MBMS client may monitor the number of frames (f) in the MBMS decoder buffer. The number of frames in the MBMS decoder buffer may be related to a defined threshold (f)_MAX) Comparison of where f_MAXIs a defined number of subframes set based on the number of gops in the last received broadcast source block. If the number of frames in the MBMS decoder buffer is greater than a defined threshold, the MBMS client remains in unicast streaming mode. If the number of frames in the MBMS decoder buffer is less than (i.e., not greater than) the defined threshold, the MBMS client may determine whether the backoff flag B is set to 1. As discussed previously, when operating in broadcast streaming mode, the MBMS client may set the backoff flag B to 1 when m consecutive blocks are lost, where m is a defined integer. In other words, the backoff mechanism is enabled during broadcast streaming mode by setting the backoff flag in case m consecutive source blocks are lost. Thus, when operating in unicast mode, the MBMS client may determine whether B is equal to 1. If B is not equal to 1, the MBMS client may switch back to the broadcast streaming mode. If B is 1, the MBMS client may determine to backoffWhether time T has elapsed. As explained before, the back-off time T may be calculated when the MBMS client operates in a broadcast streaming mode. For example, the back-off time may be set to T_MAXWherein T is_MAXIs a predefined value.

Thus, when the MBMS client operates in unicast stream mode, it does not switch back to broadcast stream mode until the back-off time T has passed or expired (even if f > f)_MAX). Assuming buffered unicast subframes exceed f_MAXWhen there is no back-off time (i.e., the back-off time has expired), the MBMS client may switch back to the broadcast streaming mode. If the back-off time T has not expired, the MBMS client may continue to operate in the unicast streaming mode. The backoff time T may be doubled (i.e., 2T) if the MBMS client returns to the broadcast streaming mode and another set of m consecutive source blocks is lost. However, the updated back-off time cannot exceed the maximum back-off time limit T_MAXThe limit value is a predefined value.

Fig. 6 is an exemplary flow chart illustrating a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) switching between a broadcast streaming mode and a unicast streaming mode. The MBMS client may start operating in a broadcast streaming mode. The MBMS client may receive media content packets over a broadcast channel while operating in a broadcast streaming mode. The MBMS client may determine whether the MBMS decoder failed to decode, and if the MBMS decoder did not fail to decode, the MBMS client may continue to operate in the broadcast stream mode. If the MBMS decoder fails decoding, the MBMS client may determine whether the number of missing picture groups (gops) is greater than a defined value m. If the number of missing gops is less than (i.e., not greater than) the defined value m, the MBMS client may determine whether the number of frames (f) in the MBMS decoder buffer is less than the defined threshold. If the number of frames in the MBMS decoder is not less than the defined threshold, the MBMS client may continue to operate in the broadcast streaming mode. The MBMS client may switch to unicast streaming mode if the number of frames in the MBMS decoder is less than a defined threshold and/or the number of missed gops is less than m.

When operating in unicast streaming mode, the MBMS client may determine whether the number of frames in the MBMS decoder buffer (f) is greater than a defined value (f)_MAX) If not, the MBMS client may still operate in unicast streaming mode. If the number of frames in the MBMS decoder buffer is greater than a defined value, the MBMS client may determine whether a block error rate (BLER) and a Packet Error Rate (PER) meet a defined threshold. The BLER may indicate a number of erroneous blocks in a defined number of source blocks and the PER may indicate a number of erroneous packets in the defined number of packets. If the BLER and/or PER do not meet the defined threshold, the MBMS client may continue to operate in unicast streaming mode. If the BLER and/or PER meet the defined thresholds, the MBMS client can switch back to the broadcast streaming mode. Thus, when buffered unicast frames exceed f, assuming PER/BLER is also below the specified value_MAXAt this time, the MBMS client may switch back to the broadcast streaming mode.

By observing BLER and PER, the MBMS client can avoid unnecessarily decoding the incoming source blocks when operating in unicast streaming mode. In other words, the MBMS client may be inactive while operating in unicast streaming mode, thereby saving computational power. In the example shown in fig. 6, a sliding PER/BLER window may be used in unicast streaming mode to monitor the status of the most recent n packets/source blocks in the broadcast channel. The MBMS client may similarly switch back to the unicast streaming mode while operating in the broadcast streaming mode, as previously described. In an alternative configuration, the size n of the sliding PER/BLER window may be based on the number of packets/blocks constituting the last source block received in the broadcast stream mode, rather than a fixed number.

Another example provides functionality 700 of circuitry of a User Equipment (UE) comprising a Multimedia Broadcast Multicast Service (MBMS) client operable to receive media content, as shown in the flow diagram in fig. 7. The functionality may be implemented in a method or the functionality may be executed as instructions on a machine, where the instructions are included on at least one computer readable medium or one non-transitory machine readable storage medium. The circuitry may be configured to receive, by the MBMS client, the media content segment on the broadcast channel when the MBMS client is operating in a unicast streaming mode, as shown in block 710. The circuitry may be configured to detect whether the MBMS decoder buffer level and the broadcast channel condition of the broadcast channel correspond to a defined level, as shown in block 720. The circuitry may be configured to switch from operating in a unicast stream mode to operating in a broadcast stream mode based on the MBMS decoder buffer level and the broadcast channel condition not corresponding to the defined level, as shown in block 730.

In one example, the circuitry may be further configured to receive the media content segment in a broadcast streaming mode with the MBMS client after switching from the unicast streaming mode to the broadcast streaming mode. In another example, the circuitry may be further configured to detect whether the MBMS decoder buffer level is above a defined threshold for a defined period of time, wherein the defined threshold is set according to a number of picture groups (gops) in a last broadcast source block received at the MBMS client.

In one example, the circuitry may be further configured to detect whether a broadcast channel condition of the broadcast channel is below a defined threshold based on a function of a Packet Error Rate (PER) and a block error rate (BLER) relative to the broadcast channel condition, wherein the defined threshold is set as a function of the PER and the BLER relative to a last broadcast source block received at the MBMS client. In another example, the circuitry may be further configured to switch from operating in the unicast streaming mode to operating in the broadcast streaming mode when a previously lost media content segment is received at the MBMS client while operating in the unicast streaming mode. Further, the UE includes an antenna, a touch-sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, internal memory, or a non-volatile memory port.

Another example provides functionality 800 of circuitry of a User Equipment (UE) comprising a Multimedia Broadcast Multicast Service (MBMS) client operable to receive media content, as shown in the flow diagram in fig. 8. The functionality may be implemented in a method or the functionality may be executed as instructions on a machine, where the instructions are included on at least one computer readable medium or one non-transitory machine readable storage medium. The circuitry may be configured to receive, by the MBMS client, the media content segment on the broadcast channel when the MBMS client is operating in a broadcast streaming mode, as shown in block 810. The circuitry may be configured to detect when the MBMS decoder buffer level and the broadcast channel condition of the broadcast channel do not meet a defined threshold, as shown in block 820. The circuitry may be configured to switch from operating in a broadcast streaming mode with the MBMS client to operating in a unicast streaming mode based on the MBMS decoder buffer level and the broadcast channel condition not meeting the defined threshold, as shown in block 830.

In one example, the circuitry may be further configured to: detecting when the MBMS decoder buffer level and broadcast channel conditions meet defined thresholds; and switches from operating in unicast mode back to broadcast streaming mode with the MBMS client. In another example, the circuitry may be further configured to: detecting when an MBMS decoder buffer level is below a defined threshold, wherein the defined threshold is a fixed value or a dynamic value based on the size of a source block received at an MBMS client while operating in a broadcast streaming mode; and switches from operating in a broadcast streaming mode with the MBMS client to operating in a unicast streaming mode.

In one example, the circuitry may be further configured to: determining a broadcast channel condition of a broadcast channel based on a weight of a source block received at the MBMS client within a defined window relative to a number of picture groups (gops) contained within the source block; determining that a weight of the source block relative to a number of GoPs included within the source block does not meet a defined threshold; and switches from operating in a broadcast streaming mode with the MBMS client to operating in a unicast streaming mode.

In one example, the circuitry may be further configured to: determining a broadcast channel condition of a broadcast channel based on a function of a Packet Error Rate (PER) and a block error rate (BLER) relative to the broadcast channel condition; determining that a function of PER and BLER relative to broadcast channel conditions does not meet a defined threshold; and switches from operating in a broadcast streaming mode with the MBMS client to operating in a unicast streaming mode.

In one example, the circuitry may be further configured to: switching from operating in broadcast streaming mode with the MBMS client to operating in unicast streaming mode when a decoder fails at the MBMS client. In another example, the circuitry may be further configured to: switching from operating in a broadcast streaming mode with the MBMS client to operating in a unicast streaming mode when certain segments of the media content are not successfully received in the broadcast streaming mode; and switching from operating in unicast streaming mode to operating in broadcast streaming mode when a previously lost segment of media content is received at the MBMS client while operating in unicast streaming mode.

Another example provides a method 900 for receiving media content, as shown in the flow diagram in fig. 9. The method may be performed as instructions on a machine, where the instructions are included on at least one computer-readable medium or one non-transitory machine-readable storage medium. The method may include an operation for receiving media content segments on a broadcast channel by a Multimedia Broadcast Multicast Service (MBMS) client in a User Equipment (UE) when the MBMS client operates in a first streaming mode, as shown in block 910. The method may include the operation of determining, at the UE, that an MBMS decoder buffer level associated with the broadcast channel and the broadcast channel condition do not meet a defined threshold, as shown in block 920. The method may include switching from operating in the first streaming mode to operating in the second streaming mode based on the MBMS decoder buffer level and the broadcast channel condition not meeting the defined threshold, as shown in block 930.

In one example, the method may include the operation of receiving a media content segment in a second streaming mode for a defined duration. In another example, the first streaming mode is a broadcast streaming mode and the second streaming mode is a unicast streaming mode. In another example, the first streaming mode is a unicast streaming mode and the second streaming mode is a broadcast streaming mode.

In one example, the method may include switching from operating in a first streaming mode to operating in a second streaming mode based on a weight of a source block received at the MBMS client within a defined window relative to a number of picture groups (gops) contained within the source block. In another example, the method can include switching from operating in the first streaming mode to operating in the second streaming mode based on a function of a Packet Error Rate (PER) and a block error rate (BLER) relative to broadcast channel conditions. In another example, the method may include switching from operating in the first streaming mode to operating in the second streaming mode when a media content segment is lost or when a media content segment is recovered.

Fig. 10 provides an example illustration of a wireless device, such as a User Equipment (UE), Mobile Station (MS), mobile wireless device, mobile communication device, tablet computer, handheld computer, or other type of wireless device. The wireless device may include one or more antennas configured to communicate with a node or transmission station, such as a Base Station (BS), evolved node b (enb), baseband unit (BBU), Radio Remote Head (RRH), Remote Radio Equipment (RRE), Relay Station (RS), Radio Equipment (RE), Remote Radio Unit (RRU), 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. Wireless devices may communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The wireless devices may communicate within a Wireless Local Area Network (WLAN), a Wireless Personal Area Network (WPAN), and/or a WWAN.

Fig. 10 also provides an illustration of a microphone and one or more speakers that may be used for audio input and output of the wireless device. The display screen may be a Liquid Crystal Display (LCD) screen or other type of display screen such as an Organic Light Emitting Diode (OLED) display. The display screen may be configured as a touch screen. The touch screen may be capacitive, resistive or another type of touch screen technology. The application processor and the graphics processor may be coupled to internal memory to provide processing and display capabilities. The non-volatile memory port may also be used to provide data input/output options to a user. A non-volatile memory port may also be used to extend the memory capabilities of the wireless device. The keyboard may be integrated with or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard may also be provided using a touch screen.

Various techniques, or certain aspects or portions of these techniques, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, compact disk-read only memories (CD-ROMs), hard drives, non-transitory computer-readable storage media, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. The circuitry may include hardware, firmware, program code, executable code, computer instructions, and/or software. The non-transitory computer readable storage medium may be a computer readable storage medium that does not include a signal. In the case of program code execution on programmable computers, 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), flash memory, optical drives, magnetic hard drives, solid state drives, or other media for storing electronic data. The nodes and wireless devices may also include a transceiver module (i.e., transceiver), a counter module (i.e., counter), a processing module (i.e., processor), and/or a clock module (i.e., clock) or timer module (i.e., timer). One or more programs that may implement or utilize the various techniques described herein may use an Application Programming Interface (API), reusable controls, or the like. These programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

It should be appreciated that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom Very Large Scale Integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

In one example, a plurality of hardware circuits may be used to implement the functional units described in this specification. For example, a first hardware circuit may be used to perform processing operations and a second hardware circuit (e.g., a transceiver) may be used to communicate with other entities. The first hardware circuit and the second hardware circuit may be integrated into a single hardware circuit, or the first hardware circuit and the second hardware circuit may be separate hardware circuits.

Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

Indeed, a module of executable code may be a single instruction, or many instructions, and may be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified or illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The modules may be active or passive and include agents operable to perform desired functions.

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

As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate unique member. Thus, no member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group. Furthermore, various embodiments and examples of the present technology may be referred to herein along with their various component alternatives. It should be understood that such embodiments, examples, or alternatives are not to be construed as actual equivalents of each other, but are to be considered as separate autonomous manifestations of the present technology.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of embodiments of the present technology. One skilled in the relevant art will recognize, however, that the technology of the present application can be practiced without one or more of the specific details, or with other methods, components, arrangements, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the technology.

While the foregoing illustrates the principles of the present technology in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the technology of the present application. Accordingly, the techniques of this application are not intended to be limited, except as by the appended claims.

Claims (20)

1. A User Equipment (UE) including a Multimedia Broadcast Multicast Service (MBMS) client operable to receive media content, the UE comprising:

a first circuit configured to:

receiving, by the MBMS client, a media content segment on a broadcast channel when the MBMS client is operating in a unicast streaming mode; and

a second circuit configured to:

detecting that an MBMS decoder buffer level and a broadcast channel condition of the broadcast channel correspond to a defined level; and is

Switch from operating in the unicast stream mode to operating in a broadcast stream mode based on the MBMS decoder buffer level and the broadcast channel condition not corresponding to the defined threshold.

2. The UE of claim 1, wherein the first circuitry is further configured to: receiving the media content segment with the MBMS client in the broadcast streaming mode after switching from the unicast streaming mode to the broadcast streaming mode.

3. The UE of claim 1, wherein the second circuitry is further configured to: detecting that the MBMS decoder buffer level exceeds a defined threshold for a defined period of time, wherein the defined threshold is set according to a number of picture groups (GoPs) within a last broadcast source block received at an MBMS client.

4. The UE of claim 1, wherein the second circuitry is further configured to: detecting that a broadcast channel condition of the broadcast channel is below a defined threshold based on a function of a Packet Error Rate (PER) and a block error rate (BLER) relative to the broadcast channel condition, wherein the defined threshold is set as a function of the PER and the BLER relative to a last broadcast source block received at the MBMS client.

5. The UE of claim 1, wherein the second circuitry is further configured to: switching from operating in the unicast streaming mode to operating in the broadcast streaming mode when a previously lost media content segment is received at the MBMS client while operating in the unicast streaming mode.

6. The UE of claim 1, wherein the UE comprises an antenna, a touch sensitive display screen, a speaker, a microphone, a graphics processor, an application processor, internal memory, or a non-volatile memory port.

7. A User Equipment (UE) including a Multimedia Broadcast Multicast Service (MBMS) client operable to receive media content, the UE comprising:

a first circuit configured to:

receiving, by the MBMS client, a media content segment on a broadcast channel when the MBMS client is operating in a broadcast streaming mode; and

a second circuit configured to:

detecting when an MBMS decoder buffer level and a broadcast channel condition of the broadcast channel do not meet a defined threshold; and is

Switching the MBMS client from operating in the broadcast stream mode to operating in a unicast stream mode based on the MBMS decoder buffer level and the broadcast channel condition not meeting the defined threshold.

8. The UE of claim 7, wherein the second circuitry is further configured to:

detecting when the MBMS decoder buffer level and the broadcast channel condition meet the defined thresholds; and is

Switching the MBMS client from operating in the unicast stream mode back to operating in the broadcast stream mode.

9. The UE of claim 7, wherein the second circuitry is further configured to:

detecting when the MBMS decoder buffer level is below the defined threshold, wherein the defined threshold is a fixed value or a dynamic value based on the size of source blocks received at the MBMS client while operating in the broadcast streaming mode; and is

Switching the MBMS client from operating in the broadcast stream mode to operating in the unicast stream mode.

10. The UE of claim 7, wherein the second circuitry is further configured to:

determining a broadcast channel condition of the broadcast channel based on a weight of source blocks received at the MBMS client within a defined window relative to a number of picture groups (GoPs) contained within the source blocks;

determining that a weight of the source block relative to a number of GoPs included within the source block does not meet the defined threshold; and is

Switching the MBMS client from operating in the broadcast stream mode to operating in the unicast stream mode.

11. The UE of claim 7, wherein the second circuitry is further configured to:

determining a broadcast channel condition of the broadcast channel based on a function of a Packet Error Rate (PER) and a block error rate (BLER) relative to the broadcast channel condition;

determining that a function of the PER and the BLER relative to the broadcast channel conditions does not meet the defined threshold; and is

Switching the MBMS client from operating in the broadcast stream mode to operating in the unicast stream mode.

12. The UE of claim 7, wherein the second circuitry is further configured to:

switching the MBMS client from operating in the broadcast stream mode to operating in the unicast stream mode when a decoder fails at the MBMS client.

13. The UE of claim 7, wherein the second circuitry is further configured to:

switching the MBMS client from operating in the broadcast streaming mode to operating in the unicast streaming mode when certain segments of media content are not successfully received in the broadcast streaming mode; and is

Switching from operating in the unicast streaming mode to operating in the broadcast streaming mode when a previously lost media content segment is received at the MBMS client while operating in the unicast streaming mode.

14. A method for receiving media content, comprising:

receiving, using one or more processors of a User Equipment (UE), a media content segment on a broadcast channel by a Multimedia Broadcast Multicast Service (MBMS) client within the UE when the MBMS client operates in a first streaming mode;

determining, at the UE, that an MBMS decoder buffer level and a broadcast channel condition associated with the broadcast channel do not meet a defined threshold using one or more processors of the UE; and is

Switching, using one or more processors of the UE, from operating in the first streaming mode to operating in a second streaming mode based on the MBMS decoder buffer level and the broadcast channel condition not meeting the defined threshold.

15. The method of claim 14, further comprising receiving the media content segment in the second streaming mode for a defined duration.

16. The method of claim 14, wherein the first streaming mode is a broadcast streaming mode and the second streaming mode is a unicast streaming mode.

17. The method of claim 14, wherein the first streaming mode is a unicast streaming mode and the second streaming mode is a broadcast streaming mode.

18. The method of claim 14, further comprising: switching from operating in the first streaming mode to operating in the second streaming mode based on a weight of source blocks received at the MBMS client within a defined window relative to a number of groups of pictures (GoPs) contained within the source blocks.

19. The method of claim 14, further comprising: switching from operating in the first streaming mode to operating in the second streaming mode based on a function of a Packet Error Rate (PER) and a block error rate (BLER) relative to the broadcast channel conditions.

20. The method of claim 14, further comprising: switching from operating in the first streaming mode to operating in the second streaming mode when the media content segment is lost or when the lost media content segment is recovered.