Validation and Evaluation of eMBMS in OAI platform

For the validation of the implemented eMBMS service in OpenAirInterface platform, the first metric we want to measure is the Block Error Rate (BLER) which allows us to infer about the physical layer properties. According to [63], the minimum require-ment for eMBMS transmission’s BLER in both FDD and TDD configuration is 1% at SNR=20.5(dB) with the R.39-1 reference channel model and the Transport Block Size (TBS) corresponds to Modulation Coding Scheme (MCS) equal 20. With this emulation, the scenario with only one service group (one MCH) and one eMBMS service (MTCH) is applied. More detail about simulation parameters can be found in Table 6.1.

Table 6.1 – Simulation Parameters for eMBMS

Parameters Setting

Transmission Bandwidth 5MHz

Number of pairs of RBs available for eMBMS 25

Transmission Time Interval 1ms Number of symbols per MBSFN 6 symbols (FDD)

We have done the simulation with the same condition as used in the standard requi-rement (R.39-1 channel) for three different Modulation and Coding Schemes (MCS = 17, 20, 22). As we can observe in Fig. 6.3, the eMBMS transmission in the emulation obtains a gain about of 3dB at BLER=1% against the standard requirement (the x point in the graph).

One major benefit of using LTE for eMBMS is that the bit rates for real-time services such as video streaming, video conference or interactive games are much higher than for MBMS in 3G network (UTRAN). Therefore the user throughput is an importance metric when assessing eMBMS performance. The Fig. 6.4 shows the throughput of eMBMS trans-mission in FDD with different MCS values and different number of eMBMS subframes in one radio frame. To remind, maximum six out of ten subframes can be allocated to eMBMS in one radio frame.

At the moment, in mode TDD, our OAI platform only supports the TDD configuration mode 3 which allows transmitting the eMBMS data maximum in three subframes (#7, #8 and #9). Thereby, when we run the emulation in TDD mode, only three subframes are

Figure 6.3 – BLER for eMBMS Transmission in OAI.

Figure 6.4 – User Throughput of eMBMS Transmission with different MCS values.

allocated for eMBMS while with FDD, all six eligible subframes can be used. The emulation results for the eMBMS throughput in TDD mode with difference MCS values are shown in Fig. 6.5.

In the figure, the red bars represent the user throughput of eMBMS system calcula-ted by OTG at the receiver side while the blue bars represent the maximum transmission throughput for eMBMS calculated from 3GPP specifications [61]. There is a slightly dif-ference between these two values in each MCS configuration which can be explained as

(a) TDD

(b) FDD

Figure 6.5 – eMBMS User Throughput in OAI.

follows : firstly, the theoretical throughput is the transmission capability in physical layer while the user throughput is calculated after data is sent to OTG from PDCP. Hence, a small amount of resource is used for the headers at layer 2. Secondly, packet loss during the propagation over air interface (modeled channel) also affects the user throughput. The BLER result satisfies the minimum requirement of 3GPP standard and the obtained user throughputs in different MCS values are very closed to the theoretical value have proved that our eMBMS implementation in OAI is correct and reflexes the standard.

To measure the time for retrieving eMBMS control informations in OAI platform, we use the emulation with two physical machines : the first one hosts one eNB instance, ten UE instances are generated in the second machine. In this experiment, we collect the time to retrieve the SIB13, MCCH message and the MSI of all UE instances and compute the average time to receive each type of eMBMS signaling information. The retrieving time is calculated from the moment when an UE activates (turns on) until the moment when it decodes successfully the respective control information. With one MCCH repetition period value, we do the emulation for 1000 times and in each time, the UEs are programmed to switch on at a random moment following the uniform distribution. In the emulation, the

SIB13 is repeated every 8 radio frames and the MSP is set to 16 radio frames while the MCCH period varies from 32 to 256 radio frames. The results are given in the Table 6.2 and Fig. 6.6.

Table 6.2 – Retrieving Time for eMBMS Control Information.

MCCH period SIB13 MCCH MSI

Average Deviation Average Deviation Average Deviation

32 (RFs) 4.03 2.24 16.34 9.17 32.31 18.25

64 (RFs) 4.03 2.23 32.20 18.42 48.21 27.31

128 (RFs) 4.01 2.24 64.24 36.79 80.47 46.24

256 (RFs) 4.02 2.27 128.27 73.78 144.42 82.85

Figure 6.6 – Retrieving Time for eMBMS Control Information.

Look at the emulation results, we can realize that the time for retrieving SIB13 and MCCH is approximately a half of their repetition periods while the MSI is obtained about one MSP after receiving the MCCH message. It is because the UE switches on randomly during the period of SIB13/MCCH and at the end of the period, it can decode the message.

Whereas, we schedule the MCCH and MSI at the same subframe, therefore, the UE has to wait to the next MSP to get the MSI.

From these results, we can infer that if the SIB13 and MCCH message are transferred to the RRC-Connected UE during the Handover procedure, in average, the UE can save a time equal to half of the MCCH period (with the assumption that the added information does not affect the decoding time). In other words, the service interruption time can be reduce an amount equivalent to half of MCCH period. For example, in case the system uses the repetition period of 256 radio frames for MCCH, with our solution, the disruption time might be reduced an amount of 2560/2=1280 ms or 1,28 s. This amount is quite large in a streaming service and from the result in our field test with a real 4G/LTE network, we will see how it could impact the quality of a broadcast stream in terms of QoE.