Amarisoft

LTE MBMS

This tutorial is to show you how to configure and test MBMS.  MBMS stands for Multimedia Broadcast/Multicast Service and it is technology designed to deliver broadcast or multicast content to multiple users simultaneously in a more efficient manner.  It's especially useful for services like live TV, radio broadcasts, and other multimedia content that needs to be transmitted to a large number of users at once

Amarisoft supports MBMS by implementing a special gateway called MBMSGW. The key features of MBMSGW are

 

 

Table of Contents

 

 

Test Setup

Test setup for this tutorial is as shown below.  This is just for low layer testing, you may not need any complicated IP layer setup.

If you have a commercial UE that support UE assistance information with Release Preference, you can use the Setup A. If you don't have any commercial UE supporting this feature but have Amarisoft UEsim you can use Setup B. In this Test, Setup B is used.

 

Setup A

This is the setup for the case where you use a commercial phone as DUT.

TestSetup Callbox UE 1sdr 01

 

Setup B

This is the setup for the case where you use Amarisoft UEsim as DUT.

TestSetup Callbox UEsim 1sdr 01

 

 

Key Configuration Parameters

 

Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.

 

 

Test 1 : Broadcasting from eNB with NO UE Connection

This test show the simplest way of testing MBMS which does not even require any UE connection. Since MBMS is broadcasting technology, it does not require any dedicated connection to a specific UE. In this test, I will go through the basic configuration for MBMS on network side and show how to verify the transmission of broadcast data on network side only.  .

 

Configuration

I have used enb-mbms.cfg which is provided with installation package

NR SA NPN Test 1 Config 01

I am using mbmsgw.cfg which are provided by the installation package..

NR SA NPN Test 1 Config 02

 

enb-mbms.cfg is configured as follows.

Setting up basic configuration (e.g, frequency, cell id etc) are same as regular configuration.

The special configuration on eNB is mbms block which specifies synchronization_area_id, service_area_id_list, sib13 periodicity and notification_config etc.

mbmsgw.cfg carries most of service related configuration and specifies some physical layer configurations for MBMS.

I used the mbmsgw.cfg which comes with installation package almost with no change. The onlything that I changed is log_options. I set all.level=debug to collect the detailed log.

This MBMS configuration defines two broadcast services in this test.

Following is the configurations for the first service. It is identified by the PLMN (plmn: "00101") and service ID (service_id: 0x000001). It operates in service area 1 (service_area_id: 1) and uses a local IP address (gtp_addr: "127.0.2.1") and GTP tunnel identifier (gtp_teid: 1) . The service broadcasts two simulated multicast streams defined under components: a video stream from IP and port 225.1.0.1:1234 with a bitrate of 800 kbps (bitrate: 800e3), and an audio stream from 225.1.0.2:1234 at 64 kbps (bitrate: 64e3), both with simulation enabled (sim: true). The scheduling interval for broadcasting is set to 640 ms (scheduling_period: 64)

Following is the configurations for the second service. It is identified by the PLMN (plmn: "00101") and service ID (service_id: 0x000002). It operates in service area 2 (service_area_id: 1) and uses a local IP address (gtp_addr: "127.0.2.1") and GTP tunnel identifier (gtp_teid: 2). The service broadcasts two simulated multicast streams defined under components: a video stream from IP and port 225.1.0.1:1234 with a bitrate of 800 kbps (bitrate: 800e3), and an audio stream from 225.1.0.2:1234 at 64 kbps (bitrate: 64e3), both with simulation enabled (sim: true). The scheduling interval for broadcasting is set to 640 ms (scheduling_period: 64)

Following configuration defines the MBMS transmission area with area ID (area_id: 1) and sets the number of CCH symbols to 1 (non_mbsfn_region_length: 1). The mcch_config block specifies the control channel parameters for this area. The MCCH repetition period is set to 64 (mcch_repetition_period: 64), meaning MCCH messages are repeated every 640 ms. The offset for MCCH transmission is 0 (mcch_offset: 0), indicating no delay from the period start. MCCH modification information is updated every 5120 ms (mcch_modification_period: 512). The subframe allocation is defined by the bitmap (mcch_sf_alloc: '100000'), where only subframe 1 is used for MCCH. The modulation and MCS for signaling is set to 7 (signalling_mcs: 7)

Following configuration defines the MBSFN area settings used for MBMS transmission. Under common_sf_alloc, it sets the radio frame allocation period (radio_frame_allocation_period: 1) and offset (radio_frame_allocation_offset: 0), along with the subframe bitmap (subframe_allocation: "100000"), which enables transmission in subframe 1 only.

The overall allocation cycle is specified by common_sf_alloc_period: 64, meaning the subframe pattern repeats every 64 radio frames (640 ms). The pmch_info_list block contains configuration for the PMCH. The pmch_config sets the number of subframes used per allocation cycle (sf_alloc_count: 64), the MCS for data transmission (data_mcs: 20), and the scheduling period for MCH (mch_scheduling_period: 64), which should match or exceed the common period.

Inside mbms_session_info_list, two separate MBMS sessions are configured. The first session is identified by PLMN "00101" and service ID 0x000001 (tmgi: { plmn: "00101", service_id: 0x000001 }) with logical channel identity 1 (logical_channel_identity: 1). The second session similarly uses the same PLMN with a different service ID 0x000002 and logical channel identity 2.

 

Perform the Test

Run lte service on callbox and check 'cell' command an see if everything is configured as intended.

Check if you see the components MBMSGW shows up at the bottom of the screen.

Go into MBMSGW screen and see if you get the initialization print out for MBMSGW.

The first thing you may try is to run info conmmand. It shows the list of all the configured services, status (start or stop) of each services and basic informations (e.g, Service Area, GTP ip:port, TEID) for each service.

By default, the first service gets started automatically and the remaining service is in stop state.

Now let's start the second service as well by running the command service_start 2.

 

Log Analysis

Following is the log snapshot that are involved in UE assistance information message and handling process.

Sample Log

M2 setup request message sent over the M2AP interface. This message contains the mbmsServiceAreaList field, which indicates that two MBMS services (0001H and 0002H) are configured for delivery in this synchronization area.

M2 setup response confirms successful configuration of the MBMS control channel (MCCH) for the specified MBSFN area (mbsfnArea: 1). The parameters being delivered—such as repetitionPeriod: r64, offset: 0, modificationPeriod: r512, subframeAllocationInfo: '100000'B, and modulationAndCodingScheme: n7—are derived from the area_info_list configuration in the MBMS setup.

MBMS Session Start Request indicates the initiation of an MBMS service. It identifies the MBMS service using the Temporary Mobile Group Identity (plmnIdentity: '00101'H, serviceID: '000001'H) and specifies the MBMS service area ('000001'H). It also provides transport-level information using the TNL-Information field, which contains the IP multicast address (IPMulticastAddress: 'F7000201'H), IP source address (IPSourceAddress: '7F000181'H corresponding to 127.0.0.1), and the associated GTP tunnel endpoint (GTP-TEID: '00000001'H).

MBMS session start response message confirms successful activation of the MBMS session. The successfulOutcome structure indicates that the procedure for id-sessionStart was completed without error

MBMS Scheduling Information message sent and it configures the physical layer scheduling parameters for MBMS delivery. It defines how the Physical Multicast Channel (PMCH) will be allocated. It includes the pmch-Configuration block specifying that 63 subframes are allocated for MBMS (allocatedSubframesEnd: 63), the MCS for transmission (dataMCS: 20), and the scheduling period (mchSchedulingPeriod: r64, or 640 ms). Additionally, the message lists the active MBMS session (mbms-Session-List), identified by its plmnIdentity: '00101'H and serviceID: '000001'H, with lcid: 1

This is another set of configuration to be noted in MBMS scheduling Information. The set of IE(information elements) under id-MBSFN-Subframe-Configuration-Item confirms the configuration of the MBSFN subframe usage for the MBMS service. It specifies the subframe allocation timing using radioFrameAllocationPeriod: n1 and radioFrameAllocationOffset: 0, and provides the subframe usage pattern via the bitmap subframeAllocation oneFrame: '100000'B, which means only subframe 1 is allocated for MBMS transmission within each radio frame.

MBMS Scheduling Information Response confirms the successful reception and acceptance of the MBMS scheduling information previously sent

In SIB2, there is the IE mbsfn-SubframeConfigList that configures subframe configuration of MBMS (mbsfn). mbsfn-SubframeConfigList indicates the specific allocation of MBSFN subframes. It specifies that the radio frame allocation period is n1 (radioFrameAllocationPeriod n1), the offset is 0 (radioFrameAllocationOffset 0), and the subframe allocation bitmap is '100000'B, which means only subframe 1 in each radio frame is reserved for MBSFN transmission.

The mbsfn-AreaInfoList within sib13 specifies key MCCH parameters derived from the area_info_list configuration. It includes the area ID (mbsfn-AreaId: 1), the number of non-MBSFN symbols (non-MBSFNregionLength: 1), and the detailed mcch-Config such as: mcch-RepetitionPeriod, mcch-Offset, mcch-ModificationPeriod, sf-AllocInfo, signallingMCS

MBSFN area configuration message sent over the MCCH,. It informs UEs how MBMS transmissions are scheduled. It includes the subframe allocation pattern (commonSF-Alloc-r9), specifying that subframe 1 is used (subframeAllocation oneFrame: '100000'B) every radio frame (with radioFrameAllocationPeriod: n1 and radioFrameAllocationOffset: 0), and that the allocation repeats every 640 ms (commonSF-AllocPeriod-r9: r64). The PMCH section (pmch-InfoList-r9) defines that 63 subframes are used for data transmission (sf-AllocEnd-r9: 63) with MCS index 20 (dataMCS-r9: 20) and a scheduling period of 640 ms (mch-SchedulingPeriod-r9: r64). Additionally, it announces the active MBMS session (mbms-SessionInfoList-r9) with PLMN ID 001-01 (plmn-Id-r9), service ID 0x000001 (serviceId-r9) and logical channel identity 1 (logicalChannelIdentity-r9)

Once all the configurations are properfly configured as described above, you would see the traffics for all the channels from MCCH through PMCH

You would remember two broadcase services are configured for this test. You can identify traffics for a specific services by TEID field in GTPU packet.  

At the beginning of this test, you would see GTPU packets with only TEID = 1 since only service 1 is started at the beginning.

After you start server 2, you would start seeing the GTPU packets with TEID = 2 as well.

You would notice that All PMCH is transmitted at subframe 1 as confitured.

You can check out the PMCH transmission visually in RB Map plot, showing all the PMCH at subframe 1.

If you have any extra sdr card (e.g, a callbox with multiple SDR cards or UEsim), you can use it as spectrum analyzer and check out PBCH transmission in real time (NOTE : If you are not familiar with how to use SDR card as spectrum analyzer, refer to this tutorial )

Following is the spectrum analyzer captured as animation.

 

© 2024 All rights reserved | Legal notice |