LTE-M is a family of several configurations supported by LTE for machine-to-machine and IoT communications. In this post I will talk specifically about BL/CE (bandwidth reduced low complexity / coverage enhancement), which is also known as LTE Cat M1. The main difference between a BL/CE UE and a regular LTE UE is that a BL/CE UE only supports a bandwidth of 1.4 MHz (in practice, 6 resource blocks, or 1.08 MHz) and can be half-duplex. These limitations reduce the cost, size and power of the UE, but require additional techniques to handle them.
If we think about the downlink, there are several signals that occupy the whole cell bandwidth, which is usually larger than 1.4 MHz. These are the PDCCH (physical downlink shared channel), the PCFICH (physical control format indicator channel) and the PHICH (physical hybrid-ARQ indicator channel). A BL/CE UE cannot receive any of these, so alternative signals must be used to provide similar functionality. Additionally, a BL/CE UE needs guard intervals in the time domain to support retuning of the 1.4 MHz slice in which the UE operates, and transmit/receive switching for half-duplex UEs. Another distinguishing feature of BL/CE is that messages are often repeated multiple times in order to support working with worse signal conditions than what is possible with a regular UE.
In LTE, the PSS and SSS (primary synchronization signal and secondary synchronization signal), as well as the PBCH (physical broadcast channel) occupy the central 6 resource blocks, so a BL/CE UE can synchronize to the cell and decode the MIB transmitted in the PBCH. The next step that a regular UE would perform is to monitor the PDCCH, first to find a SIB1 transmission (which is transmitted in the PDSCH), and then the rest of the SIBs (whose transmission schedule is listed in the SIB1). A BL/CE UE cannot do this, because it cannot receive the PDCCH and because the SIB PDSCH transmissions might be wider than 6 resource blocks. Therefore, in a cell that supports BL/CE UEs there are also SIB-BRs (BR stands for bandwidth reduced), which BL/CE UEs use instead of the regular SIBs. The SIB-BRs occupy 6 resource blocks and do not require receiving the PDCCH to be decoded. In this post I will use my recording of an LTE eNB to show how to decode the SIB-BRs, and other important aspects of BL/CE UEs.
Narrowbands
In order to support BL/CE UEs, the bandwidth of the cell is divided into segments of 6 contiguous resource blocks which are called narrowbands. A BL/CE UE will always operate in one of these narrowbands (except when receiving the PSS, SSS and PBCH). The set of 6 resource blocks contained in each narrowband is defined by some formulas in Section 6.2.7 of TS 36.211. Basically these formulas say that the cell bandwidth is divided in segments of 6 resource blocks, potentially leaving out some resource blocks at the edges of the cell and between some narrowbands when the total number of resource blocks is not a multiple of 6. There is a nice table in ShareTechnote that shows the narrowbands for each of the possible LTE cell bandwidths.
In our case, the cell has 10 MHz bandwidth, which corresponds to 50 resource blocks. The first and last resource block do not belong to a narrowband, and the remaining 48 resource blocks are divided into 8 consecutive narrowbands numbered from 0 to 7.
BL/CE PBCH
Before starting to talk about the SIB-BR, I should say that even though a BL/CE UE is capable of decoding the regular PBCH, LTE defines a BL/CE PBCH which consists of 4 additional repetions of the regular PBCH located immediately before and after it. The BL/CE PBCH page from ShareTechnote contains more details about this and includes the following figure showing which resource elements are used by the BL/CE PBCH.
Recall that the PSS and SSS are transmitted in the sixth and seventh symbol of the first and fifth subframe of each radio frame. These are shown in yellow in the figure (the figure only shows a single resource block in the frequency domain). The resources that are used by the CRS (cell specific reference signal) of each antenna port are shown in blue and red (the offset in the frequency domain of the location of the CRS depends on the physical cell ID modulo 3, so this particular diagram is for a cell with ID equal to zero mod 3).
Since by the time that a UE attempts to decode the PBCH it doesn’t know the number of antenna ports used by the eNB yet, the PBCH always avoids the locations of the CRS of all the 4 possible antenna ports. The usual PBCH is shown as “legacy PBCH”. It occupies the 4 symbols following the PSS and SSS in the first subframe of each radio frame. The repetitions for BL/CE UEs occupy the rest of the subframe (SF#0) and also the previous subframe (SF#9). The first three symbols of these subframes are not used because potentially they can be used by the PDCCH, depending on the CFI (control format indicator, transmitted in the PCFICH).
In the case of the recording I’m using, the BL/CE PBCH is not used. This can be seen clearly in the following figure, which shows the waterfall of a piece of the recording. The two PBCH transmissions that appear are indicated with red marks. The PSS and SSS can be seen immediately before them (they are slightly narrower). There is nothing preceding these transmissions as in the diagram above.
I guess that the BL/CE PBCH is optional, in the sense that a cell can support BL/CE UEs and not use it, given that a BL/CE UE can decode the regular PBCH. The only thing that the BL/CE PBCH does is to improve decoding in bad conditions by providing extra repetitions.
SIB1-BR
After decoding the MIB in the PBCH, the next thing that a BL/CE UE needs to decode is the SIB1-BR. There is a field called schedulingInfoSIB1-BR-r13 in the MIB that contains a number that indicates to the UE all it needs to know to find and decode the SIB1-BR transmission in the PDSCH. The r13 in the name of this field stands for Release 13, since the concept of BL/CE UEs appeared in Release 13 of the LTE standard.
In this case, the contents of the MIB are
{'dl-Bandwidth': 'n50',
'phich-Config': {'phich-Duration': 'normal', 'phich-Resource': 'one'},
'systemFrameNumber': (b'O', 8),
'schedulingInfoSIB1-BR-r13': 4,
'systemInfoUnchanged-BR-r15': False,
'spare': (b'\x00', 4)}
The schedulingInfoSIB1-BR-r13 field has a non-zero value whenever the cell supports BL/CE UEs. By means of some tables in TS 36.211 and TS 36.213, a non-zero value in the schedulingInfoSIB1-BR-r13 field indicates when the SIB1-BR is transmitted, as well as its transport block size (which for a regular PDSCH it would be given in the corresponding DCI in the PDSCH). These tables are neatly summarized in the ShareTechnote page about the BL/CE SIB.
In this case, the schedulingInfoSIB1-BR-r13 is 4, and the cell ID is 380. Therefore, the SIB1-BR is transmitted in subframe 4 of every radio frame with an even SFN (system frame number), that is, every 20 ms.
The narrowband in which the SIB1-BR is transmitted depends on the cell ID and on when the transmission happens. In general, each transmission can use a different narrowband, to provide frequency diversity. For a 10 MHz cell, the SIB1-BR alternates between two different narrowbands. For this particular cell, with ID 380, narrowbands 2 and 7 are used.
Something else to keep in mind is that often PDSCH transmissions for BL/CE UEs starts on the fourth symbol of the subframe, because the first 3 symbols could be used for the PDCCH. A BL/CE UE has no way of knowing how many symbols are allocated to the PDCCH, as this information is in the CFI in the PCFICH, which the BL/CE UE cannot decode. In fact, for the SIB1-BR, the transmissions always start on the fourth symbol (except for 1.4 MHz cells, in which they start in the fifth symbol). The SIB1-BR indicates in which symbol all the other transmissions for BL/UEs start. The PDSCH transmissions for BL/CE UEs do not have a corresponding transmission in the PDCCH, so I haven’t decoded any of them in the post about the PDSCH.
In an cell which is not so busy, such as the one in this recording, it is quite easy to identify transmissions for BL/CE UEs in the waterfall, because of the gap that they leave between the symbols used by the PDCCH (usually just one or two) and the fourth symbol in which they start. I already observed this in my post about the PBCH and PDCCH. The keen reader might have noticed that there is one such transmission in the waterfall shown above, at the 16 ms mark. We can also see that this transmission has the same width as the PBCH, and in fact occupies narrowband 7, the highest narrowband in the 10 MHz cell. This is the first SIB1-BR transmission that appears in the recording. Looking at the position of the PBCH (which occupies subframe 0 in each radio frame), we can see that this SIB1-BR transmission indeed happens in subframe number 4 within the radio frame.
Taking a look around the waterfall it is easy to locate the other SIB1-BR transmissions and see that they follow the pattern described above. The recording I have has three 10 MHz cells in the B20 band. The cell we’re using (Vodafone) is the one in the middle, but the cell below it (Orange) is synchronized in time (which can be seen by looking at when the PSS/SSS and PBCH are transmitted). I have marked in red the SIB1-BR transmissions in these two cells. They follow the same pattern, except that they use different narrowbands because they have different cell IDs. The cell on the top (Movistar) doesn’t seem to support BL/CE UEs. Finding BL/CE transmissions in this cell by looking at the waterfall is more difficult, because the cell is usually busy, but still I haven’t seen any.
To decode these transmissions we also need to know their transport block size. This is indicated by a table indexed by the value of the schedulingInfoSIB1-BR-r13 field. The value 4 corresponds to a transport block size of 256 bits.
Another thing we need to know is the redundancy version used for each transmission. Different transmissions use a different redundancy version to allow a UE to combine multiple transmissions to improve its chances of decoding. The redundancy version used for each transmission is specified in Section 5.3.1 in TS 36.321. For the case in which the SIB1-BR is transmitted every 20 ms, the redundancy version keeps changing in the usual order 0, 2, 3, 1, with redundancy version 0 happening in the radio frames whose SFN is zero modulo 8.
The first SIB1-BR transmission in the recording happens in SFN 314. According to the above, this transmission uses redundancy version 2, and narrowband 7. With this information, we can decode the transmission as any other PDSCH transmission. Equalization must be done using transmit diversity, as is always done for SI-RNTI transmissions in a two-port cell. The figure below shows the symbols of this transmission.
The contents of the SIB-BR transmissions must be parsed with the BCCH-DL-SCH-Message-BR ASN.1 message, unlike regular SIB transmssions, which are parsed with the BCCH-DL-SCH-Message ASN.1 message. The parsed data of this SIB1-BR transmission is shown here. We see that some of the fields are the same as in the regular SIB1, but there is other information specific to BL/CE, which can be used to locate the other SIB-BR transmissions in time and frequency.
{'message': ('c1',
('systemInformationBlockType1-BR-r13',
{'cellAccessRelatedInfo': {'plmn-IdentityList': [{'plmn-Identity': {'mcc': [2,
1,
4],
'mnc': [0, 1]},
'cellReservedForOperatorUse': 'notReserved'}],
'trackingAreaCode': (b'\x01\x16', 16),
'cellIdentity': (b'F\x07@p', 28),
'cellBarred': 'notBarred',
'intraFreqReselection': 'allowed',
'csg-Indication': False},
'cellSelectionInfo': {'q-RxLevMin': -64},
'freqBandIndicator': 20,
'schedulingInfoList': [{'si-Periodicity': 'rf64',
'sib-MappingInfo': ['sibType3']},
{'si-Periodicity': 'rf512', 'sib-MappingInfo': ['sibType5']}],
'si-WindowLength': 'ms1',
'systemInfoValueTag': 24,
'nonCriticalExtension': {'nonCriticalExtension': {'cellSelectionInfo-v920': {'q-QualMin-r9': -18},
'nonCriticalExtension': {'nonCriticalExtension': {'cellAccessRelatedInfo-v1250': {},
'nonCriticalExtension': {'cellSelectionInfoCE-r13': {'q-RxLevMinCE-r13': -70},
'bandwidthReducedAccessRelatedInfo-r13': {'si-WindowLength-BR-r13': 'ms200',
'si-RepetitionPattern-r13': 'every8thRF',
'schedulingInfoList-BR-r13': [{'si-Narrowband-r13': 6,
'si-TBS-r13': 'b712'},
{'si-Narrowband-r13': 6, 'si-TBS-r13': 'b600'}],
'startSymbolBR-r13': 3,
'si-HoppingConfigCommon-r13': 'off',
'systemInfoValueTagList-r13': [0, 1]},
'nonCriticalExtension': {'nonCriticalExtension': {'cellSelectionInfoCE1-r13': {'q-RxLevMinCE1-r13': -70}}}}}}}}}))}
The remaining SIB1-BR transmissions can be decoded in the same way. These can be added to the PCAP file to be analysed with Wireshark. When doing this, it is necessary to use the MAC_LTE_CE_MODE_TAG in the metadata of the MAC-LTE UDP, followed by a value that indicates one of the two CE modes. Otherwise Wireshark will dissect the frames as regular SI-RNTI frames, using BCCH-DL-SCH-Message, and the dissection will be wrong.
SIB2-BR and SIB3-BR
As in the regular SIB, the SIB2-BR and SIB3-BR are transmitted together in the same message. The configuration parameters necessary to find these transmissions are given in the SIB1-BR. The first relevant parameter is the si-Peridiocity in the schedulingInfoList. This indicates the frequency with which the tramsmissions happen. In this case, for sibType3 (and implictly for SIB2-BR as well), the periodicity is rf64, which stands for 64 radio frames (every 640 ms). The rules that define the time offset at which these transmissions happen are listed in Section 5.2.3a in TS 36.331. Basically these rules assign a different offset to each of the entries in the schedulingInfoList according to their order in this list. This is done to avoid having transmissions that coincide in time. In this case, since the entry is the first one, the offset is zero. This means that the SIB2-BR/SIB3-BR transmissions start at every radio frame with SFN equal to zero modulo 64.
As I have mentioned, transmissions for BL/CE UEs are often repeated many times to improve the chances of decoding. In the case of the SIB-BR (besides the SIB1-BR), this repetition is organized in two “levels”. On the first level, the SIB-BR is transmitted in multiple radio frames starting at the radio frames defined by the periodicity and offset. The parameters that define these repetitions are si-WindowLength-BR-r13 and si-RepetitionPattern-r13. In this case, the window length is 200 ms, and the repetition pattern is every 8 radio frames. This means that the SIB-BR is transmitted every 8 radio frames within a 200 ms window. Thus, each time that the SIB2-BR/SIB3-BR is transmitted (starting in each radio frame with SFN equal to zero modulo 64), it is transmitted in 3 different radio frames that are spaced by 8 radio frames (so it is transmitted in frames with SFN equal to 0, 8, and 16 modulo 64).
The second level of repetition defines in which subframes within each of these radio frames the SIB-BR is transmitted. There is an optional parameter fdd-DownlinkOrTddSubframeBitmapBR-r13 that can be used to select the pattern of subframes by using a bitmap. In this case, the parameter is not present, which means that the SIB-BR is transmitted in all the 10 subframes of these radio frames.
The narrowband in which the SIB-BR is transmitted is given by the si-Narroband-r13 parameter. Here it is 6 for all the SIB-BRs. Narrowbands in this parameter are one-indexed rather than zero-indexed, so the narrowband is actually what we are labelling as narrowband 5. Besides this, there is a si-HoppingConfigCommon-r13 parameter that can activate frequency hopping of the SIB-BR transmissions. In this case it is disabled, so we need not worry about it.
Finally, another parameter that we need to take into account is the startSymbolBR-r13. As mentioned earlier, the SIB1-BR transmissions always start in symbol 3, because symbols 0, 1, 2 might be allocated to the PDCCH. The rest of the BL/CE transmissions can start on another fixed symbol, as defined by this parameter in the SIB1-BR. In this case, the startSymbolBR-r13 is 3, so the rest of the transmissions also start in symbol 3.
With this information we can easily locate the SIB2-BR/SIB3-BR transmissions on the waterfall of the recording. The figure below shows the first radio frame in which it is transmitted. The transmission is done in narrowband 5 in each of the 10 subframes of the radio frame, as expected. Note that the cell that is lower in frequency (Orange), is also transmitting the SIB2-BR/SIB3-BR at the same time, but using a different narrowband. Another thing to note is that with these settings, the SIB2-BR/SIB3-BR transmissions always coincide with a SIB1-BR transmission, because the SIB1-BR is transmitted in subframe 4 of every radio frame with even SFN. Therefore, the narrowband in which the SIB2-BR/SIB3-BR is transmitted must be chosen to avoid collisions with the narrowband used by the SIB1-BR (which is determined by the cell ID).
The next figure shows another waterfall with different time and frequency resolution. It shows the three radio frames in which the SIB2-BR/SIB3-BR is transmitted. In each of these radio frames, the SIB2-BR/SIB3-BR is transmitted 10 times, so it is transmitted a total of 30 times. The next time that the SIB2-BR/SIB3-BR appears is 640 ms later, at 0.712 s in the recording.
To decode the SIB2-BR/SIB3-BR transmissions there are two things we need to be aware of: the scrambling sequence and the redundancy version. Transmissions for BL/CE UEs have special rules regarding how the scrambling sequence is constructed. These are given in Section 6.3.1 of TS 36.211. The formula that is given there is somewhat complicated, but for this case it boils down to the fact that each group of 4 repetitions in consecutive subframes uses the same scrambling sequence: the one that would naturally be assigned to the first subframe in the group (regular PDSCH transmissions use a scrambling sequence that depends on the subframe number within the radio frame). Since the SIB2-BR/SIB3-BR is repeated 10 times in the radio frame, the first 4 repetitions use the same scrambling sequence (the one corresponding to subframe 0), the next 4 repetitions use the scrambling sequence corresponding to subframe 4, and the last 2 repetitions use the scrambling sequence corresponding to subframe 8. We have been able to ignore this rule for the SIB1-BR because in this cell it is only transmitted in subframe 4, which gets the usual scrambling sequence.
The rule for the redundancy version assignment is given in Section 5.3.1 of TS 36.321. It basically says that the redundancy version depends on the value of k, the subframe number within the window modulo 4. The redundancy version follows the usual order, so for the values of k = 0, 1, 2, 3, the corresponding redundancy version indices are 0, 2, 3, 1. This rule applies to these SIB2-BR/SIB3-BR transmission in the following way. In each radio frame, the 10 repetitions use redundancy versions 0, 2, 3, 1, 0, 2, 3, 1, 0, 2. When the SIB2-BR/SIB3-BR is transmitted again 8 radio frames afterwards, the sequence of redundancy versions is the same, because 8 radio frames contain 80 subframes, and 80 is divisible by 4.
The last piece of information that we need is the transport block size. This is given in the si-TBS-r13 parameter in the schedulingInfoList-BR-r13 of the SIB1-BR. For the SIB2-BR/SIB3-BR, the transport block size is 712. With all this we can decode the SIB2-BR/SIB3-BR transmissions. The figure below shows the symbols of the first transmission. The coding rate of these transmissions is around 0.5, which is rather high for a broadcast transmission (regular SIB transmissions use a coding rate around 0.1). This is both because the transmission needs to fit in a narrowband (so its coding rate is determined only by the transport block size) and because there are many repetitions of the transmission.
The Jupyter notebook contains plots for the other 9 repetitions in this radio frame. They all look quite similar. The contents of the SIB2-BR/SIB3-BR are as follows. They contain some information that is also present in the regular SIB2 and SIB3, and some information that is specific for BL/CE.
{'message': ('c1',
('systemInformation-BR-r13',
{'criticalExtensions': ('systemInformation-r8',
{'sib-TypeAndInfo': [('sib2',
{'ac-BarringInfo': {'ac-BarringForEmergency': False},
'radioResourceConfigCommon': {'rach-ConfigCommon': {'preambleInfo': {'numberOfRA-Preambles': 'n36'},
'powerRampingParameters': {'powerRampingStep': 'dB2',
'preambleInitialReceivedTargetPower': 'dBm-104'},
'ra-SupervisionInfo': {'preambleTransMax': 'n10',
'ra-ResponseWindowSize': 'sf10',
'mac-ContentionResolutionTimer': 'sf64'},
'maxHARQ-Msg3Tx': 5,
'preambleTransMax-CE-r13': 'n6',
'rach-CE-LevelInfoList-r13': [{'preambleMappingInfo-r13': {'firstPreamble-r13': 0,
'lastPreamble-r13': 12},
'ra-ResponseWindowSize-r13': 'sf50',
'mac-ContentionResolutionTimer-r13': 'sf480',
'rar-HoppingConfig-r13': 'off'},
{'preambleMappingInfo-r13': {'firstPreamble-r13': 18,
'lastPreamble-r13': 30},
'ra-ResponseWindowSize-r13': 'sf80',
'mac-ContentionResolutionTimer-r13': 'sf480',
'rar-HoppingConfig-r13': 'off'}]},
'bcch-Config': {'modificationPeriodCoeff': 'n4'},
'pcch-Config': {'defaultPagingCycle': 'rf128', 'nB': 'oneEighthT'},
'prach-Config': {'rootSequenceIndex': 176,
'prach-ConfigInfo': {'prach-ConfigIndex': 19,
'highSpeedFlag': False,
'zeroCorrelationZoneConfig': 14,
'prach-FreqOffset': 3}},
'pdsch-ConfigCommon': {'referenceSignalPower': 15, 'p-b': 1},
'pusch-ConfigCommon': {'pusch-ConfigBasic': {'n-SB': 4,
'hoppingMode': 'interSubFrame',
'pusch-HoppingOffset': 22,
'enable64QAM': True},
'ul-ReferenceSignalsPUSCH': {'groupHoppingEnabled': False,
'groupAssignmentPUSCH': 0,
'sequenceHoppingEnabled': False,
'cyclicShift': 0}},
'pucch-ConfigCommon': {'deltaPUCCH-Shift': 'ds1',
'nRB-CQI': 0,
'nCS-AN': 0,
'n1PUCCH-AN': 36},
'soundingRS-UL-ConfigCommon': ('release', None),
'uplinkPowerControlCommon': {'p0-NominalPUSCH': -67,
'alpha': 'al07',
'p0-NominalPUCCH': -115,
'deltaFList-PUCCH': {'deltaF-PUCCH-Format1': 'deltaF0',
'deltaF-PUCCH-Format1b': 'deltaF3',
'deltaF-PUCCH-Format2': 'deltaF1',
'deltaF-PUCCH-Format2a': 'deltaF2',
'deltaF-PUCCH-Format2b': 'deltaF2'},
'deltaPreambleMsg3': 4},
'ul-CyclicPrefixLength': 'len1',
'pusch-ConfigCommon-v1270': {'enable64QAM-v1270': 'true'},
'pcch-Config-v1310': {'paging-narrowBands-r13': 1,
'mpdcch-NumRepetition-Paging-r13': 'r4'},
'freqHoppingParameters-r13': {'interval-ULHoppingConfigCommonModeA-r13': ('interval-FDD-r13',
'int8'),
'interval-ULHoppingConfigCommonModeB-r13': ('interval-FDD-r13',
'int8')},
'pdsch-ConfigCommon-v1310': {'pdsch-maxNumRepetitionCEmodeB-r13': 'r192'},
'pusch-ConfigCommon-v1310': {'pusch-maxNumRepetitionCEmodeA-r13': 'r16',
'pusch-maxNumRepetitionCEmodeB-r13': 'r192'},
'prach-ConfigCommon-v1310': {'rsrp-ThresholdsPrachInfoList-r13': [51],
'mpdcch-startSF-CSS-RA-r13': ('fdd-r13', 'v1'),
'prach-HoppingOffset-r13': 0,
'prach-ParametersListCE-r13': [{'prach-ConfigIndex-r13': 21,
'prach-FreqOffset-r13': 8,
'maxNumPreambleAttemptCE-r13': 'n3',
'numRepetitionPerPreambleAttempt-r13': 'n1',
'mpdcch-NarrowbandsToMonitor-r13': [7],
'mpdcch-NumRepetition-RA-r13': 'r8',
'prach-HoppingConfig-r13': 'off'},
{'prach-ConfigIndex-r13': 21,
'prach-FreqOffset-r13': 8,
'maxNumPreambleAttemptCE-r13': 'n3',
'numRepetitionPerPreambleAttempt-r13': 'n2',
'mpdcch-NarrowbandsToMonitor-r13': [7],
'mpdcch-NumRepetition-RA-r13': 'r8',
'prach-HoppingConfig-r13': 'off'}]},
'pucch-ConfigCommon-v1310': {'n1PUCCH-AN-InfoList-r13': [46, 38],
'pucch-NumRepetitionCE-Msg4-Level0-r13': 'n8',
'pucch-NumRepetitionCE-Msg4-Level1-r13': 'n8',
'pucch-NumRepetitionCE-Msg4-Level2-r13': 'n32',
'pucch-NumRepetitionCE-Msg4-Level3-r13': 'n32'}},
'ue-TimersAndConstants': {'t300': 'ms2000',
't301': 'ms2000',
't310': 'ms1000',
'n310': 'n10',
't311': 'ms10000',
'n311': 'n1',
't300-v1310': 'ms5000',
't301-v1310': 'ms5000'},
'freqInfo': {'ul-Bandwidth': 'n50', 'additionalSpectrumEmission': 1},
'timeAlignmentTimerCommon': 'infinity',
'ac-BarringSkipForMMTELVoice-r12': 'true',
'ac-BarringSkipForMMTELVideo-r12': 'true',
'ac-BarringSkipForSMS-r12': 'true',
'voiceServiceCauseIndication-r12': 'true'}),
('sib3',
{'cellReselectionInfoCommon': {'q-Hyst': 'dB4',
'speedStateReselectionPars': {'mobilityStateParameters': {'t-Evaluation': 's60',
't-HystNormal': 's30',
'n-CellChangeMedium': 4,
'n-CellChangeHigh': 8},
'q-HystSF': {'sf-Medium': 'dB0', 'sf-High': 'dB0'}}},
'cellReselectionServingFreqInfo': {'s-NonIntraSearch': 6,
'threshServingLow': 5,
'cellReselectionPriority': 4},
'intraFreqCellReselectionInfo': {'q-RxLevMin': -64,
's-IntraSearch': 31,
'presenceAntennaPort1': False,
'neighCellConfig': (b'@', 2),
't-ReselectionEUTRA': 1,
't-ReselectionEUTRA-SF': {'sf-Medium': 'lDot0',
'sf-High': 'oDot75'}},
'cellSelectionInfoCE-r13': {'q-RxLevMinCE-r13': -70},
't-ReselectionEUTRA-CE-r13': 7,
'cellSelectionInfoCE1-r13': {'q-RxLevMinCE1-r13': -70}})]})}))}
I think there are no more BL/CE transmissions in this cell in the one second recording that I’m looking at. According to the SIB1-BR, the SIB5-BR is transmitted every 5.12 seconds, so a longer recording would be needed to capture it. This recording is an excerpt of a longer recording, so perhaps I’ll look there at some point. Since BL/CE UEs cannot receive the PDCCH, there is a physical channel called MPDCCH that replaces its function. It is transmitted in part of the area of the subframe that is normally allocated to the PDSCH. The MPDCCH is used to announce PDSCH transmissions to BL/CE UEs other than the SIB-BRs. I haven’t seen any MPDCCH transmissions, so this recording doesn’t give a full picture of how BL/CE UEs work.
Code and data
I have updated the Jupyter notebook with the code used to decode these SIB-BR transmissions. The PCAP file containing the decoded PDUs has also been updated.