Quality of service control in a multicast transmission

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority pursuant to 35 U.S.C. §119(e) to U.S. provisional application Ser. No. 61/477,560 filed Apr. 20, 2011, which application is hereby incorporated by reference, in its entirety.

FIELD

Aspects of the present disclosure relate generally to wireless communication systems, and more particularly, to controlling Quality of Service (QoS) of Multimedia Broadcast Multicast Service (MBMS) in a wireless communications network or similar multicast broadcast modes in other multicast formats.

BACKGROUND

Wireless communication networks are widely deployed to provide various communication services such as, for example, voice, video, packet data, messaging, or broadcast. These wireless networks may be multiple-access networks capable of supporting multiple users by sharing the available network resources. Examples of such multiple-access networks include Code Division Multiple Access (CDMA) networks, Time Division Multiple Access (TDMA) networks, Frequency Division Multiple Access (FDMA) networks, Orthogonal FDMA (OFDMA) networks, and Single-Carrier FDMA (SC-FDMA) networks.

A wireless communication network may include a number of base stations that can support communication for a number of user equipments (UEs), also referred to as mobile devices or mobile entities. A UE may communicate with a base station via a downlink and an uplink. The downlink (or forward link) refers to the communication link from the base station to the UE, and the uplink (or reverse link) refers to the communication link from the UE to the base station. As used herein, a “base station” means an eNode B (eNB), a Node B, a Home Node B, or similar network component of a wireless communications system.

The 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) represents a major advance in cellular technology as an evolution of Global System for Mobile communications (GSM) and Universal Mobile Telecommunications System (UMTS). The LTE physical layer (PHY) provides a highly efficient way to convey both data and control information between base stations, such as an evolved Node Bs (eNBs), and mobile devices, such as UEs. In prior applications, a method for facilitating high bandwidth communication for multimedia has been single frequency network (SFN) operation. SFNs utilize radio transmitters, such as, for example, eNBs, to communicate with subscriber UEs. In unicast operation, each eNB is controlled so as to transmit signals carrying information directed to one or more particular subscriber UEs. The specificity of unicast signaling enables person-to-person services such as, for example, voice calling, text messaging, or video calling.

In multicast broadcast operation, several eNBs in an area broadcast signals in a synchronized fashion, carrying information that can be received and accessed by any subscriber UE in the broadcast area. The generality of multicast broadcast operation enables greater efficiency in transmitting information of general public interest, for example, event-related multimedia broadcasts. As the demand and system capability for event-related multimedia and other multicast broadcast services has increased, system operators have shown increasing interest in making use of multicast broadcast operation in 3GPP and 3GPP2 networks. In the past, 3GPP LTE technology has been primarily used for unicast service, leaving opportunities for improvements and enhancements related to multicast broadcast signaling. Analogous multicast operations may also be implemented in wireless communications outside of the 3GPP or 3GPP2 context.

SUMMARY

Methods, apparatus and systems for managing QoS of a multicast broadcast in a wireless communication system are described in detail in the detailed description, and certain aspects are summarized below. This summary and the following detailed description should be interpreted as complementary parts of an integrated disclosure, which parts may include redundant subject matter and/or supplemental subject matter. An omission in either section does not indicate priority or relative importance of any element described in the integrated application. Differences between the sections may include supplemental disclosures of alternative embodiments, additional details, or alternative descriptions of identical embodiments using different terminology, as should be apparent from the respective disclosures.

In an aspect, a method for dynamically controlling QoS for a multicast transmission from a network entity of a wireless communications system (WCS) may include initiating a multicast transmission having an initial QoS, and generating an updated QoS for the multicast transmission, in response to a network load factor for a multicast area, prior to termination of the multicast transmission. The method may include updating the multicast transmission using the updated QoS. The updated QoS may replace an initial QoS prior to the termination of the multicast transmission. In an aspect, the network entity may be, or may include, a Broadcast-Multicast Service Center (BM-SC).

In related aspects, the method may include indicating the updated QoS to a mobile entity receiving the multicast transmission. In an aspect, the network entity does not receive feedback from the mobile entity. Indicating the updated QoS may include providing parameters for streaming a media component to the mobile entity, and specifying, in an announcement, new ones of the parameters taking effect at a specified frame boundary or time. In addition, the method may include transmitting the announcement according to at least one of: a Session Description Protocol (SDP), a modified SDP, a File Description Table (FDT), or a modified FDT. In some embodiments, the method may include indicating the updated QoS by at least one of: sending the parameters in a corresponding control stream, or including the parameters in headers of a stream transport protocol for the multicast transmission. The stream transport protocol may be, or may include, an HTTP push protocol.

In other aspects, the method may include communicating with an intermediate node within the WCS to obtain at least one of: feedback indicative of the network load factor, an updated QoS, or one or more additional factors not limited to QOS or network load factors for use in controlling the QoS. The method may further include receiving the network load factor, wherein the network load factor indicates an available bandwidth for the multicast transmission in the multicast area. The method may further include receiving the network load factor from a Multicast Coordinating Entity (MCE) via at least one of a message over a direct interface, a message relayed through several interfaces, or an Operations & Maintenance based indication. In the alternative, or in addition, the method may include receiving the network load factor from an eNode B (eNB) via at least one of a message over a direct interface, a message relayed through several interfaces, or an Operations & Maintenance based indication.

In other aspects for implementation at a mobile entity, a method for using a multicast transmission having a dynamically controlled QoS, using a mobile device, may include receiving a content via a multicast transmission in a wireless communications system, receiving a updated QoS during the multicast transmission, and processing a subsequent portion of the content according to the updated QoS. The method may further include receiving the updated QoS by receiving at least one parameter for processing a media stream of the content. Receiving the parameters may include receiving a corresponding control stream containing the parameters for the media stream. In the alternative, or in addition, receiving the parameters may include receiving announcements each comprising new ones of the parameters for taking effect at one or more specified frame boundaries or times of the media stream. The method may further include receiving ones of the announcements according to at least one of a Session Description Protocol (SDP), or a modified File Description Table (FDT). In another alternative, receiving the parameters may include receiving the parameters in headers of a stream transport protocol for the multicast transmission. The stream transport protocol may be, or may include an HTTP push protocol.

In other aspects for implementations at a network entity, a method for determining dynamic bandwidth availability from a network entity of a WCS for use in controlling QoS of a multicast transmission may include receiving dynamic measures of currently available bandwidth from base stations receiving content for a multicast transmission in a multicast area of the WCS, determining an aggregate available bandwidth for the multicast transmission in the multicast area, during the multicast transmission, and indicating the aggregate available bandwidth for use in controlling a QoS of the multicast transmission. In an aspect of the method, indicating the aggregate available bandwidth may include at least one of: transmitting an indication of the aggregate available bandwidth to an upstream network entity, or providing an indication of the currently available bandwidth to the upstream network entity using an Operations & Maintenance based indication. The method may further include at least one of: transmitting the indication via a message over a direct interface to the upstream network entity, or transmitting the indication via a message relayed through several interfaces to the upstream network entity. In an aspect, the network entity determining the aggregate available bandwidth may be, or may include, a Multicast Coordinating Entity (MCE).

In related aspects, a wireless communications apparatus may be provided for performing any of the methods and aspects of the methods summarized above. An apparatus may include, for example, a processor coupled to a memory, wherein the memory holds instructions for execution by the processor to cause the apparatus to perform operations as described above. Certain aspects of such apparatus (e.g., hardware aspects) may be exemplified by equipment such as mobile entities or base stations of various types used for wireless communications. Similarly, an article of manufacture may be provided, including a computer-readable storage medium holding encoded instructions, which when executed by a processor, cause a wireless communications apparatus to perform the methods and aspects of the methods as summarized above.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram conceptually illustrating an example of a telecommunications system.

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram conceptually illustrating an example of a down link frame structure in a telecommunications system.

<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram conceptually illustrating a design of a base station/eNB and a UE configured according to one aspect of the present disclosure.

<figref idref="DRAWINGS">FIG. 4</figref> is a diagram of a signaling frame illustrating an example of symbol allocation for unicast and multicast signals.

<figref idref="DRAWINGS">FIG. 5</figref> is a diagram illustrating MBMS over a Single Frequency Network (MBSFN) areas within an MBSFN service area.

<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram illustrating components of a wireless communication system for providing or supporting MBSFN service.

<figref idref="DRAWINGS">FIG. 7</figref> illustrates an embodiment of a network-level call flow for QoS control in a multicast transmission of a wireless communications system.

<figref idref="DRAWINGS">FIGS. 8A-F</figref> illustrate embodiments of a methodology for QoS control in a multicast transmission by a network entity providing multicast broadcast services.

<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example of an apparatus for implementing the methodologies of <figref idref="DRAWINGS">FIGS. 8A-F</figref>.

<figref idref="DRAWINGS">FIGS. 10A-B</figref> illustrate embodiments of a methodology for using a multicast transmission configured for dynamic QoS control at a mobile device.

<figref idref="DRAWINGS">FIG. 11</figref> illustrates an example of an apparatus for implementing the methodologies of <figref idref="DRAWINGS">FIGS. 10A-B</figref>.

<figref idref="DRAWINGS">FIGS. 12A-C</figref> illustrate embodiments of a methodology for providing network load factors used for dynamic QoS control at a base station.

<figref idref="DRAWINGS">FIG. 13</figref> illustrates an example of an apparatus for implementing the methodologies of <figref idref="DRAWINGS">FIGS. 12A-C</figref>.

<figref idref="DRAWINGS">FIGS. 14A-B</figref> illustrate embodiments of a methodology for aggregating bandwidth availability measures used for dynamic QoS control in a multicast area, at an intermediate network entity.

<figref idref="DRAWINGS">FIG. 15</figref> illustrates an example of an apparatus for implementing the methodologies of <figref idref="DRAWINGS">FIGS. 14A-B</figref>.

DETAILED DESCRIPTION

The detailed description set forth below, in connection with the appended drawings, is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

The techniques described herein may be used for various wireless communication networks such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA and other networks. The terms “network” and “system” are often used interchangeably. A CDMA network may implement a radio technology such as, for example, Universal Terrestrial Radio Access (UTRA), or CDMA2000. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. CDMA2000 covers IS-2000, IS-95 and IS-856 standards. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS that use E-UTRA. UTRA, E-UTRA, UMTS, LTE, LTE-A and GSM are described in documents from an organization named “3rd Generation Partnership Project” (3GPP). CDMA2000 and UMB are described in documents from an organization named “3rd Generation Partnership Project 2” (3GPP2). The techniques described herein may be used for the wireless networks and radio technologies mentioned above as well as other wireless networks and radio technologies. For clarity, certain aspects of the techniques are described below for LTE, and LTE terminology is used in much of the description below.

<figref idref="DRAWINGS">FIG. 1</figref> shows a wireless communication network <b>100</b>, which may be an LTE network. The wireless network <b>100</b> may include a number of eNBs <b>110</b> and other network entities. An eNB may be a station that communicates with the UEs and may also be referred to as a base station, a Node B, an access point, or other term. Each eNB <b>110</b><i>a</i>, <b>110</b><i>b</i>, <b>110</b><i>c </i>may provide communication coverage for a particular geographic area. In 3GPP, the term “cell” can refer to a coverage area of an eNB and/or an eNB subsystem serving this coverage area, depending on the context in which the term is used.

An eNB may provide communication coverage for a macro cell, a pico cell, a femto cell, and/or other types of cell. A macro cell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by UEs with service subscription. A pico cell may cover a relatively small geographic area and may allow unrestricted access by UEs with service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow restricted access by UEs having association with the femto cell (e.g., UEs in a Closed Subscriber Group (CSG), or UEs for users in the home). An eNB for a macro cell may be referred to as a macro eNB. An eNB for a pico cell may be referred to as a pico eNB. An eNB for a femto cell may be referred to as a femto eNB or a home eNB (HNB). In the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, the eNBs <b>110</b><i>a</i>, <b>110</b><i>b </i>and <b>110</b><i>c </i>may be macro eNBs for the macro cells <b>102</b><i>a</i>, <b>102</b><i>b </i>and <b>102</b><i>c</i>, respectively. The eNB <b>110</b><i>x </i>may be a pico eNB for a pico cell <b>102</b><i>x</i>, serving a UE <b>120</b><i>x</i>. The eNBs <b>110</b><i>y </i>and <b>110</b><i>z </i>may be femto eNBs for the femto cells <b>102</b><i>y </i>and <b>102</b><i>z</i>, respectively. An eNB may support one or multiple (e.g., three) cells.

The wireless network <b>100</b> may also include relay stations <b>110</b><i>r</i>. A relay station is a station that receives a transmission of data and/or other information from an upstream station (e.g., an eNB or a UE) and sends a transmission of the data and/or other information to a downstream station (e.g., a UE or an eNB). A relay station may also be a UE that relays transmissions for other UEs. In the example shown in <figref idref="DRAWINGS">FIG. 1</figref>, a relay station <b>110</b><i>r </i>may communicate with the eNB <b>110</b><i>a </i>and a UE <b>120</b><i>r </i>in order to facilitate communication between the eNB <b>110</b><i>a </i>and the UE <b>120</b><i>r</i>. A relay station may also be referred to as a relay eNB or a relay.

The wireless network <b>100</b> may be a heterogeneous network that includes eNBs of different types, e.g., macro eNBs, pico eNBs, femto eNBs, relays, etc. These different types of eNBs may have different transmit power levels, different coverage areas, and different impact on interference in the wireless network <b>100</b>. For example, macro eNBs may have a high transmit power level (e.g., 20 Watts) whereas pico eNBs, femto eNBs and relays may have a lower transmit power level (e.g., 1 Watt).

The wireless network <b>100</b> may support synchronous or asynchronous operation. Multicast broadcast operations may require synchronization of base stations within a defined area, but the present technology is not limited thereby. For synchronous operation, the eNBs may have similar frame timing, and transmissions from different eNBs may be approximately aligned in time. For asynchronous operation, the eNBs may have different frame timing, and transmissions from different eNBs may not be aligned in time. The techniques described herein may be used for both synchronous and asynchronous operation.

A network controller <b>130</b> may couple to a set of eNBs and provide coordination and control for these eNBs. The network controller <b>130</b> may communicate with the eNBs <b>110</b> via a backhaul. The eNBs <b>110</b> may also communicate with one another, e.g., directly or indirectly via wireless or wireline backhaul.

The UEs <b>120</b> may be dispersed throughout the wireless network <b>100</b>, and each UE may be stationary or mobile. A UE may also be referred to as a terminal, a mobile station, a mobile entity, a subscriber unit, a station, or other name. A UE may be a cellular phone, a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, or other mobile devices. A UE may be able to communicate with macro eNBs, pico eNBs, femto eNBs, relays, or other network entities. In <figref idref="DRAWINGS">FIG. 1</figref>, a solid line with double arrows indicates desired transmissions between a UE and a serving eNB, which is an eNB designated to serve the UE on the downlink and/or uplink. A dashed line with double arrows indicates interfering transmissions between a UE and an eNB.

LTE utilizes orthogonal frequency division multiplexing (OFDM) on the downlink and single-carrier frequency division multiplexing (SC-FDM) on the uplink. OFDM and SC-FDM partition the system bandwidth into multiple (K) orthogonal subcarriers, which are also commonly referred to as tones or bins. Each subcarrier may be modulated with data. In general, modulation symbols are sent in the frequency domain with OFDM and in the time domain with SC-FDM. The spacing between adjacent subcarriers may be fixed, and the total number of subcarriers (K) may be dependent on the system bandwidth. For example, K may be equal to 128, 256, 512, 1024 or 2048 for system bandwidth of 1.25, 2.5, 5, 10 or 20 megahertz (MHz), respectively. The system bandwidth may also be partitioned into subbands. For example, a subband may cover 1.08 MHz, and there may be 1, 2, 4, 8 or 16 subbands for system bandwidth of 1.25, 2.5, 5, 10 or 20 MHz, respectively.

<figref idref="DRAWINGS">FIG. 2</figref> shows a down link frame structure <b>200</b> used in LTE. The transmission timeline for the downlink may be partitioned into units of radio frames <b>202</b>, <b>204</b>, <b>206</b>. Each radio frame may have a predetermined duration (e.g., 10 milliseconds (ms)) and may be partitioned into ten subframes <b>208</b> with indices of 0 through 9. Each subframe may include two slots, e.g., slots <b>210</b>. Each radio frame may thus include twenty slots with indices of 0 through 19. Each slot may include L symbol periods, e.g., seven symbol periods <b>212</b> for a normal cyclic prefix (CP), as shown in <figref idref="DRAWINGS">FIG. 2</figref>, or six symbol periods for an extended cyclic prefix. The normal CP and extended CP may be referred to herein as different CP types. The 2L symbol periods in each subframe may be assigned indices of 0 through 2L−1. The available time frequency resources may be partitioned into resource blocks. Each resource block may cover N subcarriers (e.g., 12 subcarriers) in one slot.

In LTE, an eNB may send a primary synchronization signal (PSS) and a secondary synchronization signal (SSS) for each cell in the eNB. The primary and secondary synchronization signals may be sent in symbol periods <b>6</b> and <b>5</b>, respectively, in each of subframes <b>0</b> and <b>5</b> of each radio frame with the normal cyclic prefix, as shown in <figref idref="DRAWINGS">FIG. 2</figref>. The synchronization signals may be used by UEs for cell detection and acquisition. The eNB may send a Physical Broadcast Channel (PBCH) in symbol periods <b>0</b> to <b>3</b> in slot <b>1</b> of subframe <b>0</b>. The PBCH may carry certain system information.

The eNB may send a Physical Control Format Indicator Channel (PCFICH) in only a portion of the first symbol period of each subframe, although depicted in the entire first symbol period in <figref idref="DRAWINGS">FIG. 2</figref>. The PCFICH may convey the number of symbol periods (M) used for control channels, where M may be equal to 1, 2 or 3 and may change from subframe to subframe. The number of symbol periods M may also be equal to 4 for a small system bandwidth, e.g., with less than 10 resource blocks. In the example shown in <figref idref="DRAWINGS">FIG. 2</figref>, M=3. The eNB may send a Physical HARQ Indicator Channel (PHICH) and a Physical Downlink Control Channel (PDCCH) in the first M symbol periods of each subframe (M=3 in <figref idref="DRAWINGS">FIG. 2</figref>). The PHICH may carry information to support hybrid automatic retransmission (HARQ). The PDCCH may carry information on resource allocation for UEs and control information for downlink channels. Although not shown in the first symbol period in <figref idref="DRAWINGS">FIG. 2</figref>, it is understood that the PDCCH and PHICH are also included in the first symbol period. Similarly, the PHICH and PDCCH are also both in the second and third symbol periods, although not shown that way in <figref idref="DRAWINGS">FIG. 2</figref>. The eNB may send a Physical Downlink Shared Channel (PDSCH) in the remaining symbol periods of each subframe. The PDSCH may carry data for UEs scheduled for data transmission on the downlink. The various signals and channels in LTE are described in 3GPP TS 36.211, entitled “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation,” which is publicly available.

The eNB may send the PSS, SSS and PBCH in the center 1.08 MHz of the system bandwidth used by the eNB. The eNB may send the PCFICH and PHICH across the entire system bandwidth in each symbol period in which these channels are sent. The eNB may send the PDCCH to groups of UEs in certain portions of the system bandwidth. The eNB may send the PDSCH to specific UEs in specific portions of the system bandwidth. The eNB may send the PSS, SSS, PBCH, PCFICH and PHICH in a broadcast manner to all UEs, may send the PDCCH in a unicast manner to specific UEs, and may also send the PDSCH in a unicast manner to specific UEs.

A number of resource elements may be available in each symbol period. Each resource element may cover one subcarrier in one symbol period and may be used to send one modulation symbol, which may be a real or complex value. Resource elements not used for a reference signal in each symbol period may be arranged into resource element groups (REGs). Each REG may include four resource elements in one symbol period. The PCFICH may occupy four REGs, which may be spaced approximately equally across frequency, in symbol period <b>0</b>. The PHICH may occupy three REGs, which may be spread across frequency, in one or more configurable symbol periods. For example, the three REGs for the PHICH may all belong in symbol period <b>0</b> or may be spread in symbol periods <b>0</b>, <b>1</b> and <b>2</b>. The PDCCH may occupy 9, 18, 32 or 64 REGs, which may be selected from the available REGs, in the first M symbol periods. Only certain combinations of REGs may be allowed for the PDCCH.

A UE may know the specific REGs used for the PHICH and the PCFICH. The UE may search different combinations of REGs for the PDCCH. The number of combinations to search is typically less than the number of allowed combinations for the PDCCH. An eNB may send the PDCCH to the UE in any of the combinations that the UE will search.

A UE may be within the coverage of multiple eNBs. One of these eNBs may be selected to serve the UE. The serving eNB may be selected based on various criteria such as, for example, received power, path loss, signal-to-noise ratio (SNR.

<figref idref="DRAWINGS">FIG. 3</figref> shows a block diagram of a design of a base station/eNB <b>110</b> and a UE <b>120</b>, which may be one of the base stations/eNBs and one of the UEs in <figref idref="DRAWINGS">FIG. 1</figref>. For a restricted association scenario, the base station <b>110</b> may be the macro eNB <b>110</b><i>c </i>in <figref idref="DRAWINGS">FIG. 1</figref>, and the UE <b>120</b> may be the UE <b>120</b><i>y</i>. The base station <b>110</b> may also be a base station of some other type. The base station <b>110</b> may be equipped with antennas <b>334</b><i>a </i>through <b>334</b><i>t</i>, and the UE <b>120</b> may be equipped with antennas <b>352</b><i>a </i>through <b>352</b><i>r. </i>

At the base station <b>110</b>, a transmit processor <b>320</b> may receive data from a data source <b>312</b> and control information from a controller/processor <b>340</b>. The control information may be for the PBCH, PCFICH, PHICH, PDCCH, or other control channel. The data may be for the PDSCH or other data channel. The processor <b>320</b> may process (e.g., encode and symbol map) the data and control information to obtain data symbols and control symbols, respectively. The processor <b>320</b> may also generate reference symbols, e.g., for the PSS, SSS, and cell-specific reference signal. A transmit (TX) multiple-input multiple-output (MIMO) processor <b>330</b> may perform spatial processing (e.g., precoding) on the data symbols, the control symbols, and/or the reference symbols, if applicable, and may provide output symbol streams to the modulators (MODs) <b>332</b><i>a </i>through <b>332</b><i>t</i>. Each modulator <b>332</b> may process a respective output symbol stream (e.g., for OFDM) to obtain an output sample stream. Each modulator <b>332</b> may further process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. Downlink signals from modulators <b>332</b><i>a </i>through <b>332</b><i>t </i>may be transmitted via the antennas <b>334</b><i>a </i>through <b>334</b><i>t</i>, respectively.

At the UE <b>120</b>, the antennas <b>352</b><i>a </i>through <b>352</b><i>r </i>may receive the downlink signals from the base station <b>110</b> and may provide received signals to the demodulators (DEMODs) <b>354</b><i>a </i>through <b>354</b><i>r</i>, respectively. Each demodulator <b>354</b> may condition (e.g., filter, amplify, downconvert, and digitize) a respective received signal to obtain input samples. Each demodulator <b>354</b> may further process the input samples (e.g., for OFDM) to obtain received symbols. A MIMO detector <b>356</b> may obtain received symbols from all the demodulators <b>354</b><i>a </i>through <b>354</b><i>r</i>, perform MIMO detection on the received symbols if applicable, and provide detected symbols. A receive processor <b>358</b> may process (e.g., demodulate, deinterleave, and decode) the detected symbols, provide decoded data for the UE <b>120</b> to a data sink <b>360</b>, and provide decoded control information to a controller/processor <b>380</b>. The processor <b>380</b> may also perform or direct the execution of the functional blocks illustrated in <figref idref="DRAWINGS">FIGS. 10A-B</figref>, and/or other processes for performance by a UE according to the techniques described herein.

On the uplink, at the UE <b>120</b>, a transmit processor <b>364</b> may receive and process data (e.g., for the PUSCH) from a data source <b>362</b> and control information (e.g., for the PUCCH) from the controller/processor <b>380</b>. The processor <b>364</b> may also generate reference symbols for a reference signal. The symbols from the transmit processor <b>364</b> may be precoded by a TX MIMO processor <b>366</b> if applicable, further processed by the modulators <b>354</b><i>a </i>through <b>354</b><i>r </i>(e.g., for SC-FDM), and transmitted to the base station <b>110</b>. At the base station <b>110</b>, the uplink signals from the UE <b>120</b> may be received by the antennas <b>334</b>, processed by the demodulators <b>332</b>, detected by a MIMO detector <b>336</b> if applicable, and further processed by a receive processor <b>338</b> to obtain decoded data and control information sent by the UE <b>120</b>. The processor <b>338</b> may provide the decoded data to a data sink <b>339</b> and the decoded control information to the controller/processor <b>340</b>.

The controllers/processors <b>340</b> and <b>380</b> may direct the operation at the base station <b>110</b> and the UE <b>120</b>, respectively. The processor <b>340</b> and/or other processors and modules at the base station <b>110</b> may perform or direct the execution of various processes for the techniques described herein. The processor <b>380</b> and/or other processors and modules at the UE <b>120</b> may also perform or direct the execution of the functional blocks illustrated in <figref idref="DRAWINGS">FIGS. 12A-C</figref>, and/or other processes for the techniques described herein. The memories <b>342</b> and <b>382</b> may store data and program codes for the base station <b>110</b> and the UE <b>120</b>, respectively. A scheduler <b>344</b> may schedule UEs for data transmission on the downlink and/or uplink. Other aspects of the techniques described herein may be performed by other network entities of a wireless communications systems as described elsewhere herein.

eMBMS and Unicast Signaling in Single Frequency Networks

One mechanism to facilitate high bandwidth communication for multimedia has been single frequency network (SFN) operation. Particularly, Multimedia Broadcast Multicast Service (MBMS) and MBMS for LTE, also known as evolved MBMS (eMBMS) (including, for example, what has recently come to be known as multimedia broadcast single frequency network (MBSFN) in the LTE context), can utilize such SFN operation. SFNs utilize radio transmitters, such as, for example, eNBs, to communicate with subscriber UEs. Groups of eNBs can transmit information in a synchronized manner, meaning that wireless signals from multiple eNBs reinforce one another rather than interfere with each other at the receiving station. In the context of eMBMS, the shared content is transmitted from multiple eNB's of a LTE network to multiple UEs. Therefore, within a given eMBMS area, a UE may receive eMBMS signals from any eNB (or eNBs) within radio range that belong to the same MBSFN service area. However, to decode the eMBMS signal each UE receives Multicast Control Channel (MCCH) information from a serving eNB over a non-eMBMS channel. MCCH information changes from time to time and notification of changes is provided through another non-eMBMS channel, the PDCCH. Therefore, to decode eMBMS signals within a particular eMBMS area, each UE is served MCCH and PDCCH signals by one of the eNBs in the area.

In accordance with aspects of the subject of this disclosure, there is provided a wireless network (e.g., a 3GPP network) having features relating to single carrier optimization for eMBMS. An efficient way to transmit shared content from an LTE network to multiple mobile devices, such as, for example, UEs, may be provided by eMBMS.

For a physical layer (PHY) of eMBMS for LTE Frequency Division Duplex (FDD), the channel structure may comprise time division multiplexing (TDM) resource partitioning between an eMBMS and unicast transmissions on mixed carriers, thereby allowing flexible and dynamic spectrum utilization. Currently, a subset of subframes (up to 60%), known as multimedia broadcast single frequency network (MBSFN) subframes, can be reserved for eMBMS transmission. As such current eMBMS design allows at most six out of ten subframes for eMBMS.

An example of subframe allocation for eMBMS is shown in <figref idref="DRAWINGS">FIG. 4</figref>, which shows an existing allocation of MBSFN reference signals on MBSFN subframes <b>400</b>, for a single-carrier case. Components depicted in <figref idref="DRAWINGS">FIG. 4</figref> correspond to those shown in <figref idref="DRAWINGS">FIG. 2</figref>, with <figref idref="DRAWINGS">FIG. 4</figref> showing the individual subcarriers within each slot <b>402</b> and resource block (RB) <b>404</b>. In 3GPP LTE, a RB <b>404</b> spans 12 subcarriers over a slot duration of 0.5 ms, with each subcarrier having a bandwidth of 15 kHz. Therefore, the 12 subcarriers together spann 180 kHz per RB. Subframes may be allocated for unicast or eMBMS; for example in a sequence of ten subframes <b>408</b> numbered to zero (0) to nine (9), subframes <b>0</b>, <b>4</b>, <b>5</b>, and <b>9</b> may be excluded from eMBMS in FDD. Also, subframes <b>0</b>, <b>1</b>, <b>5</b>, and <b>6</b> may be excluded from eMBMS in time division duplex (TDD). More specifically, subframes <b>0</b>, <b>4</b>, <b>5</b>, and <b>9</b> may be used for PSS/SSS/PBCH/paging/system information blocks (SIBs) and unicast service. Remaining subframes in the sequence, e.g., subframes <b>1</b>, <b>2</b>, <b>3</b>, <b>6</b>, <b>7</b>, and <b>8</b> may be configured as eMBMS subframes.

With continued reference to <figref idref="DRAWINGS">FIG. 4</figref>, within each eMBMS subframe <b>400</b>, the first 1 or 2 symbols may be used for unicast reference symbols (RSs) and control signaling. A CP length of the first 1 or 2 symbols may follow that of subframe <b>0</b>. A transmission gap may occur between the first 1 or 2 symbols and the eMBMS symbols if the CP lengths are different in adjacent subframes. In related aspects, the overall eMBMS bandwidth utilization may be 42.5% considering RS overhead (e.g., 6 eMBMS subframes and 2 control symbols within each eMBMS subframe). Known techniques for providing MBSFN RSs and unicast RSs typically involve allocating the MBSFN RSs on MBSFN subframes (as shown in <figref idref="DRAWINGS">FIG. 4</figref>), and separately allocating unicast RSs on non-MBSFN subframes. More specifically, as <figref idref="DRAWINGS">FIG. 4</figref> shows, the extended CP of the MBSFN subframe <b>400</b> includes MBSFN RSs <b>410</b> but not unicast RSs. The present technology is not limited to the particular frame allocation scheme illustrated by <figref idref="DRAWINGS">FIGS. 2 and 4</figref>, which are presented by way of example, and not by way of limitation. A multicast session, which may also be referred to as a multicast broadcast, may use any suitable frame allocation scheme.

eMBMS Service Areas

<figref idref="DRAWINGS">FIG. 5</figref> illustrates a system <b>500</b> including an MBMS service area <b>502</b> encompassing multiple MBSFN areas <b>504</b>, <b>506</b>, <b>508</b>, which themselves include multiple cells or base stations <b>510</b>. As used herein, an “MBMS service area” refers to a group of wireless transmission cells where a certain MBMS service is available. For example, a particular sports or other program may be broadcast by base stations within the MBMS service area at a particular time. The area where the particular program is broadcast defines the MBMS service area. The MBMS service area may be made up of one or more “MBSFN areas” as shown at <b>504</b>, <b>506</b> and <b>508</b>. As used herein, an MBSFN area refers to a group of cells (e.g., cells <b>510</b>) currently broadcasting a particular program in a synchronized fashion using an MBSFN protocol. An “MBSFN synchronization area” refers to a group of cells that are interconnected and configured in a way such that they are capable of operating in a synchronized fashion to broadcast a particular program using an MBSFN protocol, regardless of whether or not they are currently doing so. Each eNB can belong to only one MBSFN synchronization area, on a given frequency layer. It is worth noting that an MBMS service area <b>502</b> may include one or more MBSFN synchronization areas (not shown). Conversely, an MBSFN synchronization area may include one or more MBSFN areas or MBMS service areas. Generally, an MBSFN area is made up of all, or a portion of, a single MBSFN synchronization area and is located within a single MBMS service area. Overlap between various MBSFN areas is supported, and a single eNB may belong to several different MBSFN areas within a single synchronization area. For example, up to 8 independent MCCHs may be configured in System Information Block (SIB) <b>13</b> to support membership in different MBSFN areas. An MBSFN Area Reserved Cell or Base Station is a cell/base station within a MBSFN Area that does not contribute to the MBSFN transmission, for example a cell near a MBSFN Synchronization Area boundary, or a cell that that is not needed for MBSFN transmission because of its location.

eMBMS System Components and Functions

<figref idref="DRAWINGS">FIG. 6</figref> illustrates functional entities of a wireless communication system <b>600</b> for providing or supporting MBSFN service. Regarding Quality of Service (QoS), the system <b>600</b> may use a Guaranteed Bit Rate (GBR) type MBMS bearer, wherein the Maximum Bit Rate (MBR) equals the GBR. These components are shown and described by way of example, and do not limit the inventive concepts described herein, which may be adapted to other architectures and functional distributions for delivering and controlling multicast transmissions.

The system <b>600</b> may include an MBMS Gate Way (MBMS GW) <b>616</b>. The MBMS GW <b>616</b> controls Internet Protocol (IP) multicast distribution of MBMS user plane data to eNodeBs <b>604</b> via an M1 interface, wherein “M1” refers to a logical interface as described by technical specifications for LTE and related specifications; one eNB <b>604</b> of many possible eNBs is shown. In addition, the MBMS GW controls IP multicast distribution of MBMS user plane data to UTRAN Radio Network Controllers (RNCs) <b>620</b> via an M1 interface; one UTRAN RNC <b>620</b> of many possible RNCs is shown. The M1 interface is associated to MBMS data (user plane) and makes use of IP for delivery of data packets. The eNB <b>604</b> may provide MBMS content to a UE/mobile device <b>602</b> via an E-UTRAN Uu interface, wherein “Uu” refers to an air interface as described by technical specifications for LTE and related specifications. The RNC <b>620</b> may provide MBMS content to a UE mobile device <b>622</b> via a Uu interface. The MBMS GW <b>616</b> may further perform MBMS Session Control Signaling, for example MBMS session start and session stop, via the Mobility Management Entity (MME) <b>608</b> and Sm interface, wherein “Sm” refers to a logical interface as described by technical specifications for LTE and related specifications. The MBMS GW <b>616</b> may further provide an interface for entities using MBMS bearers through the SG-mb (user plane) reference point, and provide an interface for entities using MBMS bearers through the SGi-mb (control plane) reference point, wherein “SG-mb” and “SGI-mb” refer to logical interfaces as described by technical specifications for LTE and related specifications. The SG-mb interface carries MBMS bearer service specific signaling. The SGi-mb interface is a user plane interface for MBMS data delivery. MBMS data delivery may be performed by IP unicast transmission, which may be a default mode, or by IP multicasting. The MBMS GW <b>616</b> may provide a control plane function for MBMS over UTRAN via a Serving General Packet Radio Service Support Node (SGSN) <b>618</b> and the Sn/Iu interfaces.

The system <b>600</b> may further include a Multicast Coordinating Entity (MCE) <b>606</b>. The MCE <b>606</b> may perform an admission control function for MBMS content, and allocate time and frequency radio resources used by all eNBs in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation. The MCE <b>606</b> may determine a radio configuration for an MBSFN Area, such as, for example, the modulation and coding scheme. The MCE <b>606</b> may schedule and control user plane transmission of MBMS content, and manage eMBMS service multiplexing, by determining which services are to be multiplexed in which Multicast Channel (MCH). The MCE <b>606</b> may participate in MBMS Session Control Signaling with the MME <b>608</b> through an M3 interface, and may provide a control plane interface M2 with the eNB <b>604</b>, wherein “M2” and “M3” refer to logical interfaces as described by technical specifications for LTE and related specifications.

The system <b>600</b> may further include a Broadcast-Multicast Service Center (BM-SC) <b>612</b> in communication with a content provider server <b>614</b>. The BM-SC <b>616</b> may handle intake of multicast content from one or more sources such as the content provider <b>614</b>, and provide other higher-level management functions as described below. These functions may include, for example, a membership function, including authorization and initiation of MBMS services for an identified UE. The BM-SC <b>616</b> may further perform MBMS session and transmission functions, scheduling of live broadcasts, and delivery, including MBMS and associated delivery functions. The BM-SC <b>616</b> may further provide service advertisement and description, such as advertising content available for multicast. A separate Packet Data Protocol (PDP) context may be used to carry control messages between a UE and the BM-SC. The BM-SC may further provide security functions such as key management, manage charging of content providers according to parameters such as data volume and QoS, provide content synchronization for MBMS in UTRAN and in E-UTRAN for multicast broadcast mode, and provide header compression for MBSFN data in UTRAN. The BM-SC <b>612</b> may indicate session start, update and stop to the MBMS-GW <b>616</b> including session attributes such as QoS and MBMS service area.

The system <b>600</b> may further include a Multicast Management Entity (MME) <b>608</b> in communication with the MCE <b>606</b> and MBMS GateWay (GW) <b>616</b>. The MME <b>608</b> may provide a control plane function for MBMS over E-UTRAN. In addition, the MME may provide the eNB <b>604</b> with multicast related information defined by the MBMS-GW <b>616</b>. An Sm interface between the MME <b>608</b> and the MBMS-GW <b>616</b> may be used to carry MBMS control signaling, for example, session start and stop signals.

The system <b>600</b> may further include a Packet Data Network (PDN) Gate Way (GW) <b>610</b>, sometimes abbreviated as a P-GW. The P-GW <b>610</b> may provide an Evolved Packet System (EPS) bearer between the UE <b>602</b> and BM-SC <b>612</b> for signaling and/or user data. As such, the P-GW may receive Uniform Resource Locator (URL) based requests originating from UEs in association with IP addresses assigned to the UEs. The BM-SC <b>612</b> may also be linked to one or more content providers via the P-GW <b>610</b>, which may communicate with the BM-SC <b>612</b> via an IP interface.

The system may include new interfaces enabling direct communications between certain system components, to facilitate aspects of the methods and apparatus disclosed herein. For example, a direct interface <b>624</b> may be provided between the eNB <b>604</b> and the BM-SC <b>612</b>. For further example, a direct interface <b>626</b> may be provided between the MCE <b>606</b> and the BM-SC <b>612</b>. The eNB <b>604</b> may also be indirectly linked to various system components, including but not limited to the BM-SC, via an Operations and Maintenance (O&amp;M) link <b>628</b>.

Dynamic Adaptive Streaming Over HTTP (DASH)

Dynamic adaptive streaming in unicast transmissions is described in 3GPP2 TS 26.247 v. 1.3.0 (2011-03) “Dynamic Adaptive Streaming over HTTP (3GP-DASH).” DASH as described in the foregoing document operates at the mobile device level by selection of a video bit rate, resolution, or other quality factor based on the mobile device's own observed Quality of Service (QoS) for the unicast connection over which a media component is being received. The mobile entity indicates its desired service quality based on its own hardware configuration and the unicast QoS. A network entity controlling the service quality of the unicast transmission, for example, a BM-SC, responds to the indication from the mobile entity to provide a requested service quality, e.g., video or audio bit rate, resolution, display size, or the like. This adaptive streaming capability is designed to be dynamic, meaning that the service quality can be adjusted during a unicast transmission; for example, service quality can be adjusted at a specified frame boundary or time as the unicast Signal-to-Noise Ratio (SNR) varies due to movement of the mobile device or other factors, or to support transfer of a unicast media session to an alternative wireless device. In general, DASH as conceived for unicast service relies on a feedback mechanism from the mobile device to the one or more network entities that control the service quality of the unicast transmission. The network entity controlling service quality may reside outside of the wireless communication system providing unicast transport; for example, in a connected network.

Dynamic Adaptive QoS Control in Multicast

DASH as developed for unicast transmissions generally cannot be deployed to control quality of service for multicast transmissions, for several reasons. In a multicast broadcast context, selection of a service quality at the mobile device level is not useful or feasible, because the service quality that is possible or desirable for one mobile device may not be possible or desirable for other mobile devices receiving the same multicast transmission from the same source. For this and other reasons, in the multicast broadcast context, the network infrastructure should control selection of multicast broadcast data quality. In addition, current multicast protocols lack an established interface or signal pathway for feedback from the mobile device level to the multicast control level for conveying information about multicast service quality after a multicast session begins. Instead, service quality is fixed at the initiation of each multicast session and does not change during the multicast transmission. For example, in eMBMS, streaming content is delivered using a separate flow that uses Real-Time transport Protocol (RTP) as the transport protocol. In RTP, applicable streaming parameters are delivered to the client device prior to the start of the streaming session, and these parameters are not modified after the streaming session starts. For these and other reasons, system operators and designers lack any clear motivation, reason, or technical method for providing a dynamic adaptive QoS capability in multicast transmissions.

However, surprising benefits may be obtained by adapting a type of dynamic adaptive service for multicast transmissions. Such benefits may include, for example, providing more optimal multicast service quality based on network load factors, including adjusting QoS based on changes in network load factors during the course of a multicast transmission. Multicast network load factors may include, for example: system bandwidth; multicast (e.g., MBSFN) area characteristics, for example, average cell radius and number of cells in a multicast area; interference level from transmitters outside of the multicast area; unicast load or demand; and number of concurrent multicast services demanded. System bandwidth and area characteristics may be relatively static in nature for a given MBSFN area or similar multicast area. However, the remaining network load factors may be quite dynamic (time-varying). Interference may vary due to varying loads in a neighboring area. Demand for unicast services may vary based on time-of-day, day-of-week, and/or special events. The number of concurrent multicast services may likewise vary. For example, special events or new releases of content (e.g., new game or video release) may concentrate demand for content in certain areas at certain times, while at other times more numerous but less individually popular content is available via multicast. When more numerous and diverse selections of multicast sessions are available, bandwidth available for each concurrent session will decrease if aggregate available bandwidth does not increase in proportion to the increase in concurrent multicast sessions. The converse occurs when fewer concurrent multicast sessions are available. In addition, the network may allocate differently-sized shares of available bandwidth to different concurrent multicast services for a variety of reasons, including but not limited to content type and target device type.

Therefore, bandwidth available for multicast transmission can vary substantially within a multicast area, even within relatively short time periods within the duration of a multicast session. For example, as the number of multicast programs in an area decreases coupled with a decrease in use of unicast services, bandwidth available for certain individual multicast services may increase above baseline levels within a multicast area. Similarly, available bandwidth for a multicast program may decrease as the number of available multicast programs increases and/or unicast usage increases. In either situation, it may be desirable to change the QoS for a streaming multicast program after the multicast session has been initiated to enable reallocation of radio resources to or from one or more multicast sessions. Current protocols as defined by DASH require the client (mobile device) to request the QoS, implying that the mobile device has an uplink channel allocated on which the mobile device may communicate its desired QoS media stream segment from the server. But, as described above, a multicast network generally operates as a unidirectional channel from the network to the mobile device, with no corresponding uplink channel for communicating a desired QoS.

General system-level aspects of dynamic adaptive QoS in a multicast transmission are illustrated by <figref idref="DRAWINGS">FIG. 7</figref>, showing an embodiment of a network-level call flow <b>700</b> for QoS control in a multicast transmission. The depicted call flow may require changes to existing protocol for eMBMS or other broadcast/multicast protocols. The system <b>600</b> as shown in <figref idref="DRAWINGS">FIG. 6</figref> may be used to dynamically adapt QoS for an eMBMS or other multicast session in an MBMS area as shown in <figref idref="DRAWINGS">FIG. 7</figref>, including a BM-SC <b>706</b>, one or more intermediate nodes <b>704</b> generally described as a transport network, and a client <b>702</b>, for example a mobile device. However, the systems and methods disclosed herein are not limited to eMBMS or MBMS implementation, and may be implemented in other wireless technologies.

Initially, a BM-SC <b>706</b> may initiate <b>708</b> a multicast session in which content is streamed via a multicast session with initial QoS parameters for setting up the session on the client side. A multicast session may also be referred to as a multicast transmission or multicast broadcast, and should generally by understood as existing between definite initiation and termination events; accordingly, a multicast session/transmission should be understood as having a discernable duration. Generally for multicast broadcast protocols (e.g., MBMS or eMBMS), multicast traffic is unidirectional to the client (downlink only). Any client within range of the transport network wireless transmitters may receive the initial multicast transmission <b>708</b>, and generally multiple clients will receive the multicast transmission. For illustrative simplicity, a single client <b>702</b> is depicted. At <b>716</b>, the client uses the QoS parameters received from the BM-SC <b>706</b> via the transport network <b>704</b> to access the multicast content. Meanwhile, at <b>710</b>, the transport network monitors its own load and available bandwidth. The network <b>704</b> may continue to determine an optimum data rate during the streaming multicast session <b>708</b> while the multicast session is in progress. The “optimum” rate may be based on balancing competing resource demands subject to dynamic and/or static constraints and resource limitations; for example, determining the highest data rate that existing and/or anticipated resource constraints can effectively support. In the alternative, or in addition, the BM-SC <b>706</b> may determine an optimum data rate or participate in such determination. At <b>712</b>, the transport network <b>704</b> may provide a signal to the BM-SC <b>706</b> responsive to its determination at <b>710</b>. To continuously update the BM-SC about the latest network loading conditions, the signal may be sent many times during the multicast session. The signal may indicate network load factors, available multicast bandwidth, or both to the BM-SC. In the alternative, or in addition, the signal may indicate a desired optimum data rate or other adapted QoS parameter for the multicast session, depending on where decision making functionality is distributed. The BM-SC may receive the signal and generate updated QoS parameters for the multicast session. At <b>714</b>, the BM-SC may send the updated parameters with the continuing content for the multicast session via the transport network to multicast broadcast recipients, e.g., client <b>702</b>. At <b>718</b>, the client <b>702</b> uses the updated QoS parameters to access the multicast content.

Current multicast protocols do not support providing updated QoS parameters to the client after a multicast session is initiated, as indicated at <b>714</b>. New methods and apparatus for providing updated QoS parameters are disclosed herein. Similarly, network load monitoring as indicated at <b>710</b> and signaling network load factors or available bandwidth to a BM-SC or similar entity as indicated at <b>712</b> may be enabled by the examples of new methodologies and apparatus disclosed below.

The BM-SC may be positioned upstream of the MBMS Gateway, and may be a suitable candidate for implementing QoS control aspects of the methods described herein. In such case, the BM-SC may update QoS per multicast service based on MBSFN load factors. The BM-SC may use an updated QoS to request a different video bit rate or resolution from a content provider. The content provider may provide content with the requested QoS for multicast transmission in accordance with the request of the BM-SC. Alternatively, for each flow, multiple streams may be sent to the BM-SC and the BM-SC may choose an appropriate stream for each MBSFN area, for example a stream that best matches a requested QoS in the area. The BM-SC may propagate the updated QoS to the MCE for the applicable MBSFN area. The MCE may then schedule MBMS resources for each multicast service, including an updated Modulation Coding Scheme (MCS) and number of subframes allocated for each multicast service. The eNBs within the applicable MBSFN area may be updated using a System Information Block (SIB) <b>13</b>, MCCH or Multicast Transport Channel (MTCH) transmission. The UE may decode the multicast service using the updated Physical Multicast Channel (PMCH) parameters.

Example Methodologies and Apparatus

Methodologies that may be implemented in accordance with the disclosed subject matter may be better appreciated with reference to various flow charts. For purposes of simplicity of explanation, methodologies are shown and described as a series of acts/operations. However, the claimed subject matter is not limited by the number or order of operations, as some operations may occur in different orders and/or at substantially the same time with other operations from what is depicted and described herein. Moreover, not all illustrated operations may be required to implement methodologies described herein. It is to be appreciated that functionality associated with operations may be implemented by software, hardware, a combination thereof or any other suitable means (e.g., device, system, process, or component). Additionally, it should be further appreciated that methodologies disclosed throughout this specification are capable of being stored as encoded instructions and/or data on an article of manufacture to facilitate transporting and transferring such methodologies to various devices. Those skilled in the art will understand and appreciate that a method could alternatively be represented as a series of interrelated states or events, such as in a state diagram.

Network Entity/BM-SC

<figref idref="DRAWINGS">FIGS. 8A-F</figref> illustrate related methodologies for dynamically controlling Quality-of-Service (QoS) for a multicast transmission from a network entity of a wireless communications system (WCS). The multicast transmission may be broadcast so that multiple mobile devices may receive it. The network entity may comprise a BM-SC as shown at <b>706</b> of <figref idref="DRAWINGS">FIG. 7</figref>. The multicast protocol may be downlink only, such that any mobile device receiving the multicast transmission does not provide feedback to the BM-SC. Method <b>800</b> shown in <figref idref="DRAWINGS">FIG. 8A</figref> may include, at <b>802</b>, initiating a multicast transmission having an initial QoS. The network entity may define the QoS using parameters such as bit rate, media type, resolution, frame rate, or other parameters related to bandwidth required for the multicast transmission. The method <b>800</b> may further include, at <b>804</b>, one or more network entities generating an updated QoS for the multicast transmission, in response to a network load factor for a multicast area. The updated QoS may replace the initial QoS, in that the multicast transmission may be transmitted at the new QoS prior to termination. Updating the QoS, in general, includes changing the QoS for the multicast transmission during the multicast session, without initiating a new multicast session. In such cases, the mobile devices may need to obtain information describing the updated QoS to be able to continue to use subsequent multicast content in the session. The updated QoS may require a different bandwidth than the initial QoS, and may be configured for updating the initial QoS during the multicast transmission. Therefore mobile entities may receive and access an initial portion of the multicast transmission using a first QoS, and subsequently receive and access a second portion of the multicast transmission using a second QoS different from the initial QoS. In this sense, the network entity may be described as dynamically controlling the QoS for the multicast transmission.

Additional operations <b>850</b> for effecting an update of the QoS are illustrated in <figref idref="DRAWINGS">FIG. 8B</figref>, for performance by the network entity. One or more of operations <b>850</b> may optionally be performed as part of method <b>800</b>. The operations <b>850</b> may be performed in any operative order, or may be encompassed by a development algorithm without requiring a particular chronological order of performance. Operations may be independently performed and not mutually exclusive. Therefore any one of such operations may be performed regardless of whether another downstream or upstream operation is performed. For example, if the method <b>800</b> includes at least one of the operations <b>850</b>, then the method <b>800</b> may terminate after the at least one operation, without necessarily having to include any subsequent downstream operation(s) that may be illustrated.

The additional operations <b>850</b> may include, at <b>805</b>, updating the multicast transmission using the updated QoS. For example, the network entity may cause the content being streamed in the multicast transmission to be formatted and transmitted according to the new QoS. For example, the new QoS may have a different resolution, frame rate, or so forth. This operation <b>805</b> may be performed in cooperation with a content server for the multicast content. The operations <b>850</b> may further include, at <b>806</b>, indicating the updated QoS to a mobile entity receiving the multicast transmission. Various modes for providing this indication are described below, each of which may be used to provide parameter information from the controlling network entity to the client mobile devices. The multicast transmission protocols in use may be configured such that the network entity does not receive feedback from the mobile entity, as indicated at block <b>808</b>. Block <b>808</b> illustrates that the entire method <b>800</b>, including any additional aspects or operations <b>850</b> or <b>860</b>, may optionally be performed by the network entity without receiving any feedback from the mobile device; for example, the method may exclude receiving feedback from the mobile device. In general, indicating the updated QoS <b>806</b> may comprise providing parameters for streaming a media component to the mobile entity, as indicated at block <b>810</b>. Parameters may include, for example: a protocol ID; a media type; a data rate, optionally using existing SDP bandwidth modifiers; a mode of MBMS bearer per media; FEC configuration and related parameters; service language(s) per media; Quality of Experience (QoE) metrics, for example as defined in 3GPP TS 26.346 at 8.3.2.1 and 8.4; a QoS Class Identifier (QCI); an Allocation Retention Priority; a Maximum Bit Rate (MBR); optionally a Guaranteed Bit Rate (GBR); or other parameter data.

As shown in <figref idref="DRAWINGS">FIG. 8C</figref>, the additional operations <b>850</b> may include, according to a first alternative at <b>812</b>, indicating the updated QoS <b>806</b> by specifying, in an announcement, new ones of the parameters taking effect at a specified frame boundary or time. The announcement may be made using a service announcement procedure. The frame boundary or time may relate to a frame or timeline point of the multicast content. The additional operations <b>850</b> may further include, at <b>814</b>, generating the announcement in connection with corresponding planned changes in the QoS. For example, the network entity may generate a service announcement for each upcoming QoS update. Blocks <b>816</b>-<b>818</b> relate to alternative or complementary operations for transmitting a service announcement. The additional operations <b>850</b> may further include, at <b>816</b>, transmitting the announcement according to a Session Description Protocol (SDP) or a modified SDP. In the alternative, or in addition, the additional operations <b>850</b> may further include, at <b>818</b>, transmitting the announcement according to a File Description Table (FDT) or a modified FDT.

As shown in <figref idref="DRAWINGS">FIG. 8D</figref>, the additional operations <b>850</b> may include, according to a second alternative at <b>820</b>, indicating the updated QoS <b>806</b> by sending the parameters in a corresponding control stream. The corresponding control stream may be multicast concurrently with the primary multicast transmission. That is, the corresponding control stream may comprise a second, or parallel, multicast transmission that includes data related to the first multicast transmission that is being dynamically controlled. The corresponding stream may comprise a low bit rate stream dedicated for QoS and optionally other control data correlated to the media stream. During periods when the QoS is not being updated, e.g., in between updates, the corresponding control stream may comprise null data or meaningless data that can be ignored by receiving clients. To reduce overhead required by corresponding control streams, QoS updates for more than one multicast transmission may be broadcast using a single aggregated control stream.

As shown in <figref idref="DRAWINGS">FIG. 8E</figref>, the additional operations <b>850</b> may include, according to a second alternative at <b>822</b>, indicating the updated QoS by including the parameters in headers of a stream transport protocol for the multicast transmission. As indicated at blocks <b>823</b>-<b>824</b>, the stream transport protocol may comprise an HTTP push protocol. In an alternative <b>823</b>, the operations <b>850</b> may include, at <b>824</b>, configuring the stream transport protocol as a modified autonomous HTTP push protocol. Existing HTTP push protocol requires using TCP with a bidirectional channel. In the modified HTTP push protocol, server-side events may be used for content delivery autonomously sent to the mobile device. The HTTP push protocol may use the HTTP headers as currently defined, but the modified transport protocol may use a unidirectional transport protocol such as User Datagram Protocol (UDP). In addition the modified HTTP push protocol may not require a request from the mobile device. According to another alternative <b>823</b>, the operations <b>850</b> may include, at <b>825</b>, not configuring the stream transport protocol as an HTTP push protocol. In this case, a stream transport protocol may need to be modified to include the desired parameters in transport headers.

Additional operations for <b>860</b> for effecting an update of the QoS are illustrated in <figref idref="DRAWINGS">FIG. 8F</figref>, for performance by the network entity. One or more of operations <b>860</b> may optionally be performed as part of method <b>800</b>. One or more of operations <b>860</b> may optionally be performed as part of method <b>800</b>. The elements <b>860</b> may be performed in any operative order, or may be encompassed by a development algorithm without requiring a particular chronological order of performance. Operations are independently performed and not mutually exclusive. Therefore any one of such operations may be performed regardless of whether another downstream or upstream operation is performed. For example, if the method <b>800</b> includes at least one of the operations <b>860</b>, then the method <b>800</b> may terminate after the at least one operation, without necessarily having to include any subsequent downstream operation(s) that may be illustrated.

Operations <b>860</b> may include, at <b>830</b>, communicating with an intermediate node within the WCS to obtain feedback indicative of the network load factor. Here, “indicative of a network load factor” should be understood to include data indicative of one or more network load factors, or of available bandwidth for multicast, or of a desired bandwidth allocation or quality of service. Accordingly, as illustrated at <b>832</b>, the operations <b>860</b> may include communicating with an intermediate node to obtain an updated QoS. In the alternative, or in addition, as illustrated at <b>834</b>, the operations <b>860</b> may include communicating with an intermediate node to obtain one or more additional factors not limited to QOS or network load factors for use in controlling the QoS. Additional factors may include, for example, schedule information for eMBMS programming, a program-specific QoS, or other information. In the alternative, or in addition, as illustrated at <b>836</b>, the operations <b>860</b> may include receiving the network load factor, wherein the network load factor indicates an available bandwidth for the multicast transmission in the multicast area. As used herein, an “intermediate node” means a node of a transport network intermediate between the network entity controlling the multicast QoS and the client level (e.g., UE <b>702</b>), for example, a node of the transport network <b>704</b>.

An intermediate node may include, for example, an MCE or eNB. A new message may be added to the M2 interface to indicate bandwidth availability. The MCE may use feedback from each eNB in an MBSFN or other multicast area to estimate a bandwidth allocation for a multicast transmission. Different multicast areas may transmit the same content using different QoS parameters; for example, the current QoS may be different in different areas for the same streaming content (e.g., a specific video program streamed to different areas at different QoS). Accordingly, the operations <b>860</b> may include, at <b>838</b>, receiving the network load factor from a Multicast Coordinating Entity (MCE). In such case, the operations <b>860</b> may include, at <b>840</b>, receiving the network load factor from the MCE via at least one of a message over a direct interface, a message relayed through several interfaces, or an Operations &amp; Maintenance based indication. In the alternative, or in addition, the operations <b>860</b> may include, at <b>842</b>, receiving the network load factor directly from an eNode B (eNB). In such case, the operations <b>860</b> may likewise include, at <b>844</b>, receiving the network load factor from the eNB via at least one of a message over a direct interface, a message relayed through several interfaces, or an Operations &amp; Maintenance based indication. A new message may be added to the M1/SGi-mb interfaces to indicate load factors, e.g., bandwidth availability.

With reference to <figref idref="DRAWINGS">FIG. 9</figref>, there is provided an exemplary apparatus <b>900</b> that may be configured as BM-SC in a wireless network, or as a processor or similar device for use within the BM-SC, for providing dynamic adaptable multicast services. The apparatus <b>900</b> may include functional blocks that can represent functions implemented by a processor, software, or combination thereof (e.g., firmware).

As illustrated, in one embodiment, the apparatus <b>900</b> may include an electrical component or module <b>902</b> for initiating a multicast transmission having an initial QoS. For example, the electrical component <b>902</b> may include at least one control processor coupled to a network interface or the like and to a memory with instructions for initiating a multicast transmission in cooperation with a transport network. The electrical component <b>902</b> may be, or may include, means for initiating a multicast transmission having an initial QoS. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, providing instructions for a multicast transmission via a network interface to base stations in a multicast area, and including in, or with, the instructions at least one QoS parameter to be used by the base stations for implementing the multicast transmission as a multicast session over an air interface.

The apparatus <b>900</b> may include an electrical component <b>904</b> for generating an updated QoS for the multicast transmission, in response to a network load factor for a multicast area, for updating the initial QoS prior to termination of the multicast transmission. For example, the electrical component <b>904</b> may include at least one control processor coupled to a memory holding instructions for generating an updated QoS during the multicast transmission in response to feedback received from one or more components of the transport network. The electrical component <b>904</b> may be, or may include, means for generating an updated QoS for the multicast transmission, in response to a network load factor for a multicast area, prior to termination of the multicast transmission. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, measuring a network load factor, detecting a change in the network load factor, and determining an updated value for at least one QoS parameter based on the network load factor, in response to detecting the change in the network load factor. The algorithm may further include transmitting the updated value of the at least one QoS parameter (i.e., the updated QoS) to the base stations in the multicast area for updating the QoS of the multicast session over the air interface by replacing an initial QoS of the session with an updated QoS and transmitting the multicast transmissions using the updated QoS. The apparatus <b>900</b> may include similar electrical components for performing any or all of the additional operations <b>850</b> and <b>860</b> described in connection with <figref idref="DRAWINGS">FIGS. 8B-F</figref>, which for illustrative simplicity are not shown in <figref idref="DRAWINGS">FIG. 9</figref>.

In related aspects, the apparatus <b>900</b> may optionally include a processor component <b>910</b> having at least one processor, in the case of the apparatus <b>900</b> configured as a network entity. The processor <b>910</b>, in such case, may be in operative communication with the components <b>902</b>-<b>904</b> or similar components via a bus <b>912</b> or similar communication coupling. The processor <b>910</b> may effect initiation and scheduling of the processes or functions performed by electrical components <b>902</b>-<b>904</b>.

In further related aspects, the apparatus <b>900</b> may include a network interface component <b>914</b> for communicating with other network entities, for example, an Ethernet port or wireless interface. The apparatus <b>900</b> may optionally include a component for storing information, such as, for example, a memory device/component <b>916</b>. The computer readable medium or the memory component <b>916</b> may be operatively coupled to the other components of the apparatus <b>900</b> via the bus <b>912</b> or the like. The memory component <b>916</b> may be adapted to store computer readable instructions and data for performing the activity of the components <b>902</b>-<b>904</b>, and subcomponents thereof, or the processor <b>910</b>, the additional operations <b>850</b> or <b>860</b>, or the methods disclosed herein. The memory component <b>916</b> may retain instructions for executing functions associated with the components <b>902</b>-<b>904</b>. While shown as being external to the memory <b>916</b>, it is to be understood that the components <b>902</b>-<b>904</b> can exist within the memory <b>916</b>.

Mobile Device

A mobile device may be configured to use dynamically updated QoS information to access portions of a multicast transmission. Accordingly, <figref idref="DRAWINGS">FIG. 10A</figref> illustrates a method <b>1000</b> that may be performed by a mobile device of a wireless communications system, for receiving and using a multicast transmission having a dynamically controlled Quality-of-Service (QoS). The method <b>1000</b> may include, at <b>1002</b>, receiving a content, for example streaming content, via a multicast transmission in a wireless communications system. The multicast transmission may be received having an initial QoS, and the method <b>1000</b> may include processing an initial portion of the content using the initial QoS. Method <b>1000</b> may further include, at <b>1004</b>, receiving an updated QoS during the multicast transmission, wherein the updated QoS is different from the initial QoS. Method <b>1000</b> may further include, at <b>1006</b>, processing a subsequent portion of the content according to the updated QoS.

In addition, <figref idref="DRAWINGS">FIG. 10B</figref> shows further optional elements <b>1050</b> that may be implemented for use by the mobile device in using a dynamically configured multicast transmission. The elements <b>1050</b> may be performed in any operative order, or may be encompassed by a development algorithm without requiring a particular chronological order of performance. Operations are independently performed and not mutually exclusive. Therefore any one of such operations may be performed regardless of whether another downstream or upstream operation is performed. For example, if the method <b>1000</b> includes at least one operation of <figref idref="DRAWINGS">FIG. 10B</figref>, then the method <b>1000</b> may terminate after the at least one operation, without necessarily having to include any subsequent downstream operation(s) that may be illustrated.

The additional elements <b>1050</b> may include, at <b>1008</b>, the mobile device receiving the updated QoS including receiving parameters for processing a media stream of the content. Parameters may include, for example: a protocol ID; a media type; a data rate, optionally using existing SDP bandwidth modifiers; a mode of MBMS bearer per media; FEC configuration and related parameters; service language(s) per media; QoE metrics, for example as defined in 3GPP TS 26.346 at 8.3.2.1 and 8.4; a QCI; an Allocation Retention Priority; an MBR; and/or optionally a GBR. The additional elements <b>1050</b> may further include, at <b>1010</b>, receiving the parameters at the mobile device by receiving a corresponding control stream containing the parameters for the media stream. For example, as noted above, the corresponding control stream may be broadcast through the WCS from a multicast controlling entity. In the alternative, the additional elements <b>1050</b> may further include, at <b>1012</b>, the mobile device receiving the parameters by receiving announcements each comprising new ones of the parameters for taking effect at one or more specified frame boundaries or times of the media stream. The elements <b>1050</b> may therefore include, at <b>1014</b>, receiving ones of the announcements according to an SDP or modified SDP. In the alternative, the elements <b>1050</b> may include, at <b>1016</b>, receiving ones of the announcements according to a FDT or modified FDT.

In a further alternative, the elements <b>1050</b> may include, at <b>1018</b>, the mobile entity receiving the parameters in headers of a stream transport protocol for the multicast transmission. In such case, the elements <b>1050</b> may include, at <b>1020</b>, receiving the parameters in headers of the stream transport protocol wherein the stream transport protocol comprises an HTTP push protocol.

With reference to <figref idref="DRAWINGS">FIG. 11</figref>, there is provided an exemplary apparatus <b>1100</b> that may be configured as a mobile device in a wireless network, or as a processor or similar device for use within the mobile device, for using a multicast transmission with dynamic adaptable QoS. The apparatus <b>1100</b> may include functional blocks that can represent functions implemented by a processor, software, or combination thereof (e.g., firmware).

As illustrated, in one embodiment, the apparatus <b>1100</b> may include an electrical component or module <b>1102</b> for receiving a content, for example streaming content, via a multicast transmission in a wireless communications system. For example, the electrical component <b>1102</b> may include at least one control processor coupled to a transceiver or the like and to a memory with instructions for receiving and using multicast content. The electrical component <b>1102</b> may be, or may include, means for receiving a content, for example streaming content, via a multicast transmission in a wireless communications system. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, receiving control information for decoding multicast symbols from a control channels, receiving radio frames over a wireless interface, and decoding data from the radio frames using the control information to obtain the content.

The apparatus <b>1100</b> may further include an electrical component <b>1104</b> for receiving an updated QoS during the multicast transmission. For example, the electrical component <b>1104</b> may include at least one control processor coupled to a transceiver or the like and to a memory holding instructions for receiving and recognizing an updated QoS according to one or more of the operations described herein. The electrical component <b>1104</b> may be, or may include, means for receiving an updated QoS during the multicast transmission. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, one or more of the operations <b>1050</b> described in connection with <figref idref="DRAWINGS">FIG. 10B</figref>.

The apparatus <b>1100</b> may further include an electrical component <b>1106</b> for processing a subsequent portion of the content according to the updated QoS. For example, the electrical component <b>1106</b> may include at least one control processor coupled to a transceiver or the like and to a memory holding instructions for processing a multicast session to provide a media output, for example streaming audio-video output for display on a display device. The electrical component <b>1106</b> may be, or may include, means for processing a subsequent portion of the content according to the updated QoS. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, determining a point in a received sequence of radio frames at which the updated QoS applies, and processing received data according to the updated QoS after that point. For example, if the updated QoS includes an updated frame rate or video resolution, the mobile entity may process video data received after the QoS changes to provide video output at the new frame rate and/or resolution. The apparatus <b>1100</b> may include similar electrical components for performing any or all of the additional operations <b>1050</b> described in connection with <figref idref="DRAWINGS">FIG. 10B</figref>, which for illustrative simplicity are not shown in <figref idref="DRAWINGS">FIG. 11</figref>.

In related aspects, the apparatus <b>1100</b> may optionally include a processor component <b>1110</b> having at least one processor, in the case of the apparatus <b>1100</b> configured as a mobile entity. The processor <b>1110</b>, in such case, may be in operative communication with the components <b>1102</b>-<b>1106</b> or similar components via a bus <b>1112</b> or similar communication coupling. The processor <b>1110</b> may effect initiation and scheduling of the processes or functions performed by electrical components <b>1102</b>-<b>1106</b>.

In further related aspects, the apparatus <b>1100</b> may include a radio transceiver component <b>1114</b>. A stand alone receiver and/or stand alone transmitter may be used in lieu of or in conjunction with the transceiver <b>1114</b>. The apparatus <b>1100</b> may optionally include a component for storing information, such as, for example, a memory device/component <b>1116</b>. The computer readable medium or the memory component <b>1116</b> may be operatively coupled to the other components of the apparatus <b>1100</b> via the bus <b>1112</b> or the like. The memory component <b>1116</b> may be adapted to store computer readable instructions and data for performing the activity of the components <b>1102</b>-<b>1106</b>, and subcomponents thereof, or the processor <b>1110</b>, the additional aspects <b>1050</b>, or the methods disclosed herein for a mobile device. The memory component <b>1116</b> may retain instructions for executing functions associated with the components <b>1102</b>-<b>1106</b>. While shown as being external to the memory <b>1116</b>, it is to be understood that the components <b>1102</b>-<b>1106</b> can exist within the memory <b>1116</b>.

Base Station

A base station may be configured to measure and provide network load information for use in dynamically controlling QoS of a multicast transmission. An eNB exemplifies a base station used in multicast transmission, but other wireless base stations, for example picocell or femtocell stations, are not excluded. <figref idref="DRAWINGS">FIG. 12A</figref> illustrates a method <b>1200</b> that may be performed by a base station of a wireless communications system, for indicating dynamic bandwidth availability from a base station of a wireless communications system for use in controlling QoS of a multicast transmission. The method <b>1200</b> may include, at <b>1202</b>, determining a currently available bandwidth for multicast transmission at the base station in response to at least one dynamically changing parameter, during the multicast transmission. Method <b>1200</b> may further include, at <b>1204</b>, indicating the currently available bandwidth to an upstream network entity for use in controlling a QoS of the multicast transmission. The operation <b>1204</b> may also be performed during the multicast transmission.

In addition, <figref idref="DRAWINGS">FIG. 12B</figref> shows further optional elements <b>1250</b> that may be implemented by the base station for indicating multicast bandwidth availability. The elements <b>1250</b> may be performed in any operative order, or may be encompassed by a development algorithm without requiring a particular chronological order of performance. Operations are independently performed and not mutually exclusive. Therefore any one of such operations may be performed regardless of whether another downstream or upstream operation is performed. For example, if the method <b>1200</b> includes at least one operation of <figref idref="DRAWINGS">FIG. 12B</figref>, then the method <b>1200</b> may terminate after the at least one operation, without necessarily having to include any subsequent downstream operation(s) that may be illustrated.

The additional elements <b>1250</b> may include, at <b>1206</b>, the base station transmitting an indication of the currently available bandwidth to the network entity via a message over a direct interface. A direct interface means a single interface for communication between two network nodes; for example, the M1 interface between an eNB <b>604</b> and MBMS GW <b>616</b>, or the new direct interface <b>624</b> between the eNB <b>604</b> and the BM-SC <b>612</b>, as shown in <figref idref="DRAWINGS">FIG. 6</figref>. In the alternative, the additional elements <b>1250</b> may further include, at <b>1208</b>, the base station transmitting an indication of the currently available bandwidth to the network entity via a message relayed through a plurality of interfaces and network nodes. In the alternative, the additional elements <b>1250</b> may further include, at <b>1210</b>, the base station providing an indication of the currently available bandwidth to the network entity using an Operations &amp; Maintenance based indication, for example as shown at <b>628</b> in <figref idref="DRAWINGS">FIG. 6</figref>.

As shown in <figref idref="DRAWINGS">FIG. 12C</figref>, in an aspect, the elements <b>1250</b> may include, at <b>1212</b>, including a measure of interference from one or more neighbor base stations in the dynamically changing parameter used by the base station for determining the currently available bandwidth. In the alternative, or in addition, the elements <b>1250</b> may include, at <b>1214</b>, including a measure of bandwidth allocated to unicast services in the dynamically changing parameter used by the base station for determining the currently available bandwidth. In the alternative, or in addition, the elements <b>1250</b> may include, at <b>1216</b>, including a measure of bandwidth allocated to other multicast services or transmissions in the dynamically changing parameter for determining the currently available bandwidth.

With reference to <figref idref="DRAWINGS">FIG. 13</figref>, there is provided an exemplary apparatus <b>1300</b> that may be configured as base station in a wireless network, or as a processor or similar device for use within the base station, for indicating dynamic bandwidth availability from a base station of a wireless communications system for use in controlling QoS of a multicast transmission. The apparatus <b>1300</b> may include functional blocks that can represent functions implemented by a processor, software, or combination thereof (e.g., firmware).

As illustrated, in one embodiment, the apparatus <b>1300</b> may include an electrical component or module <b>1302</b> for determining a currently available bandwidth for multicast transmission at the base station in response to at least one dynamically changing parameter, during the multicast transmission. For example, the electrical component <b>1302</b> may include at least one control processor coupled to a network interface or the like and to a memory with instructions for determining an available bandwidth using dynamic measurement parameters as disclosed herein. The electrical component <b>1302</b> may be, or may include, means for determining a currently available bandwidth for multicast transmission at the base station in response to at least one dynamically changing parameter, during the multicast transmission. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, measuring available (e.g., unused) downlink bandwidth using at least one of the operations <b>1250</b> shown in connection with <figref idref="DRAWINGS">FIG. 12C</figref>.

The apparatus <b>1300</b> may include an electrical component <b>1304</b> for indicating the currently available bandwidth to an upstream network entity for use in controlling a QoS of the multicast transmission. For example, the electrical component <b>1304</b> may include at least one control processor coupled to a memory holding instructions for signaling a network load factor, e.g., available bandwidth, to an upstream entity using any of the signaling operations or interfaces disclosed herein. The electrical component <b>1304</b> may be, or may include, means for indicating the currently available bandwidth to an upstream network entity for use in controlling a QoS of the multicast transmission. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, quantifying a measure of available bandwidth by normalizing against a benchmark (e.g., a percentage or proportion of full bandwidth) or by expressing an absolute value (e.g., bit/second available), and encoding the quantitative information symbolically in a signal to an upstream entity that controls the QoS. The apparatus <b>1300</b> may include similar electrical components for performing any or all of the additional operations <b>1250</b> described in connection with <figref idref="DRAWINGS">FIGS. 12B-C</figref>, which for illustrative simplicity are not shown in <figref idref="DRAWINGS">FIG. 13</figref>.

In related aspects, the apparatus <b>1300</b> may optionally include a processor component <b>1310</b> having at least one processor, in the case of the apparatus <b>1300</b> configured as a network entity. The processor <b>1310</b>, in such case, may be in operative communication with the components <b>1302</b>-<b>1304</b> or similar components via a bus <b>1312</b> or similar communication coupling. The processor <b>1310</b> may effect initiation and scheduling of the processes or functions performed by electrical components <b>1302</b>-<b>1304</b>.

In further related aspects, the apparatus <b>1300</b> may include a network interface component <b>1314</b> for communicating with other network entities. The apparatus <b>1300</b> may optionally include a component for storing information, such as, for example, a memory device/component <b>1316</b>. The computer readable medium or the memory component <b>1316</b> may be operatively coupled to the other components of the apparatus <b>1300</b> via the bus <b>1312</b> or the like. The memory component <b>1316</b> may be adapted to store computer readable instructions and data for performing the activity of the components <b>1302</b>-<b>1304</b>, and subcomponents thereof, or the processor <b>1310</b>, the additional operations <b>1250</b>, or the methods disclosed herein. The memory component <b>1316</b> may retain instructions for executing functions associated with the components <b>1302</b>-<b>1304</b>. While shown as being external to the memory <b>1316</b>, it is to be understood that the components <b>1302</b>-<b>1304</b> can exist within the memory <b>1316</b>.

Intermediate Network Entity

An intermediate network entity, for example, an MCE, may be configured to aggregate and provide network load information from a multicast area for use in dynamically controlling QoS of a multicast transmission in the area. <figref idref="DRAWINGS">FIG. 14A</figref> illustrates a method <b>1400</b> that may be performed by a intermediate network entity of a wireless communications system, for determining dynamic bandwidth availability from a network entity of a WCS for use in controlling QoS of a multicast transmission. The method <b>1400</b> may include, at <b>1402</b>, receiving measures of currently available bandwidth from base stations receiving content for a multicast transmission in a multicast area of the WCS. The measures may be received at different times, and may change in response to current conditions. The base stations may be broadcasting a multicast transmission, for example, as an eMBMS. Method <b>1400</b> may further include, at <b>1404</b>, determining a measure of aggregate available bandwidth for the multicast transmission in the multicast area, during the multicast transmission. As used herein, an aggregate available bandwidth indicates a measure of available bandwidth for a multicast area determined by processing network load/bandwidth availability information from base stations in the area, for example, a sum, weighted average, average, minimum, maximum, median, or other aggregate measure of available bandwidth. As such, the aggregate available bandwidth may be used to indicate whether or not bandwidth allocated to one or more multicast services in the area may be increased, decreased, or remain static. Method <b>1400</b> may further include, at <b>1406</b>, indicating a measure of the aggregate available bandwidth for use in controlling a QoS of the multicast transmission.

In addition, <figref idref="DRAWINGS">FIG. 14B</figref> shows further optional elements <b>1450</b> that may be implemented by the intermediate network entity for indicating multicast bandwidth availability. The elements <b>1450</b> may be performed in any operative order, or may be encompassed by a development algorithm without requiring a particular chronological order of performance. Operations are independently performed and not mutually exclusive. Therefore any one of such operations may be performed regardless of whether another downstream or upstream operation is performed. For example, if the method <b>1400</b> includes at least one of the additional operations <b>1450</b>, then the method <b>1400</b> may terminate after the at least one operation, without necessarily having to include any subsequent downstream operation(s) that may be illustrated.

The additional elements <b>1450</b> may include, at <b>1408</b>, the intermediate network entity indicating the aggregate available bandwidth by transmitting an indication of the aggregate available bandwidth to an upstream network entity. The operation <b>1408</b> may be performed during the multicast transmission session or sessions to which the aggregate measure pertains. In the alternative, the additional elements <b>1450</b> may further include, at <b>1410</b>, the intermediate network entity indicating the aggregate available bandwidth by transmitting the indication via a message over a direct interface to the upstream network entity. In the alternative, the additional elements <b>1450</b> may further include, at <b>1412</b>, the intermediate network entity indicating the aggregate available bandwidth by transmitting the indication of the currently available bandwidth via a message relayed through several interfaces to the upstream network entity. In the alternative, the additional elements <b>1450</b> may further include, at <b>1416</b>, the network entity indicating the aggregate available bandwidth by providing an indication of the currently available bandwidth to the upstream network entity using an Operations &amp; Maintenance based indication. The intermediate network entity determining the aggregate available bandwidth and/or performing other operations illustrated in <figref idref="DRAWINGS">FIGS. 14A-B</figref> may be, or may include, a Multicast Coordinating Entity (MCE).

With reference to <figref idref="DRAWINGS">FIG. 15</figref>, there is provided an exemplary apparatus <b>1500</b> that may be configured as an intermediate network entity in a wireless network, or as a processor or similar device for use within the network entity, for determining current bandwidth availability from a network entity of a WCS for use in controlling QoS of a multicast transmission. The apparatus <b>1500</b> may include functional blocks that can represent functions implemented by a processor, software, or combination thereof (e.g., firmware).

As illustrated, in one embodiment, the apparatus <b>1500</b> may include an electrical component or module <b>1502</b> for receiving measures of currently available bandwidth from base stations receiving content for a multicast transmission in a multicast area of the WCS. For example, the electrical component <b>1502</b> may include at least one control processor coupled to a network interface or the like and to a memory with instructions for receiving signals indicating a network load factor, e.g., available bandwidth, from one or more base stations. The electrical component <b>1502</b> may be, or may include, means for receiving measures of currently available bandwidth from base stations receiving content for a multicast transmission in a multicast area of the WCS. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, receiving periodic or episodic messages from multiple base stations in a multicast area over a network link, wherein the messages include the measures of available bandwidth for each base station sending the messages, decoding the messages to obtain the measures, and storing the measures in a computer memory in association with an identifier for the multicast transmission.

The apparatus <b>1500</b> may include an electrical component <b>1504</b> for determining an aggregate available bandwidth for the multicast transmission in the multicast area, during the multicast transmission. For example, the electrical component <b>1504</b> may include at least one control processor coupled to a memory holding instructions for aggregating measures or indications of available bandwidth to determine an aggregate measure of available bandwidth for a multicast area. The electrical component <b>1504</b> may be, or may include, means for determining an aggregate available bandwidth for the multicast transmission in the multicast area, during the multicast transmission. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, aggregating the stored measures of available bandwidth to determine an aggregate available bandwidth for a multicast area, for example by calculating a mean, a sum, a median, or other aggregation, in response to periodic or episodic updates from the base stations. The algorithm may be performed periodically or episodically (e.g., in response to a defined event such as a change in available bandwidth in a multicast area).

The apparatus <b>1500</b> may include an electrical component <b>1506</b> for indicating the aggregate available bandwidth for use in controlling a QoS of the multicast transmission. For example, the electrical component <b>1506</b> may include at least one control processor coupled to a memory holding instructions for signaling the aggregate measure to an upstream entity, using any of the novel operations or interfaces disclosed herein. The electrical component <b>1506</b> may be, or may include, means for indicating the aggregate available bandwidth for use in controlling a QoS of the multicast transmission. Said means may include an algorithm executed by one or more processors. The algorithm may include, for example, generating a message including a measure of the aggregate available bandwidth, and transmitting the message to an entity of component designated for specifying a dynamic QoS based on the aggregate measure. The algorithm may be performed periodically or episodically (e.g., in response to a defined event such as a change in available bandwidth in a multicast area). The apparatus <b>1500</b> may include similar electrical components for performing any or all of the additional operations <b>1450</b> described in connection with <figref idref="DRAWINGS">FIG. 14B</figref>, which for illustrative simplicity are not shown in <figref idref="DRAWINGS">FIG. 15</figref>.

In related aspects, the apparatus <b>1500</b> may optionally include a processor component <b>1510</b> having at least one processor, in the case of the apparatus <b>1500</b> configured as a network entity. The processor <b>1510</b>, in such case, may be in operative communication with the components <b>1502</b>-<b>1506</b> or similar components via a bus <b>1512</b> or similar communication coupling. The processor <b>1510</b> may effect initiation and scheduling of the processes or functions performed by electrical components <b>1502</b>-<b>1506</b>.

In further related aspects, the apparatus <b>1500</b> may include a network interface component <b>1514</b> for communicating with other network entities. The apparatus <b>1500</b> may optionally include a component for storing information, such as, for example, a memory device/component <b>1516</b>. The computer readable medium or the memory component <b>1516</b> may be operatively coupled to the other components of the apparatus <b>1500</b> via the bus <b>1512</b> or the like. The memory component <b>1516</b> may be adapted to store computer readable instructions and data for performing operations of the components <b>1502</b>-<b>1506</b>, and subcomponents thereof, or the processor <b>1510</b>, the additional operations <b>1450</b>, or the methods disclosed herein. The memory component <b>1516</b> may retain instructions for executing functions associated with the components <b>1502</b>-<b>1506</b>. While shown as being external to the memory <b>1516</b>, it is to be understood that the components <b>1502</b>-<b>1504</b> can exist within the memory <b>1516</b>.

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components in a user terminal.

In one or more exemplary designs, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such storage (non-transitory) computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general-purpose or special-purpose computer, or a general-purpose or special-purpose processor. Also, any connection may be properly termed a computer-readable medium to the extent involving non-transitory storage of transmitted signals. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually encode data magnetically, while discs hold data encoded optically. Combinations of the above should also be included within the scope of computer-readable media.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.