Testing
As of now (Sep 2016), 3GPP Conformance Test Case (36.521-1,36.521-3,36.523) for LTE-M1 has not been defined yet. Even thought several chipset makers has announced/claimed that their product has been supporting LTE-M1 for almost over an year, I have been seeing real/practical verification activity only recently. So I guess (I think), most of the chipset maker/product is at some point of protocol stack integration. So I decided to write down some general approach to early integration test. This is just beginning.. and I will keep updating this.
Downlink Physical Channel/Scheduling Test
< PBCH Decoding >
Basically this is to test MIB decoding capability. Since almost all of the parameters to implementing PBCH is predefined by 3GPP standard, there is almost nothing to be configured in eNB simulator and UE modem. But to verify if UE properly decode PBCH is important because LTE-M1 MIB is transmitted in different subframe from legacy LTE and Resource Element Mapping is pretty much different from legacy LTE due to repetitive transmission of PBCH in LTE M1.
< BCH-DL SCH : PDSCH >
In this channel, you need to verify on two different cases. One is the case of SIB1-NB and the other case is for other SIBs (non SIB1). In terms of Baseband I/Q generation and Resource Element mapping, there is no fundamental difference between these two case, but there are some differences in terms of scheduling and resource allocation. So, if you want to do test on this channel purely on physical layer perspective, you may test this as a single category, but if you want to test including MAC scheduling aspect as well, I would divide this into two categories.
Case 1 : PDSCH for SIB1-NB
|
Test Parameter |
Description |
Value |
|
Number of PDSCH Repetitions |
|
Case 2 : PDSCH for non-SIB1-NB
|
Test Parameter |
Description |
Value |
|
startSymbolBR |
||
|
si-RepetitionPattern |
||
|
fdd-DownlinkOrTddSubframeBitmapBR |
||
|
si-Narrowband |
||
|
si-TBS |
See SIB1 : si-TBS |
< CCCH/DCCH/DTCH : PDSCH >
The parameter setting for PDSCH for User Data is relatively straightforward (Physical Layer's point of view, most of C plane data(e.g, CCCH/DCCH) can be regarded as user data)
|
Test Parameter |
Description |
Value |
|
pdsch-Start |
The first OFDM Symbol from which the PDSCH is assigned : {1, 2, 3, 4} |
|
| Number of RB | ||
| Narrowband Index | Narrowband Index at which the PDSCH is transmitted | |
|
PDSCH repetition levels |
See PDSCH Subframe Assignment | |
| MCS | ||
|
p_a |
See 36.331 | |
|
dmrs-ConfigPDSCH |
See 36.331 | |
|
tbsIndexAlt-r12 |
See 36.331 |
< MPDCCH >
In most test equipment (especially protocol test equipment), MPDCCH related parameters are not directly configured by user. They are automatically calculated/configured by other parameter (mostly by PDSCH scheduling parameter). But if your DUT's blind decoding algorithm is not complete and you want to set any specific set of parameters, you would need to specify following tables and configure PDSCH scheduling parameters so that the test equipment would generate the specific MPDCCH parameters as you want.
|
Test Parameter |
Description |
Value |
|
Duplex Type |
FDD or TDD (This influence No of EREGs for ECCE ) |
|
|
CE Mode |
CE Mode A or B (This influence No of EREGs for ECCE ) |
|
|
MPDCCH Format |
See MPDCCH Format |
|
|
DCI Format and the field values |
Construct Parameter table for each DCI Type |
|
|
mpdcch-NumRepetition-r13 |
{r1, r2, r4, r8, r16, r32, r64, r128, r256} |
|
|
mpdcch-Narrowband-r13 |
Narrowband Index at which the PDCCH is transmitted |