The BM-SC provides functions for MBMS user service provisioning and delivery. It may serve as an entry point for content provider MBMS transmissions, used to authorise and initiate MBMS Bearer Services within the PLMN and can be used to schedule and deliver MBMS transmissions. The BM-SC is a functional entity, which must exist for each MBMS User Service. The BM-SC consists of the following sub-functions:

• Membership function;
• Session and Transmission function;
• Proxy and Transport function;
• Service Announcement function;
• Security function.
• Content synchronization for MBMS in UTRAN.
• Content synchronization for MBMS in E-UTRAN for broadcast mode.
• Header compression for MBSFN MBMS data in UTRAN.
• Header compression for Mission Critical services using MBMS in E-UTRAN (see TS 23.468).
• For MBMS bearer service for NB or M UE categories, provide mapping from UE Capability for MBMS as defined in TS 23.682 to QCIs as defined in clause 6.3.2.

This clause describes BM-SC functions, which are defined for the standardised MBMS User Services.

The BM-SC Membership function provides authorization for UEs requesting to activate an MBMS service. The Membership function may have subscription data of MBMS service users. The Membership Function may generate charging records for MBMS service users. The Membership Function is an MBMS bearer service level function, but it may also provide user service level functions e.g. membership management etc. In this case it does also have a Gi/SGi interface.

The BM-SC Session and Transmission Function shall be able to schedule MBMS session transmissions. The BM-SC Session and Transmission Function should be able to schedule MBMS session retransmissions, and label each MBMS session with an MBMS Session Identifier to allow the UE to distinguish the MBMS session retransmissions. The BM-SC Session and Transmission Function allocates TMGIs. Each transmission and subsequent retransmission(s) of a specific MBMS session are identifiable by a common MBMS Session Identifier (2-3 Octets) passed at the application layer in the content, and also passed in a shortened form (i.e. the least significant octet) in the MBMS Session Start Request message to the eNodeBs/RNCs/BSCs. The full MBMS Session Identifier should be used by the UE to identify an MBMS session when completing point-to-point repair, while the shortened MBMS Session Identifier is included by the RANs in the notification messages for MBMS The BM-SC Session and Transmission Function shall be able to provide the MBMS GW or GGSN with transport associated parameters such as quality-of-service and MBMS service area. The BM-SC Session and Transmission Function shall be able to initiate and terminate MBMS bearer resources prior to and following transmission of MBMS data. The BM-SC Session and Transmission Function should be able to send MBMS data. It could also apply favourable error resilient schemes e.g. specialized MBMS codecs or Forward Error Correction schemes. When IP multicast is used for distribution of payload from GGSN to RNC or from MBMS GW to eNodeB and RNC, the BM-SC Session and Transmission Function shall include synchronization information for the MBMS payload. If the header compression is used over the radio, the compression is done in the BM-SC. The details of synchronization and header compression for the MBMS payload are specified in TS 25.346 and TS 25.446. The BM-SC Session and Transmission Function should be able to authenticate and authorize external sources and accept content from them. The Session and Transmission Function is user service level function and it triggers bearer level functions when MBMS sessions are scheduled.

The BM-SC Proxy and Transport Function is a Proxy Agent for signalling over SGmb and Gmb reference points between MBMS GWs/GGSNs and other BM-SC sub-functions, e.g. the BM-SC Membership Function and the BM-SC Session and Transmission Function. Further, the BM-SC Proxy and Transport Function shall also be able to handle when BM-SC functions for different MBMS services are provided by multiple physical network elements. Routing of the different signalling interactions shall be transparent to the MBMS GW and the GGSN. The BM-SC Proxy and Transport function shall be able to generate charging records for content provider charging of transmitted data. Content provider name is provided to BM-SC Proxy and Transport function over SGmb/Gmb at session start. The BM-SC Proxy and Transport function may act as an intermediate device for the MBMS data sent from the BM-SC Session and Transmission function to the MBMS GW or GGSN. The Proxy and Transport Function may be divided further into a Proxy function managing the control plane (SGmb/Gmb) and a Transport function managing the multicast payload. The Proxy and Transport Function is an MBMS bearer service function.

The BM-SC Service Announcement function shall be able to provide service announcements for multicast and broadcast MBMS user services. The BM-SC Service Announcement function shall be able to provide the UE with media descriptions specifying the media to be delivered as part of an MBMS user service (e.g. type of video and audio encodings). The BM-SC Service Announcement function shall be able to provide the UE with MBMS session descriptions specifying the MBMS sessions to be delivered as part of an MBMS user service (e.g. multicast service identification, addressing, time of transmission, etc.). The BM-SC Service Announcement function shall be able to deliver media and session descriptions by means of service announcements using IETF specified protocols over MBMS multicast and broadcast bearer services. The Service Announcement Function is a user service level function. The following mechanisms should be supported for service announcement. Service announcements may be triggered by the BM-SC but are not necessarily sent by the BM-SC:

• MBMS bearer capabilities to advertise MBMS user Services;
• PUSH mechanism (WAP push);
• URL (WAP, HTTP);
• SMS (point-to-point);
• SMS-CB cell broadcast.

Other mechanisms could be considered in future releases.

MBMS user services may use the Security functions for integrity and/or confidentiality protection of MBMS data. The MBMS Security function is used for distributing MBMS keys (Key Distribution Function) to authorized UEs. Detailed description of the security functions is provided in (TS 33.246).

Some MBMS user services may broadcast different content in different areas of the network. In such case the UE is not aware of the relation between location and content, i.e. the UE just activates the reception of the service and receives the content that is relevant for its location. The BM SC controls which content is broadcasted in which area by establishing a separate MBMS bearer service for each content data flow. All MBMS bearer services of the same MBMS user service share the same TMGI but bear different Flow Identifiers. The BM SC allocates the Flow Identifier during the MBMS Session Start procedure and initiates a separate session for each content data flow. For IP Multicast support in EPS, the MBMS GW allocates an IP Multicast Address based on the TMGI and Flow Identifier (broadcast mode only). Since in any specific location only one version of the content shall be available at any point in time, the MBMS Service Areas of each session of a same user service shall not overlap; this shall be ensured by proper configuration of the service in the BM SC. The RNC and the eNodeB ultimately enforces this constraint by rejecting any session start request with the same TMGI as an already active session if there is any overlap in the respective service areas. As indicated above, the UE is unaware of the Flow Identifier and of the existence of multiple sessions for the same MBMS user service.

MBMS User Service Consumption Reporting functionality better enables the MBMS service operator to decide in a dynamic manner, based on real time demand of an MBMS User Service, to either:

• establish service delivery over an MBMS bearer;
• tear down service delivery over an already established MBMS bearer to only leave service delivery over unicast.

By permitting these decisions to be made dynamically, this functionality enables the MBMS service operator to better utilize overall network resources in supporting unicast and/or MBMS services delivery. The MBMS service consumption reporting procedure is optional and initiated by the MBMS receiver (UE) to the BM-SC, in accordance with parameters in the Associated Delivery Procedure description as defined in TS 26.346. The BM-SC can specify the nominal periodicity by which the UE, when it is continuously consuming the service of concern, performs consumption reporting. The BM-SC can specify whether the UE includes its current location (serving cell-ID or MBMS SAI) when it performs consumption reporting. The location type is selected based on the Associated Delivery Procedure Description settings, or the MooD Management Object (MO) on the UE, or via UE pre-configuration rules. Typically, the BM-SC is pre-configured, via OAM procedures, with a threshold per location (number of UEs reporting consumption) to be used in making the decision to switch delivery method. The service offloaded to the MBMS bearer could be either one delivered by unicast not involving MBMS User Services, or an MBMS User Service delivered on a unicast bearer. Furthermore, the BM-SC can determine, based on Consumption Reporting from UEs consuming that MBMS User Service over an MBMS bearer, the interest for that MBMS User Service has decreased sufficiently to terminate the MBMS bearer. In such event, UEs may continue to receive the service but over unicast instead, either not involving the MBMS User Service, or as an MBMS User Service over unicast. Continued consumption monitoring by the BM-SC, and consumption reporting by UEs, may be employed to facilitate further switching, over time, between bearer modes. Along with MBMS Consumption Reporting, the use of MBMS operation on Demand (clause 7.4) permits certain content that is initially delivered over the unicast network to be turned into an MBMS User Service, in order to efficiently use network resources when the traffic exceeds a certain threshold.

The Cell Broadcast Centre (CBC) may be used to announce MBMS user services to the users.

One or more MBMS GW function entities may be used in a PLMN. Note that MBMS GW may be stand alone or co-located with other network elements such as BM-SC or combined S GW/PDN GW. MBMS GW functions include:

• It provides an interface for entities using MBMS bearers through the SGi-mb (user plane) reference point;
• It provides an interface for entities using MBMS bearers through the SGmb (control plane) reference point;
• IP multicast distribution of MBMS user plane data to E-UTRAN (M1 reference point). If the MBMS GW has allocated both an IPv4 and an IPv6 IP Multicast address, IP multicast distribution of MBMS user plane data is performed towards both IP Multicast addresses, using the same C-TEID;
• IP multicast distribution of MBMS user plane data to RNCs (M1 reference point);
• In the case of UTRAN access, it allocates either an IPv4 or an IPv6 IP Multicast address. An RNC should join to IP Multicast distribution to receive the MBMS data. The IP Multicast address together with the IP address of the multicast source (SSM) and a C-TEID is provided to the RNC via SGSN;
• In the case of E-UTRAN access, and if the MBMS GW supports both IPv4 and IPv6, it may allocate both an IPv4 and an IPv6 IP Multicast address (e.g. in deployments with a mix of IPv4 and IPv6 eNodeBs and/or backhauls). Otherwise it allocates either an IPv4 or an IPv6 IP Multicast address. An eNodeB should join to IP Multicast distribution using one IP Multicast address (either IPv4 or IPv6) to receive the MBMS data. When a single IP Multicast address is allocated by the MBMS-GW, this IP Multicast address together with the IP address of the multicast source (SSM) and a C-TEID is provided to the eNodeB via MME. When two IP Multicast addresses are allocated by the MBMS-GW:
  • each of them is associated with an IP address of the multicast source (SSM);
  • the same C-TEID is associated to both IP Multicast addresses;
  • both IP Multicast addresses together with the corresponding IP addresses of the multicast source (SSM) and the C-TEID is provided to the E-UTRAN via MME;
  The IP Multicast Address or, optionally in case of E-UTRAN access and if the MBMS GW supports both IPv4 and IPv6, both an IPv4 and an IPv6 IP Multicast address are either uniquely allocated for the MBMS bearer service (identified by the TMGI and Flow Identifier), or it may be reused from another active MBMS bearer service with an identical service area and of the same QoS.
• An MBMS GW may support fall back to point to point mode where applicable for UTRAN access;
• An MBMS GW can communicate with multiple control plane entities (i.e. MME, SGSN and BM-SCs).

The MBMS control plane function is supported by MME for E-UTRAN access and by SGSN for UTRAN access. For SGSN functions, see clause 5.4. One or more MBMS control plane functional entities are used in a PLMN. MME supports the following functions in order to enable MBMS support for E-UTRAN:

• Session control of MBMS bearers to the E-UTRAN access (including reliable delivery of Session Start/Session Stop to E-UTRAN);
• Transmit Session control messages towards multiple E-UTRAN nodes;
• When connected to multiple MCEs (see TS 36.300), the MME should filter the distribution of Session Control message to the MCEs based on the MBMS service area;
• Provision of the list of MBMS Service Areas served by the MCE to the MME using M3AP Setup signalling;
• Transmit Session Control messages towards the necessary E-UTRAN nodes to ensure the distribution of content from ongoing MBMS sessions:
  • if an MCE sets up (or restarts) an M3AP connection with the MME, by applying the MCE Failure procedure specified in TS 23.007; or
  • if the MCE modifies the list of MBMS Service Areas it serves, by triggering the MCE Configuration Update procedure.
• It provides an Sm interface to the MBMS GW function: it receives MBMS service control messages and the IP Multicast address or, optionally, (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 MBMS data reception from MBMS GW function over the Sm interface.

E-UTRAN is responsible for efficiently delivering MBMS data to the designated MBMS service area. The E-UTRAN for MBMS in EPS shall have capability of receiving IP multicast distribution. In order to provide the appropriate MBMS bearer service for NB or M UE categories, E-UTRAN/MCE may map received QCI into appropriate radio configurations for the appropriate UE categories, when such mapping is configured as described in clause 6.3.2.