It shall be possible for the network to control quality-of-service parameters for sessions of multicast and broadcast MBMS bearer services. All QoS attributes related to the UMTS bearer service described in TS 23.107 are applicable to MBMS bearer services. Compared to point-to-point bearer services the following limitations exist:

• For traffic class, only the background and streaming classes shall be supported.
• For SDU error ratio, only higher values are supported, i.e. the values describing higher numbers of lost or corrupted SDUs (actual values are for the background and streaming classes are 10-2 and 10-1).
• For maximum bit-rate, see the values described in TS 22.246.
• For Guaranteed bit rate of the Streaming Traffic Class: depending on radio resource usage by other services, some cells of the MBMS Service Area may not have sufficient resources available for a MBMS Session. The RAN may decide not to establish RB in cells where requested resources are not available. The RAN does not reject a MBMS Session Start Request message even if one or more cells do not have enough resources to establish radio bearers.

MBMS bearer services of background class are best suited for the transport of MBMS user services such as messaging or downloading. Buffering, shaping schemes and packet dropping may be applied to the traffic flow to adapt to the available resources and changing network conditions. The total transfer time is not critical for background class bearer services since the content must normally have been received in totality and stored in the UE before the user can access it. MBMS bearer services of streaming class are best suited for the transport of MBMS user services such as streaming. As for point-to-point bearer services, the network should minimise the packet transfer delay of streaming class bearer services as far as possible. Packet dropping should be the preferred traffic conditioning action applied to the traffic flow to adapt to the available resources. The principle difference between background and streaming classes for MBMS is the support of a guaranteed bit-rate in the streaming case. No indication is provided to the UE in cases where the RAN cannot provide the requested QoS. As a result, some UEs may not receive the MBMS session or parts of it. For background class, the RAN may continue to distribute data in congestion conditions but at potentially high packet loss rates, therefore the MBMS user service will have to provide sufficient redundancy within the data to be able to cope with the high packet loss. MBMS user services that would normally use MBMS bearer services of background class may however decide to use a streaming class MBMS bearer service if the MBMS user service cannot cope with high packet loss. The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer services. As the MBMS bearer service transfers data to many UEs in parallel and because of the lack of feedback channel on radio level low SDU error ratios are difficult to achieve. When the resulting packet error ratio is not suitable for the MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of MBMS data over a point-to-point PDP context.

It shall be possible for the network to control quality-of-service parameters for sessions of broadcast MBMS bearer services. All EPS QoS attributes related to the EPS bearer service are applicable to MBMS bearer services. For EPS, only GBR MBMS service is defined and the MBMS bearer service QoS includes the parameters QCI, ARP, GBR and MBR (TS 23.401). For E-UTRAN MBMS bearer service for NB or M UE categories, operator defined QCIs may be configured in the BMSC and in the EUTRAN. The BMSC may take into account the UE Capability for MBMS received via Activate MBMS Bearer Request in addition to the QoS requirements of the service and map that to a QCI value that is sent using MBMS Session Start Procedure towards EUTRAN (see TS 23.682). BMSC may be configured to take into account the UE Category for MBMS to derive operator defined QCIs. An example mapping is shown below for a service with otherwise the same QoS requirements:

The BMSC may receive coverage level information for MBMS in addition to the UE Category for MBMS. When coverage information is received, and the BMSC is configured to take into account the coverage level, then BMSC generates the appropriate QCI based on the UE Category for MBMS and coverage level information for the MBMS service as defined in TS 23.682. An example mapping is shown below for a service with otherwise the same QoS requirements including coverage level:

Each GBR MBMS bearer service is associated with the following MBMS bearer level QoS parameters:

• QoS Class Identifier (QCI);
• Allocation and Retention Priority (ARP);
• Maximum Bit Rate (MBR);
• Guaranteed Bit Rate (GBR).

Unlike point-to-point EPS bearers, the MBR of a particular GBR bearer service shall be set equal to the GBR. Compared to point-to-point bearer services the following limitations exist:

• For Guaranteed bit rate: depending on radio resource usage by other services, some cells of the MBMS Service Area may not have sufficient resources available for a MBMS Session. The RAN may decide not to establish RB in cells where requested resources are not available. The RAN does not reject a MBMS Session Start Request message even if one or more cells do not have enough resources to establish radio bearers.
• MBMS bearer admission control within E-UTRAN is constrained by the E-UTRAN resources that are configured for MBMS.

In the case of E-UTRAN, established MBMS bearers may not always use all the resources configured for MBMS. When the resources configured for MBMS are not fully utilised, the E-UTRAN may schedule delivery of traffic from point-to-point bearers using some of the un-utilised MBMS resources (refer to TS 36.213). GBR MBMS bearer services are best suited for the transport of MBMS user services where a constant bit rate is needed. As for point-to-point bearer services, the network should comply with the transfer delay for GBR QCI's (TS 23.203). Packet dropping should be the preferred traffic conditioning action applied to the traffic flow to adapt to the available resources. The BM-SC ensures that the bit rate is not larger than the MBR. There is no radio aware flow shaping in the BM-SC. The Allocation and Retention Priority of the MBMS bearer service allows for prioritisation between MBMS bearer services at MBMS bearer service establishment. When the MBMS bearer service experience a packet error ratio which is not suitable for the MBMS user service or when prevention of data loss is required, an MBMS user service may perform retransmission of MBMS data over a point-to-point PDP context or PDN connection.

MBMS data will be distributed to multiple users through a MBMS distribution tree that can go through many BSCs/RNCs, many SGSNs and one or more GGSNs. Furthermore some bearer resources may be shared between many users accessing the same MBMS bearer service in order to save resources. As a result, each branch of a MBMS distribution tree shall be established with the same QoS. MBMS distribution tree shall have the same QoS for all its branches. When a branch of the MBMS distribution tree has been created, it is not possible for another branch (e.g. due to arrival of a new UE or change of location of a UE with removal of a branch and addition of a new one) to impact the QoS of already established branches. There is no QoS (re-)negotiation between network elements (e.g. between RNC and SGSN). This implies that some branches may not be established if QoS requirement cannot be accepted by the concerned network node.

For GPRS in GGSN or for EPS in MBMS GW it shall by configuration be possible to enable distribution of MBMS payload by using IP Multicast in the backbone network. IP Multicast distribution is done from GGSN to RNC downstream nodes or from MBMS GW to eNodeB or RNC downstream nodes. The Source Specific Multicast (SSM) service model shall be used by nodes and routers as specified in RFC 4607 and RFC 4604.

Fallback to legacy point-to-point distribution is done for RNC nodes which do not support IP Multicast distribution. The GGSN chooses an IP Multicast address for distribution and a Source address as well as a common TEID-U (C TEID). The proposed IP Multicast and Source address for distribution and the C-TEID is indicated by the GGSN to the downstream SGSNs at Session Start. The SGSN forwards the request to the downstream RNC (and BSC in Iu mode) at Session Start. The RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session Start Response to the SGSN. If accepted the RNC shall report the channel (IP Multicast and Source address) to the backbone in order to join the bearer service multicast distribution. At Session Stop the RNC shall correspondingly report to the backbone in order to leave the bearer service multicast distribution. If one or more downstream RNC nodes do not accept IP Multicast distribution, the SGSN will establish a normal MBMS point-to-point GTP-U tunnel to related RNCs and a point-to-point GTP-U tunnel to the GGSN. The SGSN does not respond to the GGSN until it has received responses from all RNCs. The SGSN shall indicate to the GGSN if IP Multicast distribution is accepted (by one or more RNCs) and it shall also indicate if normal MBMS point-to-point distribution is required (by one or more RNCs). The SGSN will also establish a normal MBMS point-to-point GTP-U tunnel to GGSN if there are BSCs in Gb mode in the MBMS distribution tree. The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If this indication is missing, the SGSN node shall treat the RNC node as not accepting IP Multicast distribution and use unicast distribution. IP Multicast distribution is only used within a PLMN. In the roaming case the GGSN establishes normal MBMS point-to-point GTP-U tunnels to SGSNs/RAN nodes in other networks. GGSN shall assign IP Multicast addresses used for MBMS distribution according to RFC 4607. When several GGSN are used for MBMS payload distribution, the used IP Multicast addresses and common TEIDs shall be coordinated by configuration. Clashes between common TEIDs allocated by GGSN and TEIDs allocated by RNC should be avoided by coordinated TEID ranges. The GTP-U Error Indication mechanism shall be disabled for MBMS bearers using IP Multicast distribution. The receiving node controls itself what is received using the IGMPv3/MLDv2 protocol, RFC 4604. The MBMS payload with the synchronization information received from the BM-SC included, shall be distributed by the GGSN with IP Multicast to the RNC. The synchronization information is used in the radio interface for the user data transmission synchronization across the RNCs as described in TS 25.346. It is up to RAN configurations whether the inter-RNC MBMS combining/MBSFN operation mode is used during the MBMS payload delivery.

The MBMS GW chooses an IP Multicast address for distribution or, optionally, in the case of E-UTRAN access (e.g. in deployments with a mix of IPv4 and IPv6 eNodeBs and/or backhauls) and if the MBMS GW supports both IPv4 and IPv6, both an IPv4 and an IPv6 IP Multicast address for distribution. The IP Multicast Addresses may be unique for the MBMS bearer service, or it may be reused from another active MBMS bearer service with an identical service area and of the same QoS. The proposed IP Multicast and Source addresses for distribution is indicated by the MBMS GW to the downstream MMEs and/or SGSNs at Session Start. The MME/SGSN forwards the request to the downstream eNodeB/RNC at Session Start. In the UTRAN case, the RNC may accept or reject the proposed IP Multicast distribution in the MBMS Session Start Response to the SGSN. The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If accepted the RNC shall report the channel (IP Multicast and Source address) to the backbone in order to join the bearer service multicast distribution. For an IP Multicast address that is shared by several MBMS bearer services, RNC only reports to the backbone once. At Session Stop the RNC shall correspondingly report to the backbone in order to leave the bearer service multicast distribution. For a MBMS bearer service that shares the IP Multicast address with one or more other MBMS bearer service(s), the RNC does only report to the backbone at session stop of the last remaining bearer service that has used a shared IP Multicast address. If one or more downstream RNC nodes do not accept IP Multicast distribution, the SGSN will establish a normal MBMS point-to-point GTP-U tunnel to related RNCs and a point-to-point GTP-U tunnel to the MBMS GW. The SGSN does not respond to the MBMS GW until it has received responses from all RNCs or until a configurable time has elapsed (e.g. with a recommended default of 5 seconds). The SGSN shall indicate to the MBMS GW if IP Multicast distribution is accepted (by one or more RNCs) and it shall also indicate if normal MBMS point-to-point distribution is required (by one or more RNCs). The RNC node shall indicate to SGSN if IP Multicast distribution is accepted in the Session Start Response. If this indication is missing, the SGSN node shall treat the RNC node as not accepting IP Multicast distribution and use unicast distribution. IP Multicast distribution is only used within a PLMN. MBMS GW shall assign IP Multicast addresses used for MBMS distribution according to RFC 4607. When several MBMS GWs are used for MBMS payload distribution, the used IP Multicast addresses shall be coordinated by configuration. Clashes between common TEIDs allocated by MBMS GW and TEIDs allocated by eNodeB/RNC should be avoided by coordinated TEID ranges. The receiving node controls itself what is received using the IGMPv3/MLDv2 protocol RFC 4604. The MBMS payload with the synchronization information received from the BM-SC shall be distributed by the MBMS GW with IP Multicast to the eNodeB/RNC. The synchronization information is used in the radio interface for the user data transmission synchronization across the eNodeBs and RNCs as described in TS 25.346. It is up to RAN configurations whether the inter-RNC MBMS combining/MBSFN operation mode is used during the MBMS payload delivery. Mobility between cells may cause limited MBMS data loss towards the UE. Therefore, MBMS user services should be able to cope with potential data loss caused by UE mobility.