APPLICATION-SERVER-ASSISTED PREEMPTIVE MULTICAST BEARER ESTABLISHMENT FOR REAL-TIME LOW-LATENCY APPLICATIONS
The present Application for Patent claims priority to Provisional Application No. 61/581,576, entitled “APPLICATION-SERVER-ASSISTED PREEMPTIVE MULTICAST BEARER ESTABLISHMENT FOR REAL-TIME LOW-LATENCY APPLICATIONS,” filed Dec. 29, 2011, and assigned to the assignee hereof and hereby expressly incorporated by reference herein. The present disclosure relates generally to communication, and more specifically to techniques for supporting group communications on broadcast and multicast services in a cellular communication system. A cellular communication system can support bi-directional communication for multiple users by sharing the available system resources. Cellular systems are different from broadcast systems that can mainly or only support unidirectional transmission from broadcast stations to users. Cellular systems are widely deployed to provide various communication services and may be multiple-access systems such as Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal FDMA (OFDMA) systems, Single-Carrier FDMA (SC-FDMA) systems, etc. A cellular system may support broadcast, multicast, and unicast services. A broadcast service is a service that may be received by all users, e.g., news broadcast. A multicast service is a service that may be received by a group of users, e.g., a subscription video service. A unicast service is a service intended for a specific user, e.g., voice call. Group communications can be implemented using either unicast, broadcast, multicast or a combination of each. As the group becomes larger it is generally more efficient to use multicast services. However, for group communication services that require low latency and a short time to establish the group communication, the setup time of conventional multicast channels can be a detriment to system performance. The disclosure is directed to preemptively establishing a multicast bearer. An embodiment determines whether adding a multicast session to a plurality of multicast bearers will exceed a high bandwidth threshold, requests setup of a new multicast bearer if adding the multicast session will exceed the high bandwidth threshold, and hosts the multicast session on an available one of the plurality of multicast bearers or the new multicast bearer. The accompanying drawings are presented to aid in the description of embodiments of the invention and are provided solely for illustration of the embodiments and not limitation thereof. Aspects of the invention are disclosed in the following description and related drawings directed to specific embodiments of the invention. Alternate embodiments may be devised without departing from the scope of the invention. Additionally, well-known elements of the invention will not be described in detail or will be omitted so as not to obscure the relevant details of the invention. The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. Likewise, the term “embodiments of the invention” does not require that all embodiments of the invention include the discussed feature, advantage or mode of operation. Further, as used herein the term group communication, push-to-talk, or similar variations are meant to refer to a server arbitrated service between two or more devices. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments of the invention. As used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. Further, many embodiments are described in terms of sequences of actions to be performed by, for example, elements of a computing device. It will be recognized that various actions described herein can be performed by specific circuits (e.g., application specific integrated circuits (ASICs)), by program instructions being executed by one or more processors, or by a combination of both. Additionally, these sequence of actions described herein can be considered to be embodied entirely within any form of computer readable storage medium having stored therein a corresponding set of computer instructions that upon execution would cause an associated processor to perform the functionality described herein. Thus, the various aspects of the invention may be embodied in a number of different forms, all of which have been contemplated to be within the scope of the claimed subject matter. In addition, for each of the embodiments described herein, the corresponding form of any such embodiments may be described herein as, for example, “logic configured to” perform the described action. The techniques described herein may be used for various cellular communication systems such as Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal FDMA (OFDMA) systems, Single-Carrier FDMA (SC-FDMA) systems. The terms “system” and “network” are often used interchangeably. A CDMA system may implement a radio technology such as Universal Terrestrial Radio Access (UTRA), cdma2000, etc. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. cdma2000 covers IS-2000, IS-95 and IS-856 standards. A TDMA system may implement a radio technology such as Global System for Mobile Communications (GSM). An OFDMA system 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-OFDM®, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunication System (UMTS). 3GPP Long Term Evolution (LTE) is a release of UMTS that uses E-UTRA, which employs OFDMA on the downlink and SC-FDMA on the uplink UTRA, E-UTRA, UMTS, LTE 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). For clarity, certain aspects of the techniques are described below for LTE, and LTE terminology is used in much of the description below. In the example shown in UEs 120 may be dispersed throughout the system, and each UE may be stationary or mobile. A UE may also be referred to as a mobile station, a terminal, an access terminal, a subscriber unit, a station, etc. 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, etc. A UE may communicate with a Node B via transmissions on the downlink and uplink. The downlink (or forward link) refers to the communication link from the Node B to the UE, and the uplink (or reverse link) refers to the communication link from the UE to the Node B. In Network controller 130 may couple to multiple Node Bs to provide coordination and control for the Node Bs under its control, and to route data for terminals served by these Node Bs. Access network 100 may also include other network entities not shown in The system bandwidth may be partitioned into multiple (K) subcarriers with orthogonal frequency division multiplexing (OFDM). The available time frequency resources may be divided into resource blocks. Each resource block may include Q subcarriers in one slot, where Q may be equal to 12 or some other value. The available resource blocks may be used to send data, overhead information, pilot, etc. The system may support evolved multimedia broadcast/multicast services (eMBMS or E-MBMS) for multiple UEs as well as unicast services for individual UEs. A service for eMBMS may be referred to as an eMBMS service or flow and may be a broadcast service/flow or a multicast service/flow. In LTE, data and overhead information are processed as logical channels at a Radio Link Control (RLC) layer. The logical channels are mapped to transport channels at a Medium Access Control (MAC) layer. The transport channels are mapped to physical channels at a physical layer (PHY). Table 1 lists some logical channels (denoted as “L”), transport channels (denoted as “T”), and physical channels (denoted as “P”) used in LTE and provides a short description for each channel. As shown in Table 1, different types of overhead information may be sent on different channels. Table 2 lists some types of overhead information and provides a short description for each type. Table 2 also gives the channel(s) on which each type of overhead information may be sent, in accordance with one design. The different types of overhead information may also be referred to by other names. The scheduling and control information may be dynamic whereas the system and configuration information may be semi-static. The system may support multiple operational modes for eMBMS, which may include a multi-cell mode and a single-cell mode. The multi-cell mode may have the following characteristics:
The single-cell mode may have the following characteristics:
In general, eMBMS services may be supported with the multi-cell mode, the single-cell mode, and/or other modes. The multi-cell mode may be used for eMBMS multicast/broadcast single frequency network (MBSFN) transmission, which may allow a UE to combine signals received from multiple cells in order to improve reception performance. In the example shown in In general, an eMBMS service may be sent in any number of time frequency blocks. The number of sub frames may be dependent on the amount of data to send and possibly other factors. The M cells may transmit the three eMBMS services 1, 2 and 3 in time frequency blocks that may not be aligned in time and frequency, as shown in As noted in the foregoing, eMBMS services can be used to distribute multicast data to groups and could be useful in group communication systems (e.g., Push-to-Talk (PTT) calls). Conventional applications on eMBMS have a separate service announcement/discovery mechanism. Further, communications on pre-established eMBMS flows are always on even on the air interface. Power saving optimization must be applied to put the UE to sleep when a call/communication is not in progress. This is typically achieved by using out of band service announcements on unicast or multicast user plane data. Alternatively application layer paging channel like mechanism may be used. Since the application layer paging mechanism has to remain active, it consumes bandwidth on the multicast sub-frame which could be idle in the absence of the paging mechanism. Additionally, since the multicast sub-frame will be active while using the application layer paging, the remainder of the resource blocks within the sub frame cannot be used for unicast traffic. Thus the total 5 Mhz bandwidth will be consumed for the sub frame for instances when application layer paging is scheduled without any other data. In accordance with various embodiments disclosed herein some of the downlink channels related to eMBMS will be further discussed, which include. MCCH: Multicast Control Channel; MTCH: Multicast Traffic Channel; MCH: Multicast Channel; and PMCH: Physical Multicast Channel. It will be appreciated that multiplexing of eMBMS and unicast flows are realized in the time domain only. The MCH is transmitted over MBSFN in specific sub frames on physical layer. MCH is a downlink only channel. A single transport block is used per sub frame. Different services (MTCHs) can be multiplexed in this transport block, as will be illustrated in relation to To achieve low latency and reduce control signaling, one eMBMS flow (562, 564) can be activated for each service area. Depending on the data rate, multiple multicast flows can be multiplexed on a single slot. PTT UEs (targets) can ignore and “sleep” between scheduled sub frames and reduce power consumption when no unicast data is scheduled for the UE. The MBSFN sub frame can be shared by groups in the same MBSFN service area. MAC layer signaling can be leveraged to “wake-up” the application layer (e.g., PTT application) for the target UEs. Embodiments can use two broadcast streams, each a separate eMBMS flow over an LTE broadcast flow, with its own application level broadcast stream and its own (multicast IP address) for each defined broadcast region 502, 501 (e.g., a subset of sectors within the network). Although illustrated as separate regions, it will be appreciated that the broadcast areas 502, 501 may overlap. In LTE, the control and data traffic for multicast is delivered over MCCH and MTCH, respectively. The Medium Access Control Protocol Data Units (MAC PDUs) for the UEs indicate the mapping of the MTCH and the location of the a particular MTCH within a sub frame. An MCH Scheduling Information (MSI) MAC control element is included in the first subframe allocated to the MCH within the MCH scheduling period to indicate the position of each MTCH and unused subframes on the MCH. For eMBMS user data, which is carried by the MTCH logical channel, MCH scheduling information (MSI) periodically provides at lower layers (e.g., MAC layer information) the information on decoding the MTCH. The MSI scheduling can be configured and according to this embodiment is scheduled prior to MTCH sub-frame interval. At Node B 110, a transmit processor 620 may receive data for unicast services and data for broadcast and/or multicast services from a data source 612 (e.g., directly or indirectly from application server 150). Transmit processor 620 may process the data for each service to obtain data symbols. Transmit processor 620 may also receive scheduling information, configuration information, control information, system information and/or other overhead information from a controller/processor 640 and/or a scheduler 644. Transmit processor 620 may process the received overhead information and provide overhead symbols. A transmit (TX) multiple-input multiple-output (MIMO) processor 630 may multiplex the data and overhead symbols with pilot symbols, process (e.g., precode) the multiplexed symbols, and provide T output symbol streams to T modulators (MOD) 632 At UE 120, antennas 652 On the uplink, at UE 120, data from a data source 678 and overhead information from a controller/processor 690 may be processed by a transmit processor 680, further processed by a TX MIMO processor 682 (if applicable), conditioned by modulators 654 Controllers/processors 640 and 690 may direct the operation at Node B 110 and UE 120, respectively. Scheduler 644 may schedule UEs for downlink and/or uplink transmission, schedule transmission of broadcast and multicast services, and provide assignments of radio resources for the scheduled UEs and services. Controller/processor 640 and/or scheduler 644 may generate scheduling information and/or other overhead information for the broadcast and multicast services. Controller/processor 690 may implement processes for the techniques described herein. Memories 642 and 692 may store data and program codes for Node B 110 and UE 120, respectively. Accordingly, group communications in the eMBMS environment can be accomplished in accordance with the various embodiments disclosed herein, while still remaining compliant with the existing standards. Referring to Referring to Referring to Referring to Referring to Referring to For group communication services that require low latency and a short time to establish the group communication, the setup time of conventional multicast channels can be detrimental to system performance. A conventional eMBMS system, for example, only allows static or semi-static bearer setup. For low latency applications, if the bearers are setup during the call initiation, the call latency will be unacceptable. To avoid this, the bearers may be setup from the time the service is operational based on statistical traffic patterns. Further, MCCH propagation issues prevent on-demand bearer establishment for low latency applications. Typically, bearer sizing is performed to accommodate high traffic periods, but since the eMBMS bearers are always held in one state, even during periods of inactivity, these bearers are underutilized. Moreover, the bearers take away the useable network capacity that could be used for unicast users. The various embodiments are directed to application server-assisted dynamic multicast bearer management in an MBMS system with semi-static bearer allocation capability for real-time low-latency applications. The various embodiments allocate the minimum number of bearers needed to support the average call rate in a given area, and enable the network to preemptively add bearers to the existing bearer pool by tracking whether the bearers reach a traffic threshold near their capacity, and upon detecting that the bearers reach this threshold, triggering the network to setup another bearer. Thus, the various embodiments establish the bearer before the need arises and allow reasonable time for the UEs to detect the availability of the bearer. Similarly, when the traffic is below a set threshold and there is an unused bearer, the bearer is deactivated. The various embodiments thus allow low latency applications to meet the call setup latency target while saving over-the-air (OTA) and network capacity wastage by using multicast resources (e.g., new bearers) only when needed. Further, the various embodiments are technology agnostic and provide bearer management control to the application layer. The various embodiments update the MCCH with the new bearer information. There is generally a delay in propagating MCCH updates. Since the new bearer is activated in anticipation of the data stream, however, the UEs have sufficient time (e.g. at least 10 seconds) to detect the MCCH update and identify the additional bearer. An MCCH has an MCCH modification period parameter that can be set to either 512 frames (5.12 seconds), or 1024 frames (10.24 seconds). An MCCH change is signaled first through the PDCCH for a full modification period. A multicast radio network temporary identifier (M-RNTI) may be used to signal updates for up to eight MCCHs. MCCH periodicity is half of the smallest MCCH repetition period (a minimum of four frames and a maximum of 128 frames). Modification period starts are such that the SFN (single frequency network) mod of the modification period is equal to 0. If adding the new session will not exceed the high-capacity threshold, at 1220, the application server 550 proceeds with hosting the session without requesting a new bearer setup and adds the session bandwidth to the existing aggregate bandwidth total for the area. At 1225, when the session ends, the application server 550 deducts the session bandwidth from the existing aggregate bandwidth total for the service area 500. At 1230, the application server 550 determines whether the new aggregate bandwidth total is less than a low-capacity threshold and whether any bearers are free of traffic. The low-capacity threshold should be set at a capacity level where the current network traffic could be handled by the remaining bearers. If the aggregate bandwidth is less than the low-capacity threshold and there is at least one bearer free of traffic, at 1235, the application server 550 deactivates the at least one bearer that has no traffic. At 1240, the application server 550 continues monitoring the aggregate bandwidth for the area, and may return to 1210 when a request for a new session is received. If at 1230, however, the application server 550 determines that the aggregate bandwidth is not less than the low-capacity threshold and/or there is not at least one bearer free of traffic, then at 1240, the application server 550 continues monitoring the aggregate bandwidth for the MBMS area 500. If at 1215, the application server 550 determines that adding the new session will exceed the high-capacity threshold, then at 1245, the application server 550 determines whether the new session will exceed the bearer's capability. If at 1245 the application server 550 determines that the new session will not exceed the bearer's capability, then at 1250, the application server 550 requests the network gateway/BM-SC, such as BM-SC 536, to add another bearer by provisioning the downstream network components. At 1255, upon receipt of a successful bearer activation response from the network gateway/BM-SC 536, the application server 550 adds the new bearer to the pool of bearers used for determining session admission. The method then proceeds to 1220. If at 1245 the application server 550 determines that the new session will exceed the bearer's capability, then at 1260, the application server 550 informs the session originator, such as UE 520, that the session will be delayed. The method then proceeds to 1250. When adding a new session to a bearer at 1220, the application server 550 first attempts to add the session to one of the default bearers allocated in 1205, regardless of whether a new bearer was activated in response to the new session being requested. If none have the necessary capacity, the application server 550 adds the session to a newly activated bearer instead. Since the application server 550 adds new sessions to the default bearers allocated in 1205 first and up to their capacity, any additional bearers added to the pool in 1255 will empty first, and thus be deactivated in 1235. That is, the network traffic is not distributed over all activated bearers, but rather concentrated on the default bearers, allowing for the deactivation of any extra bearers in 1235. Table 586 shows that there are a total of five simultaneous sessions allowed on a bearer, that there are six current simultaneous sessions, and that there are two active bearers. It will be apparent that the values stored in table 586 are examples, and the disclosure is not limited to these values. When the bandwidth usage for a session exceeds the high-capacity threshold 582, the application server 550 sends a new bearer activation message requesting that an additional bearer be setup, as described above with reference to The system identifies certain UEs for periodic reporting of multicast channel activity, such as UE 520. The UE 520 monitors the multicast channel (for eMBMS, UE 520 would monitor the MCCH and the MCH) and can use a unicast channel to report the current number of media streams for each multicast bearer. From these periodic reports, the application server 550 can determine the need to preemptively establish an additional bearer or deactivate an unused bearer by comparing the network traffic to the high threshold and/or the low threshold, as discussed above with reference to Referring to 1215 of Those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed 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 invention. The methods, sequences and/or algorithms described in connection with the embodiments disclosed 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. Accordingly, an embodiment of the invention can include a computer readable media embodying a method for group communications over evolved multimedia broadcast/multicast services (eMBMS). Accordingly, the invention is not limited to illustrated examples and any means for performing the functionality described herein are included in embodiments of the invention. While the foregoing disclosure shows illustrative embodiments of the invention, it should be noted that various changes and modifications could be made herein without departing from the scope of the invention as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the embodiments of the invention described herein need not be performed in any particular order. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated. The disclosure is directed to preemptively establishing a multicast bearer. An embodiment determines whether adding a multicast session to a plurality of multicast bearers will exceed a high bandwidth threshold, requests setup of a new multicast bearer if adding the multicast session will exceed the high bandwidth threshold, and hosts the multicast session on an available one of the plurality of multicast bearers or the new multicast bearer. 1. A method for preemptively establishing a multicast bearer, comprising:
determining whether adding a multicast session to a plurality of multicast bearers will exceed a high bandwidth threshold; if adding the multicast session will exceed the high bandwidth threshold, requesting setup of a new multicast bearer; and hosting the multicast session on an available one of the plurality of multicast bearers or the new multicast bearer. 2. The method of adding the multicast session to a multicast bearer that already has one or more multicast sessions established. 3. The method of when one of the one or more multicast sessions ends, deducting a bandwidth of the one of the one or more multicast sessions from an aggregate bandwidth of a pool of multicast bearers comprising the plurality of multicast bearers; determining whether the aggregate bandwidth falls below a low bandwidth threshold; and if the aggregate bandwidth falls below the low bandwidth threshold, deactivating one of the plurality of multicast bearers or the new multicast bearer. 4. The method of 5. The method of receiving a request to add the multicast session; and in response to the receiving, performing the determining. 6. The method of determining whether adding the multicast session will exceed the bearer capability; and if adding the multicast session will exceed the bearer capability, sending a notification to an originator of the multicast session that setup of the multicast session is delayed. 7. The method of determining whether adding the multicast session will exceed the bearer capability; and if adding the multicast session will not exceed the bearer capability, requesting the setup of the new multicast bearer. 8. The method of in response to activation of the new multicast bearer, adding the new multicast bearer to a pool of multicast bearers comprising the plurality of multicast bearers. 9. The method of adding a bandwidth of the multicast session to an aggregate bandwidth of the pool of multicast bearers. 10. The method of receiving periodic reports from selected user devices, the reports including an indication of an amount of traffic on the plurality of multicast bearers and the new multicast bearer. 11. The method of determining that the multicast session has ended based on the periodic reports. 12. The method of when the multicast session ends, deducting a bandwidth of the multicast session from an aggregate bandwidth of a pool of multicast bearers comprising the plurality of multicast bearers; determining whether the aggregate bandwidth falls below a low bandwidth threshold; and if the aggregate bandwidth falls below the low bandwidth threshold, deactivating one of the plurality of multicast bearers or the new multicast bearer. 13. The method of determining whether one of the plurality of multicast bearers or the new multicast bearer is free of traffic; and if one of the plurality of multicast bearers or the new multicast bearer is free of traffic, deactivating the one of the plurality of multicast bearers or the new multicast bearer. 14. An apparatus for preemptively establishing a multicast bearer, comprising:
logic configured to determine whether adding a multicast session to a plurality of multicast bearers will exceed a high bandwidth threshold; logic configured to request setup of a new multicast bearer if adding the multicast session will exceed the high bandwidth threshold; and logic configured to host the multicast session on an available one of the plurality of multicast bearers or the new multicast bearer. 15. The apparatus of logic configured to add the multicast session to a multicast bearer that already has one or more multicast sessions established. 16. The apparatus of logic configured to deduct, when one of the one or more multicast sessions ends, a bandwidth of the one of the one or more multicast sessions from an aggregate bandwidth of a pool of multicast bearers comprising the plurality of multicast bearers; logic configured to determine whether the aggregate bandwidth falls below a low bandwidth threshold; and logic configured to deactivate one of the plurality of multicast bearers or the new multicast bearer if the aggregate bandwidth falls below the low bandwidth threshold. 17. The apparatus of 18. The apparatus of logic configured to receive a request to add the multicast session; and logic configured to perform the determining in response to the receiving. 19. The apparatus of logic configured to determine whether adding the multicast session will exceed the bearer capability; and logic configured to send a notification to an originator of the multicast session that setup of the multicast session is delayed if adding the multicast session will exceed the bearer capability. 20. The apparatus of logic configured to determine whether adding the multicast session will exceed the bearer capability; and logic configured to request the setup of the new multicast bearer if adding the multicast session will not exceed the bearer capability. 21. The apparatus of logic configured to add the new multicast bearer to a pool of multicast bearers comprising the plurality of multicast bearers in response to activation of the new multicast bearer. 22. The apparatus of logic configured to add a bandwidth of the multicast session to an aggregate bandwidth of the pool of multicast bearers. 23. The apparatus of logic configured to receive periodic reports from selected user devices, the reports including an indication of an amount of traffic on the plurality of multicast bearers and the new multicast bearer. 24. The apparatus of logic configured to determine that the multicast session has ended based on the periodic reports. 25. The apparatus of logic configured to deduct, when the multicast session ends, a bandwidth of the multicast session from an aggregate bandwidth of a pool of multicast bearers comprising the plurality of multicast bearers; logic configured to determine whether the aggregate bandwidth falls below a low bandwidth threshold; and logic configured to deactivate one of the plurality of multicast bearers or the new multicast bearer if the aggregate bandwidth falls below the low bandwidth threshold. 26. The apparatus of logic configured to determine whether one of the plurality of multicast bearers or the new multicast bearer is free of traffic; and logic configured to deactivate the one of the plurality of multicast bearers or the new multicast bearer if one of the plurality of multicast bearers or the new multicast bearer is free of traffic. 27. An apparatus for preemptively establishing a multicast bearer, comprising:
means for determining whether adding a multicast session to a plurality of multicast bearers will exceed a high bandwidth threshold; means for requesting setup of a new multicast bearer if adding the multicast session will exceed the high bandwidth threshold; and means for hosting the multicast session on an available one of the plurality of multicast bearers or the new multicast bearer. 28. A non-transitory computer-readable medium for preemptively establishing a multicast bearer, comprising:
at least one instruction to determine whether adding a multicast session to a plurality of multicast bearers will exceed a high bandwidth threshold; at least one instruction to request setup of a new multicast bearer if adding the multicast session will exceed the high bandwidth threshold; and at least one instruction to host the multicast session on an available one of the plurality of multicast bearers or the new multicast bearer. CLAIM OF PRIORITY UNDER 35 U.S.C. §119
FIELD OF DISCLOSURE
BACKGROUND
SUMMARY
BRIEF DESCRIPTION OF THE DRAWINGS
DETAILED DESCRIPTION
Broadcast Control BCCH L Carry system information Channel Broadcast Channel BCH T Carry master system Information eMBMS Traffic MTCH L Carry configuration information Channel for eMBMS services. Multicast Channel MCH T Carry the MTCH and MCCH Downlink Shared DL-SCH T Carry the MTCH and other Channel logical channels Physical Broadcast PBCH P Carry basic system information Channel for use in acquiring the system. Physical Multicast PMCH P Carry the MCH. Channel Physical Downlink PDSCH P Carry data for the DL-SCH Shared Channel Physical Downlink PDCCH P Carry control information for the Control Channel DL-SCH System BCCH Information pertinent for communicating Information with and/or receiving data from the system. Configuration MCCH Information used to receive the Information Information services, e.g., MBSFN Area Configuration, which contains PMCH configurations, Service ID, Session ID, etc. Control PDCCH Information used to receive Information Information transmissions of data for the services, e.g., resource assignments, modulation and coding schemes, etc.