4G/LTE - MBSFN

MBSFN (Multicast Broadcase Single Frequency Network)

With the introduction of mobile device and mobile network, one thing a lot of mobile users wanted to have was "I want to see TV (Movies etc on my mobile phone.". A set of first solutions to this requirement was DVB-H/DVB-T,  DMB, ISDB-T, MediaFLO etc. These technlogies are still very widely used in some contries. There are many mobile device supporting both normal mobile phone capability and the mobile TV reception functionality. So for the users point of view, it was very good since they can have both mobile phone and TV on a single device with a small extra cost. But for the service provider's point of view, it is not that simple story. Mobile phone network and mobile TV network is totally different and separate. So it would be pretty big investment to deploy the network for mobile TV.

Then many people start having another idea saying "Why don't we prvide this kind of mobile TV (Broadcasting/Multicasting) service through the existing mobile phone network/technology ?".

The intial implementation of this idea was MBMS (Multimedia Broadcast Multicast Services) in UMTS and its LTE counter part is MBSFN (Multimedia Broadcast Single Frequency network or Multicase Broadcast Single Frequency Network).

Overall concept is as follows. A eNodeB can transmit the same data (idential data) to multiple UE simulteneously. In some case, multiple eNodeB can transmit the identical data simultaneously so that UE can receive the same data from multiple eNodeBs.

eMBMS Implementation Overview

To implement eMBMS, we need to tweak (or implement new feature) across almost all layers from PHY to Core Network. Following shows some of key feature on each layer that need to be implemented on each layer. I would not explan the details on each of these items. The details will be described in following sections.

Network Components for MBSFN(eMBMS)

For implementing eMBMS, a couple of components are added in the core network side as shown below. MCE, MBSFN Gateway and BM-SC are those components. (Refer to 36.300 15.1.1 E-MBMS Logical Architecture for details).

MCE (Multi-call/multicast Coordination Entity) : This is a logical entity and, physically it can be integrated into another network element. It has following functionality,

• admission control and allocation of the radio resources for all eNB in the MBSFN area for multicell MBMS transmission.
• counting and acquisition of counting results for MBMS services.
• controlling resumption of MBMS session within MBSFN area
• controlling suspension of MBMS session within MBSFN area
• Involved in MBMS Session Control Signaling
• NOT perform UE-MCE signaling

MBMS Gateway(GW) : This is a logical entity and, physically it can be integrated into another network element. It has following functionality,

• Sending/broadcasting of MBMS packets to each eNB transmitting the service
• Uses IP multicast as the means of forwarding MBMS user data to the eNB
• Performs MBMS Session Control Signalling (Session start/update/stop) towards the E-UTRAN via MME

M3 interface : Interface between MME-MCE

• allows for MBMS Session Control Signaling on E-RAB level (e.g, MBMS Session Start/Stop)
• does not convey radio configuration data
• SCTP is used as signalling transport (e.g, Point-to-Point signaling)

M2 interface : Interface between MCE-eNB

• allows for MBMS Session Control Signaling and Radio Configuration data
• SCTP is used as signalling transport (e.g, Point-to-Point signaling)

M1 interface : Interface between MBMS GW-eNB

• purely a user plane interface
• No Control Plane Application Part is defined for this interface
• IP multicast is used for point-to-multipoint multipoint delivery of user packets

Session Start/Stop

MBSFN Access Network Structure/Definition

Followings are common terminologies you need to understand in MBSFN/MBMS. (Based on 3GPP TS 36.300 Chapter 15)

MBSFN Synchronization Area : This refers to an area of the network where all eNodeBs can be synchronized and perform MBSFN transmissions.

• MBSFN Synchronization Area are capable of supporting one or more MBSFN Area
• One eNB can only belong to one MBSFN Synchronization Area on a given frequency layer.
• MBSFN Synchronization Area are independent from the definition from the definition of MBMS Service Area

MBSFN Transmission/Transmission in MBSFN mode : This refers to a simulcast transmission technique realized by transmission of identical waveforms at the same time from multiple cells. An MBSFN Transmission from multiple cells within the MBSFN Area is seen as a single transmission by a UE.

MBSFN Area : This is an area which consists of a group of cells within an MBSFN Synchronization Area, which are co-ordinated to achieve an MBSFN Transmission.

• Except for the MBSFN Area Reserved Cells, all cells within an MBSFN Area contribute to the MBSFN Transmission and advertise its availability.
• The UE many only need to consider a subset of the MBSFN areas that are configured, i.e when it knows which MBSFN area applies for the services it wants to recieve.

MBSFN Area Reserved Cell : This refers to a cell within a MBSFN Area which does not contribute to the MBSFN Transmission. These cells may transmit data for other services but it should not transmit it in too high power that may interfere other MBSFN cell. So it should control its transmission power very carefully.

Synchronization Sequence : This refer to a sequence of MBSFN service which has the same duration and start time which is configured in the BM-SC and the MCE. Each SYNC PDU contains a time stamp which indicates the start time of the synchronisation sequence.

Syncronizsation Period : This refer to a duration which multiple synchronized sequence maintain the synchronization. The synchronization period provies the time reference for the indication of the start time of each synchronisation sequence.

Radio Channels for MBSFN(eMBMS)

LTE uses totally separate channel (logical cand transport channel) for MBSFN. As you may guess, it uses MCCH for control information and MTCH for data transmission. The information carried by MCCH includes subframe allocation and MCS(Modulation Coding Scheme).

RLC mode for MBSFN is UM (It is understandable since MBSFN is for broadcasting and there is no feedback from the reciever).

One or Several MTCH and one MCCH are multiplexed onto MCH by MAC layer.

MIMO is not defined for PMCH.

MCCH Implementation Structure/ Information in MCCH

Following is the overall principles for MCCH implementation listed 36.300 15.3.5.

< MCCH and MBSFN Area association >

• One MBSFN Area is associated with one MCCH and one MCCH corresponds to one MBSFN Area
• MCCH is transmitted by all cells within an MBSFN Area, except the MBSFN Area Reserved Cells

< MCCH Transmission >

• MCCH is transmitted by all cells within an MBSFN Area, except the MBSFN Area Reserved Cells
• MCCH is transmitted by RRC (SIB) every MCCH repetition period
• MCCH uses a modification period

< Notification Mechanism >

When MCCH gets modified due to either Session Start or presense of an MBMS counting request message, Network needs to inform UE of the modification. For this, network is using special notification mechanism summarized below.

• The notification is sent periodically throughout the modification period preceding the change of MCCH, in MBSFN subframes configured for notification.
• The DCI format 1C with M-RNTI is used for notification.
• This DCI has one field (8 bits) named 'MCCHChangeNotification' which indicate the one or more MBSFN Areas in which the MCCH changes.

< UE side procedure >

• The UE monitors more than one notification subframe per modification period
• When the UE recieves a notification, it acquires the MCCH at the next modification period boundary
• If a changes in MCCH is not announced by the notification mechanism, UE can still detect the changes by MCCH monitoring at the modification period.

MBSFN Signalling on BCCH

Following summary comes from 36.300 15.3.6 and further details follows the summary.

• BCCH only tell you where MCCH can be found, but does not tellyou whether any service is available now or not (SIB 2)
• For each MCCH, BCCH notifies UE of following informations (SIB 13)
• the scheduling of the MCCH for multi-cell transmission on MCH
• MCCH modification period, repetition period radio frame offset, subframe allocation
• an MCS which applies to the subframes indicated for MCCH scheduling and for the first subframe of all MSPs(MCH Scheduling Period) in that MBSFN Area
• For the notification commonly used for all MCCH (SIB 13)
• configures the position of the MCCH change notification subframe and the number of occasions monitored by the UE
• indicatesthe mapping between the PDCCH bit(s) carried in the notification and the MCCH(s)

< MBSFN Subframe Configuration >

Since the MBSFN data is carried by the same physical channel which is used for mobile comunication, we have to use carefull scheduling for MBSFN so that it would not interfer normal mobile communication. This physical layer scheduling is specified in SIB2 as shown below.

Radio Frame meeting the following equation is allocated for MBSFN.

SFN mod radioframeAllocationPeriod = radioframeAllocationOffset

Subframes that is allocated for MBSFN within the MBSFN Frame is determined by a bitmap as shown below.

Following is an example of MBSFN SFN, Subframe allocation. Try with following parameters and See if you come out with the same result as mine.

< MBSFN Neighbour Cell Configuration >

< MBSFN Control Channel Information >

As I explained above, MBSFN is using two different channel : MCCH and MTCH. As you may easily guess, MTCH carry the MBMS traffic data and MCCH is for conveying the control message.  You learned that the MBSFN physical frame and broadcasting cycle is defined in SIB2, but there is no MBSFN control channel information in SIB2. To carry the MBSFN control channel information, 3GPP defined a separate SIB : SIB13 and major component of SIB13 is as shown below.

MBSFN control channel information and MBSFN Area specification is specified by SIB13 as shown below.

MBSFN Signalling on MCCH

There are several triggers that let UE aquire MCCH message which is summarized as below. (Refer to 36.331 5.8.2.3 for further information)

Once any one of the trigger is set, UE have to aquire MCCH and decode following informations. (Refer to 36.331 6.2.2, 6.3.7)

commonSF-Alloc : It indicates the subframes allocated to the MBSFN area

commonSF-AllocPeriod : It indicates the period during which resources corresponding with field commonSF-Alloc are divided between the (P)MCH that are configured for this MBSFN area. Subfram allocation patterns defined by commonSF-Alloc repeat continously during this period.

MAC Implementation for MCH

New LCID is specified for MCH as shown below.

MAC PDU structure for MCH is defined as shown below.

MBSFN Subframe Structure

MBSFN subframe has different structure from the normal (non-MBSFN) subframe as shown below. The first one or two OFDM Symbol in MBSFN subframe is allocated for control region as in normal subframe. But the number of symbols for the control region may or may not be same as non-MBSFN subframe. Location of Reference Signal for MBSFN is different from Non-MBSFN Reference Signal as shown below.

The number and locations of MBSFN subframes within a specific radio frame is determined by Network and is broadcasted to UE via SIB.

Multi-Cell Transmission

This is based on 36.300 15.3.3.

Muli-Cell Transmission refers to Synchronous transmission of MBMS within a MBSFN Area and it has following characteristics.

• Combining of MBMS transmission from multiple cells is supported.
• MCE schedules each MCH
• Only single transmission is done for MCH, it means that HARQ repetition is not supported and RLC quick repeat is not supported.
• Single Transport Block is used for TTI for MCH and that TB uses all the MBSFN resources in that subframe.
• MTCH and MCCH uses RLC-UM mode
• There is special MAC subheader to indicate LCID for MTCH and MCCH
• MBSFN Synchronization Area, MBSFN Area and MBSFN cells are semi-statically configured
• MTCH and MCCH can be multiplexed on the same MCH and are mapped on MCH for p-t-m(Point to Multipoint) transmission.

Reference - 3GPP

Reference - 3GPP Implementation 

• 36.331 5.8.1.3 MCCH information validity and notification of changes

Reference - 3GPP Test Specificaiton

Following is from 36.521-1 (V11.2.0 (2013-10))

• 8.2.1.1.2 FDD PDSCH Single Antenna Port Performance with 1 PRB in presence of MBSFN
• 8.2.2.1.2 TDD PDSCH Single Antenna Port Performance with 1 PRB in the presence of MBSFN

Following is from 36.523-1 (V11.4.0 (2013-10))

• 17.1.1 MCCH information acquisition/ UE is switched on
• 17.1.2 MCCH information acquisition/ cell reselection to a cell in a new MBSFN area
• 17.1.3 MCCH information acquisition/ UE handover to a cell in a new MBSFN area
• 17.1.4 MCCH information acquisition/ UE is receiving an MBMS service
• 17.1.5 MCCH information acquisition/ UE is not receiving MBMS data
• 17.2.1 UE Acquire the MBMS data based on the SIB13 and MCCH message /MCCH and MTCH are on the same MCH
• 17.2.2 UE Acquire the MBMS data based on the SIB13 and MCCH message /MCCH and MTCH are on different MCHs
• 17.2.3 UE receives the MBMS data when this data is in the beginning of the MSP
• 17.2.4 Reception of PDCCH DCI format 0 and PHICH in MBSFN subframes
• 17.3.1 MBMS Counting / UE not receiving MBMS service
• 17.3.2 MBMS Counting / UE receiving MBMS service
• 17.4.1 Cell reselection to intra-frequency cell to continue MBMS service reception
• 17.4.2 Cell reselection to inter- frequency cell to start MBMS service reception
• 17.4.4 Handover to intra-frequency cell to continue MBMS service reception
• 17.4.6 MBMS Interest Indication retransmission after returning from cell not broadcasting SIB15
• 17.4.7 MBMS Interest Indication after Radio Link Failure
• 17.4.8 Continued MBMS service reception after E-UTRAN release of unicast bearer

MBMS Servers

• Expway
• Addpac

Reference

• LTE eMBMS Technology Overview : Qualcomm
• eMBMS : Alcatel Lucent
• eMBMS with SamSung
• Scalable push file delivery with MBMS : Erricson
• Video Streaming over MBMS: A System Design Approach