5.8 MBMS

36.3313GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Protocol specificationRadio Resource Control (RRC)Release 15TS

5.8.1 Introduction

5.8.1.1 General

In general the control information relevant only for UEs supporting MBMS is separated as much as possible from unicast control information. Most of the MBMS control information is provided on a logical channel specific for MBMS common control information: the MCCH. E-UTRA employs one MCCH logical channel per MBSFN area. In case the network configures multiple MBSFN areas, the UE acquires the MBMS control information from the MCCHs that are configured to identify if services it is interested to receive are ongoing. The action applicable when the UE is unable to simultaneously receive MBMS and unicast services is up to UE implementation. In this release of the specification, an MBMS capable UE is only required to support reception of a single MBMS service at a time, and reception of more than one MBMS service (also possibly on more than one MBSFN area) in parallel is left for UE implementation. The MCCH carries the MBSFNAreaConfiguration message, which indicates the MBMS sessions that are ongoing as well as the (corresponding) radio resource configuration. The MCCH may also carry the MBMSCountingRequest message, when E-UTRAN wishes to count the number of UEs in RRC_CONNECTED that are receiving or interested to receive one or more specific MBMS services.

A limited amount of MBMS control information is provided on the BCCH. This primarily concerns the information needed to acquire the MCCH(s). This information is carried by means of a single MBMS specific SystemInformationBlock: SystemInformationBlockType13. An MBSFN area is identified solely by the mbsfn-AreaId in SystemInformationBlockType13. At mobility, the UE considers that the MBSFN area is continuous when the source cell and the target cell broadcast the same value in the mbsfn-AreaId.

5.8.1.2 Scheduling

The MCCH information is transmitted periodically, using a configurable repetition period. Scheduling information is not provided for MCCH i.e. both the time domain scheduling as well as the lower layer configuration are semi-statically configured, as defined within SystemInformationBlockType13.

For MBMS user data, which is carried by the MTCH logical channel, E-UTRAN periodically provides MCH scheduling information (MSI) at lower layers (MAC). This MCH information only concerns the time domain scheduling i.e. the frequency domain scheduling and the lower layer configuration are semi-statically configured. The periodicity of the MSI is configurable and defined by the MCH scheduling period.

5.8.1.3 MCCH information validity and notification of changes

Change of MCCH information only occurs at specific radio frames, i.e. the concept of a modification period is used. Within a modification period, the same MCCH information may be transmitted a number of times, as defined by its scheduling (which is based on a repetition period). The modification period boundaries are defined by SFN values for which SFN mod m= 0, where m is the number of radio frames comprising the modification period. The modification period is configured by means of SystemInformationBlockType13.

When the network changes (some of) the MCCH information, it notifies the UEs about the change during a first modification period. In the next modification period, the network transmits the updated MCCH information. These general principles are illustrated in figure 5.8.1.3-1, in which different colours indicate different MCCH information. Upon receiving a change notification, a UE interested to receive MBMS services acquires the new MCCH information immediately from the start of the next modification period. The UE applies the previously acquired MCCH information until the UE acquires the new MCCH information.

Figure 5.8.1.3-1: Change of MCCH Information

Indication of an MBMS specific RNTI, the M-RNTI (see TS 36.321 [6]), on PDCCH is used to inform UEs in RRC_IDLE and UEs in RRC_CONNECTED about an MCCH information change. When receiving an MCCH information change notification, the UE knows that the MCCH information will change at the next modification period boundary. The notification on PDCCH indicates which of the MCCHs will change, which is done by means of an 8-bit bitmap. Within this bitmap, the bit at the position indicated by the field notificationIndicator is used to indicate changes for that MBSFN area: if the bit is set to "1", the corresponding MCCH will change. No further details are provided e.g. regarding which MCCH information will change. The MCCH information change notification is used to inform the UE about a change of MCCH information upon session start or about the start of MBMS counting.

The MCCH information change notifications on PDCCH are transmitted periodically and are carried on MBSFN subframes only except on MBMS-dedicated cell or FeMBMS/Unicast-mixed cell where the MCCH information change is provided on non-MBSFN subframes. These MCCH information change notification occasions are common for all MCCHs that are configured, and configurable by parameters included in SystemInformationBlockType13: a repetition coefficient, a radio frame offset and a subframe index. These common notification occasions are based on the MCCH with the shortest modification period.

NOTE 1: E-UTRAN may modify the MBMS configuration information provided on MCCH at the same time as updating the MBMS configuration information carried on BCCH i.e. at a coinciding BCCH and MCCH modification period. Upon detecting that a new MCCH is configured on BCCH, a UE interested to receive one or more MBMS services should acquire the MCCH, unless it knows that the services it is interested in are not provided by the corresponding MBSFN area.

A UE that is receiving an MBMS service via MRB shall acquire the MCCH information from the start of each modification period. A UE interested to receive MBMS from a carrier on which dl-Bandwidth included in MasterInformationBlock is set to n6 shall acquire the MCCH information at least once every MCCH modification period. A UE that is not receiving an MBMS service via MRB, as well as UEs that are receiving an MBMS service via MRB but potentially interested to receive other services not started yet in another MBSFN area from a carrier on which dl-Bandwidth included in MasterInformationBlock is other than n6, shall verify that the stored MCCH information remains valid by attempting to find the MCCH information change notification at least notificationRepetitionCoeff times during the modification period of the applicable MCCH(s), if no MCCH information change notification is received.

NOTE 2: In case the UE is aware which MCCH(s) E-UTRAN uses for the service(s) it is interested to receive, the UE may only need to monitor change notifications for a subset of the MCCHs that are configured, referred to as the ‘applicable MCCH(s)’ in the above.

5.8.2 MCCH information acquisition

5.8.2.1 General

Figure 5.8.2.1-1: MCCH information acquisition

The UE applies the MCCH information acquisition procedure to acquire the MBMS control information that is broadcasted by the E-UTRAN. The procedure applies to MBMS capable UEs that are in RRC_IDLE or in RRC_CONNECTED.

5.8.2.2 Initiation

A UE interested to receive MBMS services shall apply the MCCH information acquisition procedure upon entering the corresponding MBSFN area (e.g. upon power on, following UE mobility) and upon receiving a notification that the MCCH information has changed. A UE that is receiving an MBMS service shall apply the MCCH information acquisition procedure to acquire the MCCH, that corresponds with the service that is being received, at the start of each modification period.

Unless explicitly stated otherwise in the procedural specification, the MCCH information acquisition procedure overwrites any stored MCCH information, i.e. delta configuration is not applicable for MCCH information and the UE discontinues using a field if it is absent in MCCH information unless explicitly specified otherwise.

5.8.2.3 MCCH information acquisition by the UE

An MBMS capable UE shall:

1> if the procedure is triggered by an MCCH information change notification:

2> start acquiring the MBSFNAreaConfiguration message and the MBMSCountingRequest message if present, from the beginning of the modification period following the one in which the change notification was received;

NOTE 1: The UE continues using the previously received MCCH information until the new MCCH information has been acquired.

1> if the UE enters an MBSFN area:

2> acquire the MBSFNAreaConfiguration message and the MBMSCountingRequest message if present, at the next repetition period;

1> if the UE is receiving an MBMS service:

2> start acquiring the MBSFNAreaConfiguration message and the MBMSCountingRequest message if present, that both concern the MBSFN area of the service that is being received, from the beginning of each modification period;

5.8.2.4 Actions upon reception of the MBSFNAreaConfiguration message

No UE requirements related to the contents of this MBSFNAreaConfiguration apply other than those specified elsewhere e.g. within procedures using the concerned system information, the corresponding field descriptions.

5.8.2.5 Actions upon reception of the MBMSCountingRequest message

Upon receiving MBMSCountingRequest message, the UE shall perform the MBMS Counting procedure as specified in 5.8.4.

5.8.3 MBMS PTM radio bearer configuration

5.8.3.1 General

The MBMS PTM radio bearer configuration procedure is used by the UE to configure RLC, MAC and the physical layer upon starting and/or stopping to receive an MRB. The procedure applies to UEs interested to receive one or more MBMS services.

NOTE: In case the UE is unable to receive an MBMS service due to capability limitations, upper layers may take appropriate action e.g. terminate a lower priority unicast service.

5.8.3.2 Initiation

The UE applies the MRB establishment procedure to start receiving a session of a service it has an interest in. The procedure may be initiated e.g. upon start of the MBMS session, upon (re-)entry of the corresponding MBSFN service area, upon becoming interested in the MBMS service, upon removal of UE capability limitations inhibiting reception of the concerned service.

The UE applies the MRB release procedure to stop receiving a session. The procedure may be initiated e.g. upon stop of the MBMS session, upon leaving the corresponding MBSFN service area, upon losing interest in the MBMS service, when capability limitations start inhibiting reception of the concerned service.

5.8.3.3 MRB establishment

Upon MRB establishment, the UE shall:

1> establish an RLC entity in accordance with the configuration specified in 9.1.1.4;

1> configure an MTCH logical channel in accordance with the received locgicalChannelIdentity, applicable for the MRB, as included in the MBSFNAreaConfiguration message;

1> configure the physical layer in accordance with the pmch-Config, applicable for the MRB, as included in the MBSFNAreaConfiguration message;

1> inform upper layers about the establishment of the MRB by indicating the corresponding tmgi and sessionId;

5.8.3.4 MRB release

Upon MRB release, the UE shall:

1> release the RLC entity as well as the related MAC and physical layer configuration;

1> inform upper layers about the release of the MRB by indicating the corresponding tmgi and sessionId;

5.8.4 MBMS Counting Procedure

5.8.4.1 General

Figure 5.8.4.1-1: MBMS Counting procedure

The MBMS Counting procedure is used by the E-UTRAN to count the number of RRC_CONNECTED mode UEs which are receiving via an MRB or interested to receive via an MRB the specified MBMS services.

The UE determines interest in an MBMS service, that is identified by the TMGI, by interaction with upper layers.

5.8.4.2 Initiation

E-UTRAN initiates the procedure by sending an MBMSCountingRequest message.

5.8.4.3 Reception of the MBMSCountingRequest message by the UE

Upon receiving the MBMSCountingRequest message, the UE in RRC_CONNECTED mode shall:

1> if the SystemInformationBlockType1, that provided the scheduling information for the systemInformationBlockType13 that included the configuration of the MCCH via which the MBMSCountingRequest message was received, contained the identity of the Registered PLMN; and

1> if the UE is receiving via an MRB or interested to receive via an MRB at least one of the services in the received countingRequestList:

2> if more than one entry is included in the mbsfn-AreaInfoList received in the SystemInformationBlockType13 that included the configuration of the MCCH via which the MBMSCountingRequest message was received:

3> include the mbsfn-AreaIndex in the MBMSCountingResponse message and set it to the index of the entry in the mbsfn-AreaInfoList within the received SystemInformationBlockType13 that corresponds with the MBSFN area used to transfer the received MBMSCountingRequest message;

2> for each MBMS service included in the received countingRequestList:

3> if the UE is receiving via an MRB or interested to receive via an MRB this MBMS service:

4> include an entry in the countingResponseList within the MBMSCountingResponse message with countingResponseService set it to the index of the entry in the countingRequestList within the received MBMSCountingRequest that corresponds with the MBMS service the UE is receiving or interested to receive;

2> submit the MBMSCountingResponse message to lower layers for transmission upon which the procedure ends;

NOTE 1: UEs that are receiving an MBMS User Service, as specified in TS 23.246 [56], by means of a Unicast Bearer Service, as specified in TS 26.346 [57], (i.e. via a DRB), but are interested to receive the concerned MBMS User Service, as specified in TS 23.246 [56], via an MBMS Bearer Service (i.e. via an MRB), respond to the counting request.

NOTE 2: If ciphering is used at upper layers, the UE does not respond to the counting request if it can not decipher the MBMS service for which counting is performed (see TS 22.146 [62], clause 5.3).

NOTE 3: The UE treats the MBMSCountingRequest messages received in each modification period independently. In the unlikely case E-UTRAN would repeat an MBMSCountingRequest (i.e. including the same services) in a subsequent modification period, the UE responds again. The UE provides at most one MBMSCountingResponse message to multiple transmission attempts of an MBMSCountingRequest messages in a given modification period.

5.8.5 MBMS interest indication

5.8.5.1 General

Figure 5.8.5.1-1: MBMS interest indication

The purpose of this procedure is to inform E-UTRAN that the UE is receiving or is interested to receive MBMS service(s) via an MRB or SC-MRB, and if so, to inform E-UTRAN about the priority of MBMS versus unicast reception or MBMS service(s) reception in receive only mode.

5.8.5.2 Initiation

An MBMS or SC-PTM capable UE in RRC_CONNECTED may initiate the procedure in several cases including upon successful connection establishment, upon entering or leaving the service area, upon session start or stop, upon change of interest, upon change of priority between MBMS reception and unicast reception, upon change to a PCell broadcasting SystemInformationBlockType15, upon starting and stopping of MBMS service(s) in receive only mode, upon change of receive only mode frequency, bandwidth or subcarrier spacing of MBMS service(s) in receive only mode.

Upon initiating the procedure, the UE shall:

1> if SystemInformationBlockType15 is broadcast by the PCell; or

1> if mbms-ROM-ServiceIndication is received in SystemInformationBlockType2 from PCell:

2> ensure having a valid version of SystemInformationBlockType15 for the PCell, if present;

2> if the UE did not transmit an MBMSInterestIndication message since last entering RRC_CONNECTED state; or

2> if since the last time the UE transmitted an MBMSInterestIndication message, the UE connected to a PCell neither broadcasting SystemInformationBlockType15 nor including mbms-ROM-ServiceIndication in SystemInformationBlockType2:

3> if the set of MBMS frequencies of interest, determined in accordance with 5.8.5.3, is not empty:

4> initiate transmission of the MBMSInterestIndication message in accordance with 5.8.5.4;

2> else:

3> if the set of MBMS frequencies of interest, determined in accordance with 5.8.5.3, has changed since the last transmission of the MBMSInterestIndication message; or

3> if at least one of the subcarrier spacing or bandwidth parameter of receive only mode MBMS frequency of interest, determined in accordance with 5.8.5.3, has changed since the last transmission of the MBMSInterestIndication message; or

3> if the prioritisation of reception of all indicated MBMS frequencies compared to reception of any of the established unicast bearers has changed since the last transmission of the MBMSInterestIndication message:

4> initiate transmission of the MBMSInterestIndication message in accordance with 5.8.5.4;

NOTE: The UE may send an MBMSInterestIndication even when it is able to receive the MBMS services it is interested in i.e. to avoid that the network allocates a configuration inhibiting MBMS reception.

3> else if SystemInformationBlockType20 is broadcast by the PCell:

4> if since the last time the UE transmitted an MBMSInterestIndication message, the UE connected to a PCell not broadcasting SystemInformationBlockType20; or

4> if the set of MBMS services of interest determined in accordance with 5.8.5.3a is different from mbms-Services included in the last transmission of the MBMSInterestIndication message;

5> initiate the transmission of the MBMSInterestIndication message in accordance with 5.8.5.4.

5.8.5.3 Determine MBMS frequencies of interest

The UE shall:

1> consider a frequency to be part of the MBMS frequencies of interest if the following conditions are met:

2> at least one MBMS session the UE is receiving or interested to receive via an MRB or SC-MRB is ongoing or about to start; and

NOTE 1: The UE may determine whether the session is ongoing from the start and stop time indicated in the User Service Description (USD), see TS 36.300 [9] or TS 26.346 [57].

2> for at least one of these MBMS sessions either SystemInformationBlockType15 acquired from the PCell includes for the concerned frequency one or more MBMS SAIs as indicated in the USD for this session or this session is in receive only mode; and

NOTE 2: The UE considers a frequency to be part of the MBMS frequencies of interest even though E-UTRAN may (temporarily) not employ an MRB or SC-MRB for the concerned session. I.e. the UE does not verify if the session is indicated on (SC-)MCCH

NOTE 3: The UE considers the frequencies of interest independently of any synchronization state, e.g. TS 36.300 [9], Annex J.1.

2> the UE is capable of simultaneously receiving MRBs and/or is capable of simultaneously receiving SC-MRBs on the set of MBMS frequencies of interest, regardless of whether a serving cell is configured on each of these frequencies or not; and

2> the supportedBandCombination the UE included in UE-EUTRA-Capability contains at least one band combination including the set of MBMS frequencies of interest;

NOTE 4: Indicating a frequency implies that the UE supports SystemInformationBlockType13 or SystemInformationBlockType20 acquisition for the concerned frequency i.e. the indication should be independent of whether a serving cell is configured on that frequency.

NOTE 5: When evaluating which frequencies it can receive simultaneously, the UE does not take into account the serving frequencies that are currently configured i.e. it only considers MBMS frequencies it is interested to receive.

NOTE 6: The set of MBMS frequencies of interest includes at most one frequency for a given physical frequency. The UE only considers a physical frequency to be part of the MBMS frequencies of interest if it supports at least one of the bands indicated for this physical frequency in SystemInformationBlockType1 (for serving frequency) or SystemInformationBlockType15 (for neighbouring frequencies). In this case, E-UTRAN may assume the UE supports MBMS reception on any of the bands supported by the UE (i.e. according to supportedBandCombination).

5.8.5.3a Determine MBMS services of interest

The UE shall:

1> consider a MBMS service to be part of the MBMS services of interest if the following conditions are met:

2> the UE is SC-PTM capable; and

2> the UE is receiving or interested to receive this service via an SC-MRB; and

2> one session of this service is ongoing or about to start; and

2> one or more MBMS SAIs in the USD for this service is included in SystemInformationBlockType15 acquired from the PCell for a frequency belonging to the set of MBMS frequencies of interest, determined according to 5.8.5.3.

5.8.5.4 Actions related to transmission of MBMSInterestIndication message

The UE shall set the contents of the MBMSInterestIndication message as follows:

1> if the set of MBMS frequencies of interest, determined in accordance with 5.8.5.3, is not empty:

2> include mbms-FreqList and set it to include the MBMS frequencies of interest sorted by decreasing order of interest, using the EARFCN corresponding with freqBandIndicator included in SystemInformationBlockType1 (for serving frequency), if applicable, and the EARFCN(s) as included in SystemInformationBlockType15 (for neighbouring frequencies);

NOTE 1: The EARFCN included in mbms-FreqList is merely used to indicate a physical frequency the UE is interested to receive i.e. the UE may not support the band corresponding to the included EARFCN (but it does support at least one of the bands indicated in system information for the concerned physical frequency).

2> include mbms-Priority if the UE prioritises reception of all indicated MBMS frequencies above reception of any of the unicast bearers;

2> if SystemInformationBlockType20 is broadcast by the PCell:

3> include mbms-Services and set it to indicate the set of MBMS services of interest determined in accordance with 5.8.5.3a;

NOTE 2: If the UE prioritises MBMS reception and unicast data cannot be supported because of congestion on the MBMS carrier(s), E-UTRAN may initiate release of unicast bearers. It is up to E-UTRAN implementation whether all bearers or only GBR bearers are released. E-UTRAN does not initiate re-establishment of the released unicast bearers upon alleviation of the congestion.

1> if the UE is receiving MBMS service(s) in receive only mode:

2> if the supportedBandCombination the UE included in UE-EUTRA-Capability contains at least one band combination including the mbms-ROM-Freq:

3> include mbms-ROM-Freq, mbms-ROM-SubcarrierSpacing and mbms-Bandwidth;

NOTE 3: The EARFCN included in mbms-ROM-Freq is used to indicate a physical frequency the UE is interested to receive MBMS service(s) in receive only mode and is determined based on UE implementation.

The UE shall submit the MBMSInterestIndication message to lower layers for transmission.