To provide MBMS bearer services existing functional entities, GGSN, MME, SGSN, eNodeB/RNC/BSC, perform several MBMS related functions and procedures, some of which are specific to MBMS. An MBMS specific functional entity - Broadcast Multicast Service Centre (BM-SC) supports various MBMS user service specific services such as provisioning and delivery. In the EPS a functional entity MBMS GW exists at the edge between the CN and the BM SC.
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:
Session and Transmission function;
Proxy and Transport function;
Service Announcement 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-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).
For GPRS, although these procedures mention GERAN and UTRAN extensively, only the BM-SC (which renders the content differently) and the SGSN have to implement functionality to deliver this. The GGSN, RNC and BSC shall all be transparent to this functionality.
For EPS, although these procedures mention UTRAN and E-UTRAN extensively, only the BM-SC and the MBMS-GW have to implement functionality to deliver this. The MME, S4-SGSN, RNC and eNodeB remain transparent to this functionality.
The same MBMS user service may transfer its data on separate MBMS bearer services for different access technologies, typically with different QoS, e.g. for GRPS using separate MBMS bearer services for GERAN and UTRAN or for EPS using separate MBMS bearer services for UTRAN and E-UTRAN. For this purpose two IP multicast addresses (multicast mode only) and/or two TMGIs should be allocated for the same MBMS user service. One IP multicast address (multicast mode only) and/or one TMGI is for, e.g. GERAN, and another IP multicast address (multicast mode) and/or another TMGI is for, e.g. UTRAN. The detailed impacts on the network nodes are listed below:
The service announcement instructs the UE to join two multicast MBMS bearer services (e.g. for GRPS one is for GERAN and the other is for UTRAN), i.e. for multicast mode, two IP multicast addresses that are allocated in the BM-SC are sent to UE within one service announcement message.
A UE that might move between areas covered by different access technologies activates both MBMS bearer services.
The UE monitors the paging/notification channels for both TMGIs and receives MBMS data when transferred by the MBMS bearer services.
When the BM-SC needs to deliver the content, the BM-SC produces two sets of MBMS data from the same content and sends independent Session Start messages for both of the MBMS bearer services. The "different" content streams for the same MBMS user service are sent on the separate MBMS bearer services. For GPRS, a 2G/3G indicator in the Session Start message (which the GGSN passes transparently to the SGSN) indicates whether the content should be delivered in GERAN-only or UTRAN-only (or both) coverage areas.
For GPRS, the SGSN uses the 2G/3G indicator to decide whether a MBMS Session Start Request message should be sent to the BSCs and/or the RNCs.
The same MBMS user service may also transfer its data on the same MBMS bearer service for multiple access technologies, i.e. for GRPS using a same MBMS bearer service for GERAN and UTRAN or for EPS using a same MBMS bearer service for UTRAN and E-UTRAN. For this purpose one IP multicast address (multicast mode only) and/or one TMGI should be allocated for the same MBMS user service. In such application, the "different" content for the same MBMS user service are sent in separate MBMS Sessions sequentially. For GRPS, the 2G/3G indicator in the Session Start message indicates whether the MBMS session should be delivered in GERAN-only or UTRAN-only (or both) coverage areas and the SGSN uses the 2G/3G indicator to decide whether a MBMS Session Start Request message should be sent to the BSCs and/or the RNCs.
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 UE shall support functions for the activation/deactivation of the MBMS bearer service.
Once a particular MBMS bearer service is activated, no further explicit user request is required to receive MBMS data although the user may be notified that data transfer is about to start.
The UE shall support security functions as appropriate for MBMS.
The UE should, depending on terminal capabilities, be able to receive MBMS user service announcements, paging information (non MBMS specific) and support simultaneous services (for example the user can originate or receive a call or send and receive messages whilst receiving MBMS video content). Reception of this paging or announcements may however, create losses in the MBMS data reception. The MBMS user service should be able to cope with such losses.
A UE in Multicast Mode shall be able to synchronise with the SGSN, which of its MBMS UE contexts are still active.
Depending upon terminal capability, UEs may be able to store MBMS data. This may involve DRM but this is out of scope of this specification.
The MBMS Session Identifier contained in the notification to the UE shall enable the UE to decide whether it needs to ignore the forthcoming transmission of MBMS session (e.g. because the UE has already received this MBMS session).
UTRAN/GERAN are responsible for efficiently delivering MBMS data to the designated MBMS service area.
Efficient delivery of MBMS data in multicast mode may require mechanisms in the UTRAN/GERAN, e.g. the number of users within a cell prior to and during MBMS transmission could be used to choose an appropriate radio bearer.
MBMS transmissions may be initiated and terminated intermittently. The UTRAN/GERAN shall support the initiation and termination of MBMS transmissions by the core-network. Further, the UTRAN/GERAN shall be able to receive MBMS data from the core-network over Iu bearers shared by many UEs.
.UTRAN (and GERAN in Iu mode) may also support reception of MBMS data from the core-network over IP multicast. When UTRAN (or GERAN Iu mode) supports IP multicast reception, the UTRAN (GERAN Iu mode) should support TEID coordination, i.e. avoid using the same value ranges for its own unicast TEIDs as are used by the GGSN and MBMS GW for the Common TEID-Us (C-TEIDs). If clashes anyhow occur, the RNC (Iu mode BSC) shall reject IP multicast reception and fallback to normal shared Iu bearers for reception of MBMS data.
The UTRAN/GERAN shall support both intra-RNC/BSC and inter-RNC/BSC mobility of MBMS receivers. Mobility is expected to cause limited data loss. Therefore, MBMS user services should be able to cope with potential data loss caused by UE mobility.
The UTRAN/GERAN shall be able to transmit MBMS user service announcements, paging information (non MBMS specific) and support other services in parallel with MBMS (for example depending on terminal capabilities the user could originate or receive a call or send and receive messages whilst receiving MBMS video content).
The SGSN's role within the MBMS architecture is to perform MBMS bearer service control functions for each individual UE and to provide MBMS transmissions to UTRAN/GERAN. When IP multicast is used for MBMS transmissions the SGSN is bypassed in the 3G case (and GERAN Iu mode case), i.e. MBMS data sent directly from GGSN to RNC (or Iu mode BSC) or from MBMS GW to RNC in EPS.
The SGSN shall provide support for intra-SGSN and inter-SGSN mobility procedures. Specifically this requires the SGSN to store a user-specific MBMS UE context for each activated multicast MBMS bearer service and to pass these contexts to the new SGSN during inter-SGSN mobility procedures.
The SGSN shall be able to indicate its MBMS support to the UE as well as it shall be able to synchronise with the UE, which of the UE's MBMS UE contexts are still active.
The SGSN shall be able to generate charging data per multicast MBMS bearer service for each user. The SGSN does not perform on-line charging for either the MBMS bearer service or the MBMS user service (this is handled in the BM-SC).
The SGSN shall be able to establish Iu and Gn bearers shared by many users upon receiving a session start from the GGSN. Likewise, the SGSN shall be able to tear down these bearers upon instruction from the GGSN.
When MBMS in EPS for UTRAN access is supported, the SGSN shall support the necessary control plane functions provided via Sn interface to/from MBMS GW.
The GGSN role within the MBMS architecture is to serve as an entry point for IP multicast traffic as MBMS data. Upon notification from the BM-SC the GGSN shall be able to request the establishment of a bearer plane for a broadcast or multicast MBMS transmission. Further, upon BM-SC notification the GGSN shall be able to tear down the established bearer plane. Bearer plane establishment for multicast services is carried out towards those SGSNs and /or RNCs that have requested to receive transmissions for the specific multicast MBMS bearer service. For an optimized bearer plane, IP multicast transport may be used within the core network. The bearer plane is then established between the GGSN and the RNCs.
When IP multicast is used for distribution payload from GGSN to RNC, and one or more RNC rejects IP multicast distribution, the GGSN should in parallel with the IP multicast distribution provide legacy MBMS payload distribution (i.e. using point-to-point GTP-tunnels) via the SGSNs to these RNCs. In that case, the GGSN shall remove the synchronisation protocol elements included by the BM-SC (i.e. synchronization information and the compressed header) before forwarding the payload on the legacy path (see TS 25.446).
The GGSN shall be able to receive MBMS specific IP multicast traffic and to route this data to the proper IP multicast distribution address and/or GTP tunnels set-up as part of the MBMS bearer service.
The GGSN may also provide features that support the MBMS bearer service that are not exclusive to MBMS. Examples are:
Message Screening (not needed if the MBMS sources are internal in the PLMN);
For group communications related services, the standard interface to and from BM-SC is MB2 (TS 23.468, TS 29.468). For services other than Group Communications, the standard reference point between the content provider and the BM-SC is defined in TS 26.348.
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.