Monday, 20 July 2009

eMBMS: evolved Multimedia Broadcast Multicast Control

I spent a lot of time working on MBMS but operators decided not to roll out the technology. It was killed in its infancy. Earlier I blogged that MBMS wont be present in Release 8 but now there is interest in some quarters about MBMS being present in Release 9.

As I have mentioned earlier, the main advantage of MBMS over other TV technologies is that no additional infrastructure is required, the same technology and spectrum is used as for the 3G/LTE case and user interaction is possible thereby involving participation.

At the moment, I was only able to see eMBMS information in 3GPP TS 36.300 but I am sure more is on way soon. Section 15 of 36.300 is dedicated to eMBMS information.

In E-UTRAN, MBMS can be provided with single frequency network mode of operation (MBSFN) only on a frequency layer shared with non-MBMS services (set of cells supporting both unicast and MBMS transmissions i.e. set of "Unicast/MBMS mixed cells").

MBMS reception is possible for UEs in RRC_CONNECTED or RRC_IDLE states. Whenever receiving MBMS services, a user shall be notified of an incoming call, and originating calls shall be possible. ROHC is not supported for MBMS.

So where does it fit in the overall architecture?

Multi-cell/multicast Coordination Entity (MCE): The MCE is a logical entity – this does not preclude the possibility that it may be part of another network element – whose functions are the allocation of the radio resources used by all eNBs in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation. Besides allocation of the time/ frequency radio resources this also includes deciding the further details of the radio configuration e.g. the modulation and coding scheme. The MCE is involved in MBMS Session Control Signalling. The MCE does not perform UE - MCE signalling. When the MCE is part of another network element, an eNB is served by a single MCE.

E-MBMS Gateway (MBMS GW): The MBMS GW is a logical entity – this does not preclude the possibility that it may be part of another network element – that is present between the BMSC and eNBs whose principal functions is the sending/broadcasting of MBMS packets to each eNB transmitting the service. The MBMS GW uses IP Multicast as the means of forwarding MBMS user data to the eNB. The MBMS GW performs MBMS Session Control Signalling (Session start/stop) towards the E-UTRAN via MME.

“M3” Interface: MCE – MME: An Application Part is defined for this interface between MME and MCE. This application part allows for MBMS Session Control Signalling on E-RAB level (i.e. does not convey radio configuration data). The procedures comprise e.g. MBMS Session Start and Stop. SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.

“M2” Interface: MCE – eNB: An Application Part is defined for this interface, which conveys at least radio configuration data for the multi-cell transmission mode eNBs and Session Control Signalling. SCTP is used as signalling transport i.e. Point-to-Point signalling is applied.

“M1” Interface: MBMS GW – eNB: This interface is a pure user plane interface. Consequently no Control Plane Application Part is defined for this interface. IP Multicast is used for point-to-multipoint delivery of user packets.

It is not precluded that M3 interface can be terminated in eNBs. In this case MCE is considered as being part of eNB. However, M2 should keep existing between the MCE and the corresponding eNBs. This is depicted in Figure above which depicts two envisaged deployment alternatives. In the scenario depicted on the left MCE is deployed in a separate node. In the scenario on the right MCE is part of the eNBs.

It will be possible to have an MBMS Dedicated cell or a MBMS/Unicast mixed cell. For transmission, it will be possible to have a Single-cell transmission or Multi-cell transmission. Multi-cell transmission where the safe information is sent synchronously over multiple cells will have an advantage of receivers being able to combine information from Multiple cells and also to roam in the area of transmission seamlessly.

More information when detailed specs are available.


hassan said...


really useful information about E-MBMS

If possible could you provide some resources and references for these information.

especially about the MCS and typical deployment scenarios so far in commercial networks.



T.L said...

Will MBMS/eMBMS get market position later? doubt that...

Maqbool Aliani said...

why did it die in its infancy?

Zahid Ghadialy said...

MBMS dies in its infancy not eMBMS.

MBMS was part of 3G Release-6 and worked on top of UMTS.

eMBMS is part of 3G Release-9 and will work on LTE networks.

eMBMS is still alive and kicking though I am not sure of its progress.

Anonymous said...

Can you please tell the protoccol for SG-mb interface(BM-SCand eMBMS GW) ?Nothing has been seen in the specs abt this?

Anonymous said...

More info about some business models here:

>>Can you please tell the protoccol for SG-mb interface(BM-SCand eMBMS GW)

Not standardized yet. This will turn out to be an internal interface unless two influential companies push for externalizing and defining the std.

Raúl said...

Hi Zahid,

I would like to know where are allocated the entities PDN GW, eMBMS GW and eBMSC between EPC and public internet.

Thanks a lot.


Zahid Ghadialy said...

Hi Raul, see the post here, does this help?

Anonymous said...

How the legacy SMS Cell broadcast (2G and 3G), used by some operators around the world, is preserved in LTE Release 8?

Pushpak Yadav said...

why we are using MBMS-GW Especially in
MBMS instead of S-GW & P-GW

Anonymous said...

Hello, if i understand correctly the throughput is badly limited by the frame structure and even if you use all subframes for mbms you will be still limited to several mb/s per cell

Zahid Ghadialy said...

You can easily have 8 channels or 4 HD channels. Also the operators are using eMBMS not only for TV but for other services too.