For many MBMS services, it will be necessary to provide alternative means for the UE to access the service without using MBMS bearer capabilities. This is required, for example, after completion of the MBMS session for a file download to permit errors in the file to be corrected; to permit the network to charge for a successful download; to pass a decrypt key to the UE; etc. It may also be useful in cases where all or part of an MBMS transmission has been missed due to the UE being out of coverage, switched off, etc. Care is needed to ensure that such alternative access mechanisms do not create traffic that overloads the network (radio, RNC, BSC, SGSN, GGSN and BM-SC). In the case that such alternative access requires direct interaction between the UE and a network server, one way for this load to be distributed is for the BM-SC to distribute to each UE, at activation time, one or more server addresses (from a group of addresses), along with parameter(s) that are used to generate a random time dispersion of the requests.

For Joining that is triggered by a service announcement (e.g. CBS or MBMS), then the service announcement needs to be able to contain parameters to help avoid overload in the SGSN, GGSN and BM-SC. The UE uses the defined parameters in the service announcement to randomly select the time at which to join the service. Hence the BM-SC needs to be able to generate the parameters and needs to be able to get them sent to the UE in the service announcement.

In networks with multiple accesses, e.g. GERAN and UTRAN for GPRS, users may in some situations experience problems in receiving MBMS services. These situations include:

• an operator that has chosen to provide a service on one access only (e.g. only on GERAN), and where a UE is camping on the wrong access (i.e. on UTRAN in the previous example) when an MBMS session is started. This UE may miss the MBMS content, as the MBMS architecture doesn't provide any mechanism for paging coordination, etc.
• an operator that has chosen to provide a service with different QoS levels e.g. on GERAN and UTRAN (see clause 5.1.5.2). A UE that is changing access type during an ongoing MBMS session may not be able sort the situation out and receive the MBMS content correctly.

"MBMS operation on Demand" (MooD) allows certain content that is initially delivered over the unicast network to be turned into an MBMS User Service, in order to efficiently use network resources when the traffic exceeds a certain threshold. Two types of MBMS operation on Demand are described in TS 26.346: UE-Elected and Network-Elected offloading. In both types, there could be a network proxy/server to detect whether unicast traffic volume for the same service or content exceeds a certain threshold, and to indicate such occurrence to the BM-SC to enable MBMS offloading. The MooD feature is optional. UEs that support MooD functionality support handling of the MooD redirection message. To assist the MooD decision, the network proxy/server may obtain UE location by many possible means as per the operator's policy, including use of the current location field in the MooD Header. MooD is supported for E-UTRAN and UTRAN accesses.

Enhanced TV services over E-UTRAN enables operators and service providers to deliver TV services from broadcasters as well as 3rd party service providers. The separation of access to MBMS transport services from MBMS user services allow separate content delivery and transport services from the operators. This is achieved by:

• A broadcast component where mechanisms to enable decoupling of content, MBMS service and MBMS transport, allowing the system to offer: MBMS transport only, a shared MBMS network between operators, broadcast only TV service to devices with no operator subscription.
• A unicast component via PDN connectivity is achieved through operator's EPC network, in which operator subscription for TV service may be achieved via dedicated APN.
• Enable mechanisms for broadcast/unicast fall-back support, consumption-based switching between unicast/broadcast are supported.
• Support standardised interface between BM-SC and the content provider, as defined in TS 26.348, in order to facilitate both transport and user services delivery for TV services via MBMS (for broadcast) and EPC (for unicast).

There are 2 MBMS Service Types considered for TV service:

• MBMS transport only mode:
  • The 3GPP network provides only transport of data/TV content in a transparent manner.
  • The 3rd party content provider's signalling and data transferred via MBMS bearer(s) are transparent to BM-SC and the MBMS bearer service.
  • All other service aspects, e.g. decision of whether to send data over broadcast or unicast, is not within 3GPP network, and assumed to be performed by application server.
• MBMS full service mode:
  • 3GPP MBMS system provides full service layer capability.
  • BM-SC is aware of the content stream and is capable of transforming the content stream into 3GPP compliant stream.
  • BM-SC can perform decision on whether to switch an MBMS user service between broadcast or unicast service.