15 MBMS

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

15.0 MBMS-Specific Definitions

For MBMS, the following definitions are introduced:

MBSFN Synchronization Area: an area of the network where all eNodeBs can be synchronized and perform MBSFN transmissions. MBSFN Synchronization Areas are capable of supporting one or more MBSFN Areas. On a given frequency layer, a eNodeB can only belong to one MBSFN Synchronization Area. MBSFN Synchronization Areas are independent from the definition of MBMS Service Areas

MBSFN Transmission or a transmission in MBSFN mode: a simulcast transmission technique realised 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: an MBSFN Area consists of a group of cells within an MBSFN Synchronization Area of a network, 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 may only need to consider a subset of the MBSFN areas that are configured, i.e. when it knows which MBSFN area applies for the service(s) it is interested to receive.

Figure 15-1: MBMS Definitions

MBSFN Area Reserved Cell: A cell within a MBSFN Area which does not contribute to the MBSFN Transmission. The cell may be allowed to transmit for other services but at restricted power on the resource allocated for the MBSFN transmission.

Synchronisation Sequence: Each SYNC PDU contains a time stamp which indicates the start time of the synchronisation sequence. For an MBMS service, each synchronisation sequence has the same duration which is configured in the BM-SC and the MCE.

Synchronisation Period: The synchronisation period provides the time reference for the indication of the start time of each synchronisation sequence. The time stamp which is provided in each SYNC PDU is a relative value which refers to the start time of the synchronisation period. The duration of the synchronisation period is configurable.

15.1 General

15.1.0 Overview

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

MBMS reception is possible for UEs in RRC_IDLE state, or except for NB- IoT UEs, BL UEs or UEs in enhanced coverage, in RRC_CONNECTED state. Whenever receiving MBMS services, a user shall be notified of an incoming call, and originating calls shall be possible.

ROHC for MBMS is supported by upper layers (outside of Access Stratum) and only for Mission Critical services, as described in TS 23.280 [77].

RNs do not support MBMS.

HeNBs do not support MBMS.

For NB-IoT UEs, BL UEs or UEs in enhanced coverage:

– MBMS is provided in "MBMS/Unicast-mixed cells" with single-cell transmission.

– MBMS reception is possible only for UEs in RRC_IDLE state.

– Whenever receiving MBMS services, a user shall be notified of an incoming call, and originating calls shall be possible:

– Mobile Terminated call has higher priority than MBMS reception;

– Mobile Originated signalling has higher priority than MBMS reception;

– Other cases are left to UE implementation.

15.1.1 E-MBMS Logical Architecture

Figure 15.1.1-1: E-MBMS Logical Architecture

Figure 15.1.1-1 depicts the E-MBMS Logical 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 admission control and the allocation of the radio resources used by all eNBs in the MBSFN area for multi-cell MBMS transmissions using MBSFN operation. The MCE decides not to establish the radio bearer(s) of the new MBMS service(s) if the radio resources are not sufficient for the corresponding MBMS service(s) or may pre-empt radio resources from other radio bearer(s) of ongoing MBMS service(s) according to ARP. 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.

– deciding on whether to use SC-PTM or MBSFN.

– counting and acquisition of counting results for MBMS service(s).

– resumption of MBMS session(s) within MBSFN area(s) based on e.g. the ARP and/or the counting results for the corresponding MBMS service(s).

– suspension of MBMS session(s) within MBSFN area(s) based e.g. the ARP and/or on the counting results for the corresponding MBMS service(s).

NOTE: In case of distributed MCE architecture, the MCE manages the above functions for a single eNB of a MBSFN. The coordination of the functions between MCEs is provided by OAM, if needed.

The MCE is involved in MBMS Session Control Signalling. The MCE does not perform UE – MCE signalling.

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/update/stop) towards the E-UTRAN via MME.

Control Plane Interfaces

"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.

User Plane Interface

"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.

Deployment consideration

The two envisaged alternatives are shown in Figure 15.1.1-2.

The architecture on the right part is defined as the "distributed MCE architecture". In this architecture, a MCE is part of the eNB and the M2 interface should be kept between the MCE and the corresponding eNB.

The architecture on the left part is defined as the "centralized MCE architecture". In this architecture, the MCE is a logical entity which means it can be deployed as a stand-alone physical entity or collocated in another physical entity e.g. eNB. In both cases of the centralized MCE architecture, the M2 interface is kept between the MCE and all eNB(s) belonging to the corresponding MBSFN area.

Figure 15.1.1-2: eMBMS Architecture deployment alternatives

MBMS for V2X

When MBMS is used to deliver downlink V2X messages, the localized MBMS specified in TS 23.285 [72] may be used to improve latency if desired.

Single TMGI in non-overlapped MBMS service areas or multiple TMGIs in overlapped MBMS service areas may be used to support small MBMS areas for V2X.

15.1.2 E-MBMS User Plane Protocol Architecture

The overall U-plane architecture of content synchronization is shown in Figure 15.1.2-1. This architecture is based on the functional allocation for Unicast and the SYNC protocol layer is defined additionally on transport network layer to support content synchronization mechanism.

Figure 15.1.2-1: The overall u-plane architecture of the MBMS content synchronization

The SYNC protocol is defined as a protocol to carry additional information that enable eNBs to identify the timing for radio frame transmission and detect packet loss. Every E-MBMS service uses its own SYNC entity. The SYNC protocol is applicable to DL and is terminated in the BM-SC.

15.1.3 E-MBMS Control Plane Protocol Architecture

The E-MBMS C-plane protocol architecture is shown in Figure 15.1.3-1.

Figure 15.1.3-1: The E-MBMS c-plane architecture

MCCH is terminated in the eNB on the network side. How to achieve the synchronisation of MCCH signalling is described in clause 15.3.8.

15.2 MBMS Cells

15.2.1 MBMS-dedicated cell

Cells performing only MBMS transmissions are referred to as MBMS-dedicated cells. UEs not supporting FeMBMS are not supported on these cells. Paging is not supported on an MBMS-dedicated cell.

For MBMS-dedicated cells:

– MTCH and MCCH are mapped on MCH for MBSFN transmission;

MBMS-dedicated cells do not support unicast traffic in the downlink and these cells cannot be used as PCell or PSCell. System information required to receive MBMS from MBMS-dedicated cells is broadcasted on non-MBSFN subframes. The system information change notification as well as ETWS/CMAS notification are provided via L1 signalling on non-MBSFN subframes. The PBCH of MBMS-dedicated cell, uses a different scrambling sequence initialization than the PBCH of MBMS/Unicast-mixed cell which prevents UEs not supporting FeMBMS from camping on this cell.

15.2.2 MBMS/Unicast-mixed cell

Cells performing both MBMS and unicast transmissions are referred to as MBMS/Unicast-mixed cells.

For MBMS/Unicast mixed cells:

– MTCH and MCCH are mapped on MCH for MBSFN transmission;

– SC-MTCH and SC-MCCH are mapped on DL-SCH for SC-PTM transmission;

– Transmission of both unicast and MBMS in the cell is done in a co-ordinated manner.

15.2.2.1 FeMBMS/Unicast-mixed cell

An FeMBMS/Unicast-mixed cell is an MBMS/Unicast-mixed cell that operates with at least one of the following:

– subframes 4 or 9 or both configured as MBSFN subframes

– subframes that may not contain unicast control region

The FeMBMS/Unicast-mixed cell cannot be used as a PCell or PSCell. To provide unicast traffic on non-MBSFN subframes, such cell needs to be configured as an SCell. UEs not supporting FeMBMS are not supported on these cells and camping of such UEs is prevented by using cell barring mechanism of SIB1. Paging for incoming calls is not supported on such cells and system information change notification as well as ETWS/CMAS notification are provided with L1 signalling.

15.3 MBMS Transmission

15.3.1 General

Transmission of a MBMS in E-UTRAN uses either MBSFN transmission or SC-PTM transmission. The MCE makes the decision on whether to use SC-PTM or MBSFN for each MBMS session.

15.3.2 Single-cell transmission

Single-cell transmission of MBMS is characterized by:

– MBMS is transmitted in the coverage of a single cell;

– One SC-MCCH and one or more SC-MTCH(s) are mapped on DL-SCH;

– Scheduling is done by the eNB;

– SC-MCCH and SC-MTCH transmissions are each indicated by a logical channel specific RNTI on PDCCH (there is a one-to-one mapping between TMGI and G-RNTI used for the reception of the DL-SCH to which a SC-MTCH is mapped);

– A single transmission is used for DL-SCH (i.e. neither blind HARQ repetitions nor RLC quick repeat) on which SC-MCCH or SC-MTCH is mapped;

– SC-MCCH and SC-MTCH use the RLC-UM mode.

For each SC-MTCH, the following scheduling information is provided on SC-MCCH:

– SC-MTCH scheduling cycle;

– SC-MTCH on-duration: duration in downlink subframes that the UE waits for, after waking up from DRX, to receive PDCCHs. If the UE successfully decodes a PDCCH indicating the DL-SCH to which this SC-MTCH is mapped, the UE stays awake and starts the inactivity timer;

– SC-MTCH inactivity-timer: duration in downlink subframes that the UE waits to successfully decode a PDCCH, from the last successful decoding of a PDCCH indicating the DL-SCH to which this SC-MTCH is mapped, failing which it re-enters DRX. The UE shall restart the inactivity timer following a single successful decoding of a PDCCH.

NOTE 1: The SC-PTM reception opportunities are independent of the unicast DRX scheme.

NOTE 2: The SC-MTCH inactivity-timer may be set to 0.

NOTE 3: Although the above parameters are per SC-MTCH (i.e. per MBMS service), the network may configure the same scheduling pattern for multiple SC-MTCHs (i.e. multiple MBMS services).

NOTE 4: For NB-IoT UEs, the definition of the above parameters does not apply.

NOTE 5: For BL UEs and UEs in enhanced coverage, the definition of the above parameters does not apply.

For BL UEs, UEs in enhanced coverage and NB-IoT UEs, when multi-TB scheduling is configured, a single MPDCCH/NPDCCH can indicate scheduling of multiple downlink transmissions.

15.3.3 Multi-cell transmission

Multi-cell transmission of MBMS is characterized by:

– Synchronous transmission of MBMS within its MBSFN Area;

– Combining of MBMS transmission from multiple cells is supported;

– Scheduling of each MCH is done by the MCE;

– A single transmission is used for MCH (i.e. neither blind HARQ repetitions nor RLC quick repeat);

– A single Transport Block is used per TTI for MCH transmission, that TB uses all the MBSFN resources in that subframe;

– MTCH and MCCH can be multiplexed on the same MCH and are mapped on MCH for p-t-m transmission;

– MTCH and MCCH use the RLC-UM mode;

– The MAC subheader indicates the LCID for MTCH and MCCH;

– The MBSFN Synchronization Area, the MBSFN Area, and the MBSFN cells are semi-statically configured e.g. by O&M;

– MBSFN areas are static, unless changed by O&M (i.e. no dynamic change of areas);

NOTE: The UE is not required to receive services from more than one MBSFN Area simultaneously and may support only a limited number of MTCHs.

Multiple MBMS services can be mapped to the same MCH and one MCH contains data belonging to only one MBSFN Area. An MBSFN Area contains one or more MCHs. An MCH specific MCS is used for all subframes of the MCH that do not use the MCS indicated in BCCH. All MCHs have the same coverage area.

For MCCH and MTCH, the UE shall not perform RLC re-establishment at cell change between cells of the same MBSFN area. Within the MBSFN subframes, all MCHs within the same MBSFN area occupy a pattern of subframes, not necessarily adjacent in time, that is common for all these MCHs and is therefore called the Common Subframe Allocation (CSA) Pattern. The CSA pattern is periodically repeated with the CSA period. The actual MCH subframe allocation (MSA) for every MCH carrying MTCH is defined by the CSA pattern, the CSA period, and the MSA end, that are all signalled on MCCH. The MSA end indicates the last subframe of the MCH within the CSA period. Consequently, the MCHs are time multiplexed within the CSA period, which finally defines the interleaving degree between the MCHs. It shall be possible for MCHs to not use all MBSFN resources signalled as part of the Rel-8 MBSFN signalling. Further, such MBSFN resource can be shared for more than one purpose (MBMS, Positioning, etc.). During one MCH scheduling period (MSP), which is configurable per MCH, the eNB applies MAC multiplexing of different MTCHs and optionally MCCH to be transmitted on this MCH.

MCH scheduling information (MSI) is provided per MCH to indicate which subframes are used by each MTCH during the MSP, and to indicate whether transmission for an MTCH is going to be, or has been, suspended by the eNode B. The following principles are used for the MSI:

– it is used both when services are multiplexed onto the MCH and when only a single service is transmitted on the MCH;

– it is generated by the eNB and provided once at the beginning of the MSP;

– it has higher scheduling priority than the MCCH and, when needed, it appears first in the PDU;

– it allows the receiver to determine what subframes are used by every MTCH, sessions are scheduled in the order in which they are included in the MCCH session list;

– it is carried in a MAC control element which cannot be segmented;

– it carries the mapping of MTCHs to the subframes of the associated MSP. This mapping is based on the indexing of subframes belonging to one MSP;

– it carries an indication of whether the transmission of an MTCH is to be suspended by the eNode B.

The content synchronization for multi-cell transmission is provided by the following principles:

1. All eNBs in a given MBSFN Synchronization Area have a synchronized radio frame timing such that the radio frames are transmitted at the same time and have the same SFN.

2. All eNBs have the same configuration of RLC/MAC/PHY for each MBMS service, and identical information (e.g. time information, transmission order/priority information) such that synchronized MCH scheduling in the eNBs is ensured. These are indicated in advance by the MCE.

3. An E-MBMS GW sends/broadcasts MBMS packet with the SYNC protocol to each eNB transmitting the service.

4. The SYNC protocol provides additional information so that the eNBs identify the transmission radio frame(s). The E-MBMS GW does not need accurate knowledge of radio resource allocation in terms of exact time division (e.g. exact start time of the radio frame transmission).

5. eNB buffers MBMS packet and waits for the transmission timing indicated in the SYNC protocol.

6. The segmentation/concatenation is needed for MBMS packets and should be totally up to the RLC/MAC layer in eNB.

7. The SYNC protocol provides means to detect packet loss(es) and supports a recovery mechanism robust against loss of consecutive PDU packets (MBMS Packets with SYNC Header).

8. For the packet loss case the transmission of radio blocks potentially impacted by the lost packet should be muted.

9. The mechanism supports indication or detection of MBMS data burst termination (e.g. to identify and alternately use available spare resources related to pauses in the MBMS PDU data flow).

10. If two or more consecutive SYNC SDUs within a SYNC bearer are not received by the eNB, or if no SYNC PDUs of Type 0 or 3 are received for some synchronization sequence, the eNB may mute the exact subframes impacted by lost SYNC PDUs using information provided by SYNC protocol. If not muting only those exact subframes, the eNB stops transmitting the associated MCH from the subframe corresponding to the consecutive losses until the end of the corresponding MSP and it does not transmit in the subframe corresponding to the MSI of that MSP.

11. The eNB sets VT(US) to zero in the RLC UM entity corresponding to an MCCH at its modification period boundary.

12. The eNB sets VT(US) to zero in each RLC UM entity corresponding to an MTCH at the beginning of its MSP.

13. The eNB sets every bit in the MAC padding on MCH to "0".

14. The eNB’s RLC concatenates as many RLC SDUs from the same radio bearer as possible.

15. The eNB’s MAC multiplexes as many RLC PDUs as fit in the Transport Block.

16. The eNB sets every padding bit in the RLC UM PDU corresponding to an MTCH or MCCH to "0".

17. A MAC PDU including a MAC subheader for a MTCH MAC SDU always includes non-zero size of MTCH MAC SDU.

18. A MAC PDU including a MAC subheader for a MSI MAC control element always includes non-zero size of MSI MAC control element.

15.3.4 MBMS Reception States

UEs that are receiving MTCH and/or SC-MTCH transmissions can be in RRC_IDLE or except for NB-IoT UEs, BL UEs or UEs in enhanced coverage, in RRC_CONNECTED state.

UEs except for NB-IoT UEs, BL UEs or UEs in enhanced coverage that are receiving MTCH can also be in Receive Only Mode as defined in TS 23.246 [48].

15.3.5 MCCH Structure

The following principles govern the MCCH structure:

– One MBSFN Area is associated with one MCCH and one MCCH corresponds to one MBSFN Area;

– The MCCH is sent on MCH;

– MCCH consists of a single MBSFN Area configuration RRC message which lists all the MBMS services with ongoing sessions and an optional MBMS counting request message which, when present, comes after the former message in the repetition period;

– MCCH is transmitted by all cells within an MBSFN Area, except the MBSFN Area Reserved Cells;

– MCCH is transmitted by RRC every MCCH repetition period;

– MCCH uses a modification period;

– A notification mechanism is used to announce changes of MCCH due to either Session Start or the presence of an MBMS counting request message;

– 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 and includes an 8-bit bitmap to indicate the one or more MBSFN Area(s) in which the MCCH change(s);

– The UE monitors more than one notification subframe per modification period;

– When the UE receives a notification, it acquires the MCCH at the next modification period boundary;

– The UE detects changes to MCCH which are not announced by the notification mechanism by MCCH monitoring at the modification period.

15.3.5a SC-MCCH structure

The following principles govern the SC-MCCH structure:

– there is one SC-MCCH per cell;

– the SC-MCCH is sent on DL-SCH;

– the SC-MCCH provides the list of all MBMS services with ongoing sessions transmitted on SC-MTCH(s), including for each MBMS service TMGI and optional session ID, associated G-RNTI and scheduling information;

– SC-MCCH is transmitted by RRC every SC-MCCH repetition period;

– SC-MCCH uses a modification period;

– Except for NB-IoT UEs, BL UEs or UEs in enhanced coverage a notification mechanism is used to announce changes of SC-MCCH due to Session Start:

– The notification is sent in the first subframe in a repetition period where the SC-MCCH can be scheduled. The notification is sent using the DCI format 1C with SC-N-RNTI and one bit within the 8-bit bitmap;

– When the UE receives a notification, it acquires the SC-MCCH in the same subframe;

– For NB-IoT UEs, BL UEs or UEs in enhanced coverage:

– Two notification mechanisms are used to announce changes of SC-MCCH due to Session Start:

– A notification is sent in the DCI with SC-RNTI scheduling SC-MCCH. When the UE receives the notification, it acquires the SC-MCCH in the same modification period;

– A notification is sent in the DCI with G-RNTI scheduling SC-MTCH. When the UE receives the notification, it acquires the SC-MCCH in the next modification period;

– One notification mechanism is used to announce changes of SC-MCCH for the ongoing service:

– The notification is sent in the DCI with G-RNTI scheduling SC-MTCH. When the UE receives the notification, it acquires the SC-MCCH in the next modification period.

– The UE detects changes to SC-MCCH which are not announced by the notification mechanism by SC-MCCH monitoring at the modification period.

15.3.6 MBMS signalling on BCCH

– BCCH only points to the resources where the MCCH(s)/SC-MCCH can be found i.e. it does not indicate the availability of the services;

– For each MCCH, BCCH indicates independently:

– the scheduling of the MCCH for multi-cell transmission on MCH;

– the MCCH modification period, repetition period radio frame offset and subframe allocation;

– an MCS which applies to the subframes indicated for MCCH scheduling and for the first subframe of all MSPs in that MBSFN Area.

– For the notification commonly used for all MCCH, BCCH:

– configures the position of the MCCH change notification subframe and the number of occasions monitored by the UE;

– indicates the mapping between the PDCCH bit(s) carried in the notification and the MCCH(s).

– BCCH indicates the SC-MCCH modification period, SC-MCCH repetition period and SC-MCCH subframe offset.

15.3.7 MBMS User Data flow synchronisation

The synchronised radio interface transmission from the cells controlled by different eNBs requires a SYNC-protocol support between the BM-SC and the eNBs.

As part of the SYNC-protocol procedures the BM-SC shall include within the SYNC PDU packets a time stamp which tells the timing based on which the eNB sends MBMS data over the air interface. This time stamp is based on a common time reference, and common start of the first synchronisation period available at the BM-SC and the concerned eNBs and represents a relative time value which refers to the start time of the synchronisation period.

The BM-SC shall set the timestamp of all SYNC PDU packets in one synchronisation sequence of an MBMS service to the same value. The BM-SC should take into account the following factors for setting the timestamp: arrival time of data, the Maximum Transmission Delay from the BM-SC to the farthermost eNB, the length of the synchronisation sequence used for time stamping and other extra delay (e.g. processing delay in the eNB). The MSP length is one or multiple times of the synchronisation sequence length for MBMS services in the MCH.

MBMS user data shall be time-stamped based on separable synchronisation sequences which are tied to multiples of the TTI length. Each synchronisation sequence for each service is denoted by a single timestamp value working in such a manner that an increase of the timestamp value by one or more synchronisation sequence lengths shall be interpreted as an implicit start-of-a-new-synchronisation-sequence-indicator, so that the eNB becomes aware that a new sequence is starting.

The BM-SC does not know the absolute time point at which a TTI starts, but the sequence length for the time stamp is set by O&M like the delay parameters. The BM-SC will use the delay parameters to define the transmission time point of that user data packet and for the following user data packets the sequence length for the time stamp: following user data packets arriving within e.g. 40ms will receive the same time stamp value as the first data packet, if the sequence length is set to be 40ms.

In MBSFN operation,the eNB shall schedule the received data packets in the first MSP following the time point indicated by the timestamp unless the MBMS service is suspended, in which case no packet shall be sent by eNB. When a suspended MBMS service is resumed, the eNB shall enable the transmission from the beginning of the Modification Period indicated by the MCCH Update Time.

The elementary procedures related to the SYNC-protocol are defined in TS 25.446 [36].

Based on the parameters in the SYNC Header (e.g. Timestamp, Packet Number, Elapsed Octet Counter), the eNB is able to derive the timing for downlink radio transmission and notice if any SYNC packets are lost during transmission from BM-SC to the eNB. The eNB is also able to know the size of the lost SYNC packet in case a single SYNC packet is lost. Furthermore, the eNB may also be able to know the sizes of each lost SYNC packet if multiple consecutive SYNC packets are lost. Additionally the eNB is able to reorder the PDUs before passing them to RLC processing, if needed.

At the end of each synchronisation sequence the BM-SC shall send to the eNBs a user data frame, which contains counter information including ‘Total Number Of Packet Counter‘ and ‘Total Number Of Octet‘ without MBMS payload. This Total Counter frame is implicitly marking the end-of-sync.seq. The Total Counter frame without payload may be repeated in order to improve the reliability of the delivery to the eNBs.

In MBSFN operation, in case the SYNC protocol delivers more data for an MCH than the air interface can transport in the scheduling period, the following procedure shall be used by the eNB. As long as the eNB must drop a packet because it has too much data for this MCH scheduling period, it does the following,

– select the last bearer according to the order in the MCCH list with a SYNC SDU available for dropping;

– for the selected bearer, drop the available SYNC SDU with the highest Packet Number among the SYNC SDUs with the latest Timestamp.

A SYNC SDU is considered available for dropping when the eNB knows its size and it has not been dropped by the eNB.

In SC-PTM operation, if/how to use the timestamp information is left to eNB implementation.

15.3.8 Synchronisation of MCCH Update Signalling via M2

The synchronised radio interface transmission from the cells controlled by different eNBs require means to ensure that the MCCH content is updated at the same modification period border in each cell belonging to the same MBSFN Area.

The MCE and the concerned eNBs maintain a common time reference which allows each node to be aware of the modification period boundary within an MBSFN Area. In addition, each node maintains a counter of modification periods which is incremented by one at each modification period boundary. This counter which is based on common start of the first MCCH modification period, allows the MCE to indicate to the eNBs at which modification period the MCCH update shall take place. The MCE shall ensure that it starts to inform all eNBs within the MBSFN Area well in advance. In case of the simultaneously change of the MCCH information and the MCCH related BCCH information, the eNB may use this counter to decide after which BCCH modification period the MCCH related BCCH information update takes place.

15.3.9 IP Multicast Distribution

To improve the transport efficiency the IP Multicast shall be used for the MBMS payload distribution in the backbone network between the MBMS-GW and the eNBs that have joined the IP Multicast Group.

The MBMS-GW allocates the Transport Layer Address(es) used for the IP multicast and the DL TEID used for the M1 Transport association. The MBMS-GW sends this information to the MME(s) during the Session Start procedure. The MCE(s) receives these parameters from the MME in the MBMS Session Start Request message. The MCE passes the received parameters including at least one set of the Transport Layer Address to the relevant eNBs.

If the eNB accepts the MBMS Session Start request, or if it is required following the acceptance of the MBMS Session Update request, the eNB joins the channel (IP Multicast and Source address) to the backbone in order to join the bearer service multicast distribution.

The MBMS payload is forwarded by the MBMS-GW towards the IP Multicast address(es). The eNBs having joined that IP Multicast will receive the user data packets (SYNC PDU) together with the synchronisation-related information in header part of SYNC PDU.

15.4 Service Continuity

Mobility procedures for MBMS reception allow the UE to start or continue receiving MBMS service(s) via MBSFN or SC-PTM when changing cell(s). For each MBMS service provided using SC-PTM, E-UTRAN indicates in the SC-MCCH the list of neighbour cells providing this MBMS service so that the UE can request unicast reception of the service before changing to a cell not providing the MBMS service using SC-PTM.

For MBSFN transmission, E-UTRAN procedures provide support for service continuity with respect to mobility within the same MBSFN area. Within the same geographic area, MBMS services can be provided on more than one frequency and the frequencies used to provide MBMS services may change from one geographic area to another within a PLMN.

UEs that are receiving MBMS service(s) in RRC_IDLE state performing cell reselection or are in RRC_CONNECTED state obtain target cell (SC-)MTCH information from the target cell (SC-)MCCH.

To avoid the need to read MBMS related system information and potentially (SC-)MCCH on neighbour frequencies, the UE is made aware of which frequency is providing which MBMS services via MBSFN or SC-PTM through the combination of the following MBMS assistance information:

– user service description (USD): in the USD (see TS 26.346 [49]), the application/service layer provides for each service the TMGI, the session start and end time, the frequencies and the MBMS service area identities (MBMS SAIs, see definition in clause 15.3 of TS 23.003 [26]) belonging to the MBMS service area (see definition in TS 23.246 [48]);

– system information: MBMS and non-MBMS cells indicate in SystemInformationBlockType15 the MBMS SAIs of the current frequency and of each neighbour frequency.

The MBMS SAIs of the neighbouring cell may be provided by X2 signalling (i.e. X2 Setup and eNB Configuration Update procedures) or/and OAM.

When applying the procedures described below for UEs in RRC_IDLE and RRC_CONNECTED state:

– the UE does not need to verify that a frequency is providing a MBMS service by acquiring (SC-)MCCH and may apply these procedures even though a MBMS service is not provided via MBSFN or SC-PTM;

– the UE may consider that a service is provided if a session of this service is ongoing as derived from the session start and end times indicated for this service in the USD and if a frequency provides this service;

– the UE determines the frequency on which a service is provided according to the following:

– if the serving cell provides SystemInformationBlockType15 (SystemInformationBlockType15-NB in NB-IoT), the UE considers that a frequency is providing the MBMS service via MBSFN or SC-PTM if and only if one of the MBMS SAI(s) of this frequency as indicated in SystemInformationBlockType15 of the serving cell is indicated for this MBMS service in the USD;

– except for NB-IoT UEs, BL UEs or UEs in enhanced coverage, if the serving cell does not provide SystemInformationBlockType15, the UE in RRC_IDLE state may consider that a frequency included in the USD for the MBMS service is providing this MBMS service as long as the UE reselects cells where SystemInformationBlockType13 is provided.

Except for NB-IoT UEs, BL UEs or UEs in enhanced coverage, in RRC_IDLE, the UE applies the normal cell reselection rules with the following modifications:

– the UE which is receiving MBMS service(s) via MBSFN or SC-PTM and can only receive these MBMS service(s) via MBSFN or SC-PTM while camping on the frequency providing these MBMS service(s) is allowed to make this frequency highest priority;

– the UE which is interested in receiving MBMS service(s) via MBSFN or SC-PTM and can only receive these MBMS service(s) via MBSFN or SC-PTM while camping on the frequency providing these MBMS service(s) is allowed to make this frequency highest priority when it intends to receive these MBMS service(s);

– when the MBMS service(s) which the UE is interested in are no longer available (after the end of the session) or the UE is no longer interested in receiving the service(s), the UE no longer prioritises the frequency providing these MBMS service(s);

NOTE 1: In RRC IDLE, when the above modifications to cell reselection rules are applied, the prioritization between the frequency providing these MBMS service(s) and the frequency of a CSG cell, and the autonomous search are left to UE implementation.

For NB-IoT UEs, BL UEs or UEs in enhanced coverage, the UE applies the normal cell reselection rules with the following modifications:

– the UE which is receiving MBMS service(s) via SC-PTM and can only receive these MBMS service(s) via SC-PTM while camping on the frequency providing these MBMS service(s) applies an offset signalled in SystemInformationBlockType5-NB for NB-IoT UEs and SystemInformationBlockType5 for BL UEs or UEs in CE to this frequency in ranking based cell reselection;

– the UE which is interested in receiving MBMS service(s) via SC-PTM and can only receive these MBMS service(s) via SC-PTM while camping on the frequency providing these MBMS service(s) applies an offset signalled in SystemInformationBlockType5-NB for NB-IoT UEs and SystemInformationBlockType5 for BL UEs or UEs in CE to this frequency in ranking based cell reselection;

– when the MBMS service(s) which the UE is interested in are no longer available (after the end of the session) or the UE is no longer interested in receiving the service(s), the UE no longer apply the offset to the frequency providing these MBMS service(s) in ranking based cell reselection.

Except for NB-IoT UEs, in RRC_CONNECTED, the UE that is receiving or interested to receive MBMS via MBSFN or SC-PTM informs the network about its MBMS interest via a RRC message and the network does its best to ensure that the UE is able to receive MBMS and unicast services subject to the UE’s capabilities:

– the UE indicates the frequencies which provide the service(s) that the UE is receiving or is interested to receive simultaneously, and which can be received simultaneously in accordance with the UE capabilities.

– if the PCell broadcasts SystemInformationBlockType20, the UE also indicates the list of services that the UE is receiving or is interested to receive on the indicated frequencies.

– the UE indicates its MBMS interest at RRC connection establishment (the UE does not need to wait until AS security is activated), and whenever the set of frequencies on which the UE is interested in receiving MBMS services has changed compared with the last indication sent to the network (e.g. due to a change of user interest or of service availability), and whenever the list of MBMS services that the UE is interested in receiving has changed compared with the last indication sent to the network.

– the UE may only indicate its interest when the PCell provides SystemInformationBlockType15 and after having acquired SystemInformationBlockType15 of the current PCell.

– the UE may indicate its MBMS interest even if the current configured serving cell(s) do not prevent it from receiving the MBMS services it is interested in.

– the UE indicates with a single bit whether it prioritises MBMS reception over unicast. This priority indication applies to all unicast bearers and all MBMS frequencies. It is sent whether the MBMS frequencies are congested or not.

– the E-UTRAN reuses the SupportedBandCombination IE to derive the UEs MBMS related reception capabilities, i.e. the E-UTRAN tries to ensure that the UE is able to receive MBMS and unicast bearers by providing them on the frequencies indicated in SupportedBandCombination IE signalled by the UE. The UE supporting MBMS reception via MBSFN or SC-PTM shall support MBMS reception via MBSFN or SC-PTM respectively, on any serving cell and on any cell that may be additionally configured as serving cell according to the UE capabilities.

– the E-UTRAN tries to ensure that the UE which does not support simultaneous reception of unicast transmission and SC-PTM transmission in one subframe on one carrier is able to receive the indicated MBMS services transmitted via SC-PTM and to receive unicast bearers by scheduling them in different subframes.

– for handover preparation, the source eNB transfers the MBMS interest of the UE, if available, to the target eNB. After handover, the UE reads SystemInformationBlockType15 before updating its MBMS interest. If SystemInformationBlockType15 is provided on the target cell but not on the source cell, the UE indicates its MBMS interest after handover.

If MBMS is prioritised and the unicast connection cannot be maintained because of congestion on the MBMS carrier then the E-UTRAN releases unicast bearers. It is left to E-UTRAN implementation whether all bearers or only GBR bearers are released. The E-UTRAN does not trigger re-establishment of the released unicast bearers. For congestion control, the E-UTRAN can rely on existing access control mechanisms.

The E-UTRAN may take into account the UE priority for MBMS or unicast reception when receiving an indication of proximity to a CSG cell from a UE which also indicated interest in MBMS reception (or vice-versa).

15.5 Network sharing

Unicast mobility shall not be affected by the sharing of MBMS resources by operators.

15.6 Network Functions for Support of Multiplexing

Considerable gain in radio resource efficiency can be achieved by multiplexing several E-MBMS services on a single MCH. The services that share the resources are called E-MBMS Service Multiplex. The amount of common radio resources allocated to such an E-MBMS Service Multiplex can be smaller than the sum of radio resources, which would need to be allocated for the individual services without multiplexing. This represents the statistical multiplexing gain.

The MCE manages the E-MBMS Service Multiplex e.g. deciding which services are to be multiplexed on which MCH. The duration of each E-MBMS service may be different, so there is a need to manage the Service Multiplex dynamically, i.e. addition or removal of services into/from the E-MBMS Service Multiplex. The MCE allocates the optimal amount of resources to multiplexed services, using service related information. The MCE selects the CSA pattern for the MCHs and also the order in which the services appear in the MCCH. MBSFN transmission is ensured by identical multiplexing of the services in all cells belonging to the same MBSFN area. The location of the multiplexing function is in the eNB MAC layer.

These functions are supported by respective signalling information on M2 interface. This scheduling information is sent to all eNBs via the M2 interface procedure "MBMS Scheduling Information".

Figure 15.6.1 MBMS Scheduling Information procedure message flow on M2 interface

15.7 Procedures

15.7.1 Procedures for Broadcast mode

15.7.1.1 Session Start procedure

The purpose of the MBMS Session Start procedure is to request the E-UTRAN to notify UEs about an upcoming MBMS Session of a given MBMS Bearer Service and to establish an MBMS E-RAB for this MBMS Session. The MBMS Session Start procedure is triggered by the EPC.

Figure 15.7.1.1-1. Session Start procedure

1. The MME sends MBMS session start request message to the MCE(s) controlling eNBs in the targeted MBMS service area. The message includes the IP multicast address, session attributes and the minimum time to wait before the first data delivery, and includes the list of cell identities if available.

NOTE 1: The MME does not need to check the PLMN ID included in the TMGI

2. T he MCE decides whether to use SC-PTM or MBSFN to carry the MBMS bearer over the air interface.

In MBSFN operation, the MCE checks whether the radio resources are sufficient for the establishment of new MBMS service(s) in the area it controls. If not, MCE decides not to establish the radio bearers of the MBMS service(s) and does not forward the MBMS session start request message to the involved eNBs, or may pre-empt radio resources from other radio bearer(s) of ongoing MBMS service(s) according to ARP. The MCE confirms the reception of the MBMS Session Start request to the MME. This message can be transmitted before the step 4. Only in case of distributed MCE architecture radio resource setup is scheduled according to the parameter "time of MBMS data transfer" which indicates an absolute start time of data delivery, otherwise according to the "minimum time to MBMS data transfer" parameter.

NOTE 2: In MBSFN operation, the MCE may send the MBMS SESSION START RESPONSE message after it receives at least one confirmation from the eNB(s) (i.e. Step 4).

In SC-PTM operation, the MCE only confirms the reception of the MBMS Session Start request to the MME, after the MCE receives at least one confirmation from the eNB(s) (i.e. Step 4).

3. In MBSFN operation, the MCE sends the MBMS Session Start Request message to the relevant eNBs. If the MBMS Session Start message includes the MBMS Service Area Identity with value 0 as defined in TS 23.003 [26], the MCE shall consider that all those eNBs supporting the PLMN as indicated by the received MBMS Session Start Request message are involved. The MCE then determines in which MBSFN area(s) the service should be delivered.

In SC-PTM operation, the MCE includes the SC-PTM information (i.e. list of cell identities and QoS information received from the MME in Step 1) , in the MBMS Session Start Request message to the relevant eNBs.

NOTE 3: The MCE does not need to check the PLMN ID included in the TMGI.

NOTE 4: When to send the MBMS Session Start message from MCE to eNB according to the minimum time to wait indication is an MCE implementation issue.

4. In MBSFN operation, eNB confirms the reception of the MBMS Session Start message.

In SC-PTM operation, the eNB checks whether the radio resources are sufficient for the establishment of new MBMS service(s) in the area it controls. If not, eNB decides not to establish the radio bearers of the MBMS service(s), or may pre-empt radio resources from other radio bearer(s) according to ARP. eNB confirms the reception of the MBMS Session Start message.

Step 5 and 6 are only applicable to MBSFN operation.

5. MCE sends the MBMS Scheduling Information message to the eNB including the updated MCCH information which carries the MBMS service’s configuration information. This message can be transmitted before the step 3.

6. eNB confirms the reception of the MBMS Scheduling Information message.

7. eNB indicates MBMS session start to UEs by MCCH change notification and updated MCCH information which carries the MBMS service’s configuration information.

8. eNB joins the IP multicast group to receive the MBMS User Plane data.

9. eNB sends the MBMS data to radio interface; In MBSFN operation, the MBMS data is sent at the determined time.

15.7.1.2 Session Stop procedure

The MBMS Session Stop procedure is to request the E-UTRAN to notify UEs about the end of a given MBMS Session and to release the corresponding MBMS E-RAB this MBMS Session. The MBMS Session Stop procedure is triggered by the EPC.

Figure 15.7.1.2-1. Session Stop procedure

1. The MME sends MBMS session stop request message to the MCE(s) controlling eNBs in the targeted MBMS service area.

2. MCE confirms the reception of the MBMS Session stop request to the MME.

3. MCE forwards the MBMS Session stop message to the relevant eNBs.

4. eNB confirms the reception of the MBMS Session stop message.

Step 5 and 6 are only applicable to MBSFN operation.

6. eNB confirms the reception of the MBMS Scheduling Information message.

7. eNB indicates MBMS session stop to UEs by removing any service configuration associated with the stopped session from the updated MCCH message.

8. The corresponding E-RAB is released, and eNB leaves the IP multicast group.

15.7a M1 Interface

15.7a.1 M1 User Plane

The M1 user plane interface is defined between the eNB and the MBMS GW. The M1 user plane interface provides non guaranteed delivery of user plane PDUs between the eNB and the MBMS GW. The user plane protocol stack on the M1 interface is shown in Figure 15.7a.1-1. The transport network layer is built on IP transport and GTP-U is used on top of UDP/IP to carry the user plane PDUs between the eNB and the MBMS GW.

Figure 15.7a.1-1: M1 Interface User Plane (eNB – MBMS GW)

15.8 M2 Interface

15.8.1 M2 Control Plane

The M2 control plane interface is defined between the eNB and the MCE. The control plane protocol stack of the M2 interface is shown on Figure 15.8.1-1. The transport network layer is built on IP transport, for the reliable transport of signalling messages SCTP is added on top of IP. The application layer signalling protocol is referred to as M2AP (M2 Application Protocol).

Figure 15.8.1-1: M2 Interface Control Plane (eNB-MCE)

The SCTP layer provides the guaranteed delivery of application layer messages.

In the transport IP layer point-to-point transmission is used to deliver the signalling PDUs.

A single SCTP association per eNB-MCE interface instance shall be used with one pair of stream identifiers for M2 common procedures. Only a few pairs of stream identifiers should be used for M2 MBMS-service-associated procedures. eNB and MCE communication context identifiers that are assigned by the eNB and the MCE for M2 MBMS-service-associated procedures shall be used to distinguish MBMS service specific M2 signalling transport bearers. The communication context identifiers are conveyed in the respective M2AP messages.

15.8.2 M2 Interface Functions

15.8.2.1 General

The M2 interface provides the following functions:

– MBMS Session Handling Function:

– MBMS Session Start, MBMS Session Stop, MBMS Session Update.

– MBMS Scheduling Information Provision Function.

– M2 Interface Management Function:

– Reset, Error Indication, Restoration.

– M2 Configuration Function.

– MBMS Service Counting Function.

– MBMS Service Suspension and Resumption Function.

15.8.2.2 MBMS Session Handling Function

The MBMS Session Handling Function enables the MCE to provide Session Start, Session Stop and Session Update messages to the eNBs it is connected to. The MCE provides the information of the MBMS session, e.g., the MBMS Service Area information, and the SC-PTM information to the eNB, where the SC-PTM information is included only in case of SC-PTM operation.

15.8.2.3 MBMS Scheduling Information Provision Function

The MBMS Scheduling Information Provision Function enables the MCE to configure MCCH content according to the expected or ongoing MBMS services, and to configure MCH Scheduling Information for suspension notification.

15.8.2.4 M2 Interface Management Function

The M2 interface management functions provide:

– means to ensure a defined start of the M2 interface operation (reset);

– means to handle different versions of application part implementations and protocol errors (error indication);

– means to restore services following an eNB failure or an M2 path failure (restoration). The Restoration function enables the MCE to restore in the eNB the MBMS sessions. This restoration function is implemented by the MBMS Session Start procedure.

15.8.2.5 M2 Configuration Function

The M2 Configuration Function allows the eNB and MCE to exchange configuration information necessary for the operation of the M2 interface, and MCCH related BCCH content.

15.8.2.6 MBMS Service Counting Function

The MBMS Service Counting Function enables the MCE to perform counting and to receive counting results per MBMS service(s) within MBSFN area(s). MCE can perform counting only for those MBMS service(s) for which access has not been denied by the admission control function for the corresponding MBMS session(s).

15.8.2.7 MBMS Service Suspension and Resumption Function

The MBMS Service Suspension and Resumption Function enables the MCE to request the eNB that it may release the allocated RAN resources, may leave the IP multicast if already joined, shall update the MCCH information and shall suspend the MBSFN transmission while keeping the MBMS context for that service in the eNB. If the MCE subsequently requests the eNB for resumption, then the eNB shall allocate the RAN resources, shall send the MCCH change notification, shall update the MCCH information, shall resume the MBSFN transmission and shall join IP multicast if previously left. This MBMS Services Suspension and Resumption function is implemented by the MBMS Scheduling Information procedure as described in clause 15.8.3.3.

Suspension/Resumption of MBMS service provision is applied to a whole MBSFN area.

15.8.2.8 MBMS Overload Notification Function

The MBMS Overload Notification Function enables the eNB to notify the MCE about MBMS overload status.

15.8.3 M2 Interface Signalling Procedures

15.8.3.1 General

The elementary procedures supported by the M2AP protocol are listed in Table 2 and Table 3 of TS 36.443 [44].

15.8.3.2 MBMS Session signalling procedure

The MBMS Session signalling procedure enables the MCE to deliver Session Start, Session Stop and Session Update messages to the concerned eNBs. At Session Start and Session Update, the MCE provides the information of the MBMS session, e.g., the MBMS Service Area information, and the SC-PTM information to the eNB, where the SC-PTM information is included only in case of SC-PTM operation.

15.8.3.3 MBMS Scheduling Information procedure

The MBMS Scheduling Information procedure enables the MCE to update MCCH information whenever necessary. Typically, the MCE issues an MBMS Scheduling Information procedure before user data transmission for an announced MBMS service starts or after it has ended.

The MBMS Scheduling Information procedure also enables the MCE to update MCH Scheduling Information for suspension notification.

15.8.3.4 M2 Interface Management procedures

15.8.3.4.1 Reset procedure

The Reset procedure is issued in order to re-initialize the peer entity or part of the peer entity after node setup and after a failure event occurred. This procedure may be initiated by both the eNB and MCE.

15.8.3.4.2 Error Indication procedure

The Error Indication procedure may be initiated by the eNB and the MCE. It is used to report detected errors in one incoming message, if an appropriate failure message cannot be reported to the sending entity.

15.8.3.5 M2 Configuration procedures

15.8.3.5.1 M2 Setup procedure

The M2 Setup procedure allows the exchange of configured data which is required in the MCE and in the eNB respectively to ensure a proper interoperation and MCCH related BCCH content. The M2 Setup procedure is triggered by the eNB. The M2 Setup procedure is the first M2AP procedure executed on an M2 interface instance.

15.8.3.5.2 eNB Configuration Update procedure

The eNB Configuration Update procedure is used to provide updated configured data in the eNB and receive MCCH related BCCH content from MCE. The eNB Configuration Update procedure is triggered by the eNB.

15.8.3.5.3 MCE Configuration Update procedure

The MCE Configuration Update procedure is used to provide updated configured data in the MCE and tell eNB updated MCCH related BCCH content. The MCE Configuration Update procedure is triggered by the MCE.

15.8.3.6 MBMS Service Counting procedures

15.8.3.6.1 MBMS Service Counting procedure

The MBMS Service Counting procedure is used to trigger the eNB to count the number of connected mode UEs that either are receiving the MBMS service(s) or are interested in the reception of the MBMS service(s).

15.8.3.6.2 MBMS Service Counting Results Report procedure

The MBMS Service Counting Results Report procedure is used by the eNB to provide the MCE with the number of connected mode UEs that either are receiving the MBMS service(s) or are interested in the reception of the MBMS service(s) based on counting performed by the eNB.

15.8.3.7 MBMS Overload Notification procedure

The MBMS Overload Notification procedure enables the eNB to notify the MCE about MBMS overload status.

15.9 M3 Interface

15.9.1 M3 Control Plane

The M3 control plane interface is defined between the MME and the MCE. The control plane protocol stack of the M3 interface is shown on Figure 15.9.1-1. The transport network layer is built on IP transport, for the reliable transport of signalling messages SCTP is added on top of IP. The application layer signalling protocol is referred to as M3AP (M3 Application Protocol).

Figure 15.9.1-1: M3 Interface Control Plane (MME-MCE)

The SCTP layer provides the guaranteed delivery of application layer messages.

In the transport IP layer point-to-point transmission is used to deliver the signalling PDUs.

A single SCTP association per MME-MCE interface instance shall be used with one pair of stream identifiers for M3 common procedures. Only a few pairs of stream identifiers should be used for M3 MBMS-service-associated procedures. MME and MCE communication context identifiers that are assigned by the MME and the MCE for M3 MBMS-service-associated procedures shall be used to distinguish MBMS service specific M3 signalling transport bearers. The communication context identifiers are conveyed in the respective M3AP messages.

15.9.2 M3 Interface Functions

15.9.2.1 General

The M3 interface provides the following functions:

– MBMS Session Handling Function:

– MBMS Session Start, MBMS Session Stop, MBMS Session Update.

– M3 Interface Management Function:

– Reset, Error Indication, Restoration.

– M3 Configuration Function (distributed MCE architecture only, see clause 15.1.1)

– M3 Setup, MCE Configuration Update.

15.9.2.2 MBMS Session Handling Function

The MBMS Session Handling Function enables the MME to provided Session Start, Session Stop and Session Update messages to the MCEs it is connected to. The MME provides the information of the MBMS session, e.g., QoS, MBMS Service Area, and the list of cell identities if available, to the MCEs.

In this release the MBMS Session Update procedure only supports the update of MBMS Service Area, the update of the list of cell identities, the update of the allocation and retention priority of the MBMS session and the update of time of MBMS data transfer where the last one is used in the distributed MCE architecture only.

15.9.2.3 M3 Interface Management Function

The M3 interface management functions provide:

– means to ensure a defined start of the M3 interface operation (reset);

– means to handle different versions of application part implementations and protocol errors (error indication);

– means to restore services following an MCE failure or an M3 path failure (restoration).The Restoration function enables the MME to restore in the MCE the MBMS sessions as specified in TS 23.007 [56]. This Restoration function is implemented by the MBMS Session Start procedure.

15.9.2.4 M3 Configuration Function

The M3 Configuration Function allows the MCE to exchange with the MME node configuration information necessary for the operation of the M3 interface such as the supported MBMS Service Area information.

15.9.3 M3 Interface Signalling Procedures

15.9.3.1 General

The elementary procedures supported by the M3AP protocol are listed in Table 8-1 and Table 8-2 of TS 36.444 [45].

15.9.3.2 MBMS Session signalling procedure

The MBMS Session signalling procedure enables the MME to deliver Session Start, Session Stop and Session Update messages to the concerned MCEs. At Session Start and Session Update, the MME provides the information of the MBMS session, e.g., QoS, MBMS Service Area, and the list of cell identities if available, to the MCEs.

In distributed MCE architecture only, the MME may also provide a "time of MBMS data transfer" to indicate the absolute start time of data delivery, and a "time of MBMS data stop" to indicate the absolute end time of data delivery.

In this release the MBMS Session Update procedure only supports the update of MBMS Service Area, the update of the list of cell identities if available, the update of the allocation and retention priority of the MBMS session and the update of time of MBMS data transfer where the last one is used in the distributed MCE architecture only.

15.9.3.3 M3 Interface Management procedures

15.9.3.3.1 Reset procedure

15.9.3.3.2 Error Indication procedure

The Error Indication procedure may be initiated by the MME and the MCE. It is used to report detected errors in one incoming message, if an appropriate failure message cannot be reported to the sending entity.

15.9.3.4 M3 Configuration procedures

15.9.3.4.1 M3 Setup procedure

The M3 Setup procedure allows the initial exchange of configured data which is required in the MCE and in the MME such as the supported MBMS Service Area information. The M3 Setup procedure is initiated by the MCE.

15.9.3.4.2 MCE Configuration Update procedure

The MCE Configuration Update procedure is used to provide updated configured data in the MCE to the MME. The MCE Configuration Update procedure is triggered by the MCE.

15.10 MBMS Counting

15.10.1 General

MBMS counting in LTE is used to determine if there are sufficient UEs interested in receiving a service to enable the operator to decide if it is appropriate to deliver the service via MBSFN. It allows the operator to choose between enabling or disabling MBSFN transmission for the service. MBMS counting applies only to connected mode UEs. Enabling and disabling MBSFN transmission is realized by MBMS Service Suspension and Resumption function in clause 15.8.2.7.

The following principles are used for the MBMS counting:

– Counting is supported for both a service already provided by MBSFN in an MBSFN area as well as for a service not yet provided via MBSFN in an MBSFN area. A service not yet provided via MBSFN in an MBSFN area may be:

– Service provided via unicast bearer.

– Service not yet provided either by MBSFN or by unicast.

– RAN is not aware of MBMS service provisioning through unicast bearers.

15.10.2 Counting Procedure

The Counting Procedure is initiated by the network. Initiation of the Counting Procedure results in a request to each eNB involved in the providing MBSFN area to send a Counting Request (the Counting Request is included in the directly extended MCCH message), which contains a list of TMGI’s requiring UE feedback. The connected mode UEs which are receiving or interested in the indicated services will respond with a RRC Counting Response message, which includes short MBMS service identities (unique within the MBSFN service area) and may optionally include the information to identify the MBSFN Area (if overlapping is configured).

The following principles are used for the Counting Procedure:

– Network has means to disable UE counting per service.

– The UE is able to report on multiple MBMS services via a single Counting Response message.

– It is unnecessary to retransmit the Counting Response when the UE moves within the same MBSFN area.

– The network only gets one response from a UE related to one Counting Request message, which is broadcast for one modification period.

– The UE cannot automatically indicate to network a change of interest in MBMS service(s).

– The network counts UE interest per service.

15.11 MBMS service reception using Receive Only Mode

MBMS service(s) can be received by a UE in ROM as described in TS 23.246 [48], clause D.2.3 and in TS 26.346 [49]. A UE may receive or be interested to receive broadcast MBMS service(s) in ROM from a different eNB while receiving unicast or MBMS service(s) from serving eNB. If UE baseband resources are shared for receiving unicast service and MBMS service(s) in ROM from different eNBs, the UE may use MBMSInterestIndication signaling procedure as described in TS 36.331 [16] to inform the unicast serving eNB about the baseband resources used for the purpose of MBMS service(s) in ROM from a different eNB.