The MBMS (multimedia broadcast multicast service) feature includes the MBMS Bearer Service and the MBMS User Service, which are defined over both UTRAN (i.e. WCDMA, TD-CDMA and TD-SCDMA) and LTE (referred to as eMBMS). The eMBMS (evolved multimedia broadcast multicast service), also referred as LTE Broadcast, is an advanced mobile data delivery technology that enables mobile operators to significantly reduce the cost of delivery.
NOTES:
|
The reference points below are applicable for the E-UTRAN and UTRAN MBMS Broadcast Mode (with or without counting).
M1 | The reference point between MBMS GW and E-UTRAN/UTRAN for MBMS data delivery. IP Multicast is used on this interface to forward data. |
M3 | The reference point for the control plane between MME and E-UTRAN. |
Sm | The reference point for the control plane between MME and MBMS GW. |
Sn | The reference point between MBMS GW and SGSN (S4 based) for the control plane and for MBMS data delivery. Point-to-point mode is used on this interface to forward data. |
SGi-mb | The reference point between BM-SC and MBMS GW function for MBMS data delivery. |
SGmb | The reference point for the control plane between BM-SC and MBMS GW. |
The Sm reference point is based on GTPv2-C.
The Sn reference point is based on GTPv2-C and GTPv1-U.
The M1 reference point is based on GTPv1-U.
BM-SC | The BM-SC (Broadcast-Multicast Service Centre) provides functions for MBMS user service provisioning and delivery to the content provider. It also serves as an entry point for IP MBMS data traffic from the MBMS User Service source. |
MBMS-GW | The MBMS-GW (for EPS) serves as an entry point for IP multicast traffic as MBMS data from the BM-SC. |
The Capacity and Session Loading tests determine the maximum rate at which UEs discover and access eMBMS broadcast user services. The SUT is used to determine the maximum numbers of user services and eMBMS broadcast sessions supported.
The eMBMS Nodal test case supports the broadcast mode MBMS service (in Phase one). Supports the following interfaces:
Sm interface |
Control plane between MME and MBMS GW. |
M1 interface |
User plane between MBMS GW and eNodeB for MBMS data delivery. IP Multicast is used on this interface to forward data. |
SGi interface |
BM-SC communicates with UE via SGi interface. For example, BM-SC delivers MBMS service announcements to UE by WAP, MMS and HTTP via SGi. |
Proprietary interface for service provisioning |
Control plane between user service/content provider and BM-SC. Landslide DMF is used to simulate any proprietary interface defined by you based on IP network. |
Proprietary interface for MBMS data transmission |
User plane between user service/content provider and BM-SC, assumes the data traffic goes through TCP/IP network which can be simulated by Landslide DMF. |
NOTE: Proprietary control plane and user plane traffic between BM-SC and content provider maybe simulated by one combined DMF, depending on the specific user services. You must configure Next Hop the NWH IP address of SUT BM-SC.
|
The MBMS Node emulates interfaces for service provisioning between BM-SC and content provider. User service data simulated by DMF configured on the Network Host is sent to BM-SC (MBMS node side) after the Data Traffic starts (The next hop of the Network Host must be set to the IP address of BM-SC configured in the MBMS node).
Sm interface |
Control plane between MME and MBMS GW. |
M1 interface |
User plane between MBMS GW and eNodeB for MBMS data delivery. IP Multicast is used on this interface to forward data. |
SGi interface | BM-SC communicates with UE via SGi interface. For example, BM-SC delivers MBMS service announcements to UE by WAP, MMS and HTTP via SGi. |
SGmb interface | Control plane between BM-SC and MBMS GW. |
SGimb interface | User plane between BM-SC and MBMS GW for MBMS data delivery. IP unicast encapsulation of IP multicast datagrams is used on this interface to forward data. |
Figure below shows an example of Landslide configuration for BM-SC isolation testing. The main functional focus is :
Transferring the content to the BM-SC from the emulated Content Server
Key protocols: Web-DAV and DASH
Receiving the Content on the emulated Handset/enodeB
Key Protocols: FLUTE, SYNC and DASH
The primary test metrics are focused on measuring the delivery aspects of the DASH segments to the enodeB/UE from the BM-SC via the FLUTE protocol. This includes packet loss within the Dash File segments, arrival time as compared to broadcast time, and inter-Dash File Segment Jitter analysis.
While WEB DAV is required on the Content Server side to perform the test, the Web-DAV interface is not the primary focus for test metrics.
Supported configurations :
BM-SC Testing (UE/enB, MME, S/PGW, eMBMS-GTW and content server emulation)
BMSC + eMBMS-GTW testing (UE/enB, MME, S/PGW and content server emulation)
BMSC + eMBMS-GTW + EPC testing (UE/enB + Content server emulation)
In many scenarios, the BM-SC needs to be emulated by Landslide. There are many complex configurations where BM-SC emulation may be required. Examples include when the primary SUT is an eMBMS-GW, MME, S/P-GW or even a real enodeB+UE. The following assumptions are valid when emulating the BM-SC with FLUTE/SYNC + DASH support in Landslide.
When Landslide is the BM-SC, we have a standalone IP App Node to emulate content provider.
eMBMS GTW can be Landslide-emulated or Real.
Landslide is also the terminating UE/enodeB using either eMBMS nodal, MME Nodal, or SGW Nodal.
Real enodeB and Real UE supported.
Figure below shows a basic configuration for the eMBMS Content Option where Landslide is emulating the content server, the BM-SC and the enodeB/UE for the purposes of testing the EPC and the MBMS-GW. A real UE/enB can replace the Landslide enodeB/UE.
For MBMS Service Delivery, we support 3 levels of related network elements.
eMBMS-GW and BMSC are 1 to 1 delivery. Each MBMS Service Bearer in BMSC maps to 1 MBMS Service Bearer in eMBMS-GW.
eMBMS-GW and MME are 1 to many (up to 32) delivery. This means each MBMS Service can be delivered to 32 MMEs in a group.
MME and eNodeB are 1 to many (depends on the eNodeB number connected to MME).
Each MBMS service should have a M3AP session in eNodeB.
eMBMS Service Delivery
In the example above, 1 service deliver to MME Group 1 and 2 eNodeBs connected to MME1, sessions needed in each node:
BMSC : 1 Service Bearer
eMBMS-GW : 1 Service Bearer and 3 Sm Sessions (need to deliver the service to 3 MMEs in MME Group 1)
MME1 : 1 Sm Sessions and 2 M3AP Sessions (2 eNodeBs connected to MME1)
eNodeB1 : 1 M3AP Session