NPBCH (Narrowband Physical Broadcast Channel)

NPBCH is the first NB-IoT channel a UE decodes after NPSS and NSSS, and it delivers the MIB-NB. It uses one subframe in every radio frame and spreads one MIB-NB over 640 ms. That long spread lets a UE in poor coverage collect enough energy to decode it.

NPBCH is a special channel to carry MIB and has following characteristics :

It carries only the MIB.
It is using QPSK.

Overall channel coding process is almost same as legacy LTE (the differeces are input/output bit length of each channel coding process) and of course resource element mapping and transmission cycle/subframe will be drastically different from legacy LTE. Followings are the list of topics covered in this page.

BCH Physical Layer Processing

BCH Physical Layer Processing

Following is overall transport (channel coding) and phyiscal layer processing for NPBCH. In term of overall procedure, it is same as LTE. In details, the only difference is resource element mapping and transmission cycle.

NOTE : At first I did blind copy of this process from legacy LTE page and as a result, there were some incorrect numbers in the diagram and illustration due to the difference between legacy LTE and LTE-NB. Recently (Jul 2017), Mateusz Michalski from Nokia kindly shared his experties and knowledge to correct all those wrong numbers. If anybody finds anything that need to be corrected again, please let Mateusz or/and me.

Seven-step BCH and NPBCH processing chain from CRC attachment to resource element mapping

The seven steps are the same as for LTE PBCH. NB-IoT changes the numbers at each step, and it changes the resource element mapping and the transmission cycle.

CRC Attachement : 36.212-5.3.1

The first step adds a 16-bit CRC to the 34-bit BCH transport block, so channel coding receives K = 50 bits. 36.212 clause 6.4.1 keeps the LTE BCH processing of clause 5.3.1 and changes only a few values: a TTI of 640 ms, a transport block of 34 bits, and a rate matching output of 1600 bits. The CRC mask also depends on whether the eNB uses one or two antenna ports.

CRC attachment turning 34 BCH bits into 50 bits

Channel Coding : 36.212-5.3.1

The size of array c[] is 50 (K = 50) and output of channel coding is 150 in total(each of three d[] array is 50 bits). The coding method is based on 36.212-5.1.3.1 Tail biting convolutional coding as brielfy illustrated below.

Tail biting convolutional encoder producing three output streams

Rate Matching : 36.212-5.3.1

Rate matching turns the 150 coded bits into the 1600 bits that NPBCH carries, so the coded block is repeated more than ten times. 36.211 clause 10.2.4.1 sets that output size, 1600 bits for normal cyclic prefix.

The UE shall assume antenna ports R2000 and R2001 are used for the transmission of the narrowband physical broadcast channel

Rate matching with sub-block interleavers, bit collection and bit selection

Three sub-block interleavers feed a circular buffer, and bit selection reads 1600 bits from it. The picture has two slips. The header reads 35.212 for 36.212, and the lower caption names the turbo-code figure. The interleaver table and the block diagram belong to rate matching for convolutionally coded channels, in 36.212 clause 5.1.4.2.

Scrambling : 36.211-6.6.1

Scrambling randomises the 1600 bits with a Gold sequence seeded by the NB-IoT cell ID. 36.211 clause 10.2.4.1 reuses the LTE PBCH scrambling of clause 6.6.1. It restarts the sequence only in radio frames where n_f mod 64 = 0, which is the start of each 640 ms MIB-NB period.

NPBCH scrambling with the Gold sequence initialised by the NB-IoT cell ID

Modulation : 36.211-6.6.2

QPSK turns the 1600 scrambled bits into 800 symbols. 36.211 clause 10.2.4.2 lists QPSK as the only modulation scheme for NPBCH, and the next two subsections spread these 800 symbols over eight subframes.

QPSK modulation of 1600 bits into 800 NPBCH symbols

How many subframes to transmit a MIB ?

Before we move into the last of PBCH processing based on 3GPP, let's pause a moment here and think of how many subframes (how many resource elements) we would need to transmit a single MIB message. If you follow through the numbers in the channel processing and modulation process and the number of resource elements that can be assigned to carry PBCH symbol data, you may easily figure out the number of subframes that are required to transmit a single MIB message. In conclusion, if we assume 'no repetition', we will need 8 subframes to transmit a MIB message. However in reality, a MIB is transmitted in 8 times of repeatition. So we will need 64 subframes to transmit a single MIB message.

How (in what kind of fashion) the single MIB (PBCH) repeats for transmission ? You will find the answer in next section.

Release 13 MasterInformationBlock-NB of 34 bits coded to 1600 bits and 800 QPSK symbols

NPBCH resource elements in subframe 0 numbered 1 to 100, times 8 subframes giving 800 symbols

34 bits of MIB-NB become 1600 coded bits and 800 QPSK symbols. Subframe 0 has room for 100 NPBCH symbols, so one copy of the MIB-NB needs 8 subframes.

100 symbols per subframe : the grid numbers the NPBCH resource elements from 1 to 100, around the LTE CRS, the NRS and the first three symbols.
8 subframes per copy : 800 symbols divided by 100 per subframe.
8 repetitions per subblock : each subblock is sent in 8 consecutive radio frames, so a full MIB-NB takes 64 radio frames.
The listing in the picture is Release 13 : the current MIB-NB is shown in the last section of this page.

Resource Element Mapping : 36.211-10.2.4.4

The biggest difference between NPBCH (LTE-NB) and PBCH (LTE) is resource element mapping and NPBCH transmission cycle. NPBCH transmission cycle can be illustrated as follows. You may read out some of the characteristics directly from this illustration as below.

NPBCH fills the whole subframe 0 of every radio frame except the first 3 symbols within the symbol
A PBCH data is repeated 8 times in 8 consecutive radio frames.
c_init value is reinitialized with LTE-NB Cell ID at every 64 radio frames (at the radio frame where N_fr mod 64 = 0)

Following illustration is based on my interpretation for the statements listed above. I hope I interpreted correctly, but let me know if any of you (readers) has different interpretation. Following indicate the process before the CRs mentioned above.

NPBCH subblocks repeated over 8 radio frames with the same scrambling mask, before the CRs

Before the CRs, each subblock is repeated over 8 radio frames with the same scrambling mask.

After the two recent CRs (R1-1703964, R1-1703913) are applied, the process has been modified as below. The key points in the CR is to apply the different scrambling mask for each transmission even for the same NPBCH subblock. Why this kind of CR is adopted ? The simple answer is that the original method turned out to be volnerable to interference when a cell is highly synchronized environment as in a MBSFN area. For the detailed explantion on this CR, refer to Ref [3] (Robust scrambling for NB-IoT broadcast channels ).

NPBCH subblocks repeated over 8 radio frames with a different scrambling mask for each repetition, after the CRs

After the CRs, each of the 8 repetitions of a subblock carries its own scrambling mask.

Since PBCH is the channel that carries Master Information Block, the description on MIB in 36.331 would give you a good high level description on PBCH scheduling. Followings are from 36.331 5.2.1.2a Scheduling for NB-IoT MIB scheduling.

Uses a fixed schedule with a periodicity of 640 ms and repetitions made within 640 ms.
The first transmission of the MIB-NB is scheduled in subframe #0 of radio frames for which the SFN mod 64 = 0
Repetitions are scheduled in subframe #0 of all other radio frames.
The transmissions are arranged in 8 independently decodable blocks of 80 ms duration

36.211 v19.3.0 clause 10.2.4.4 states the current rule. The 800 symbols are sent in subframe 0 for frame structure type 1, or subframe 9 for frame structure type 2, during 64 consecutive radio frames. Each radio frame carries one 100-symbol subblock, multiplied by a second scrambling sequence that is initialised at the start of every radio frame. That per-frame sequence is the change the two CRs introduced.

The same clause fixes two mapping rules. The first three OFDM symbols of the subframe are never used. And for the purpose of the mapping, the UE assumes CRS on antenna ports 0 to 3 and NRS on ports 2000 and 2001, whatever the actual configuration. So a UE can decode NPBCH before it knows the operation mode or the number of antenna ports.

One subframe per radio frame : subframe 0 in FDD, subframe 9 in TDD.
64 frames per MIB-NB : 8 subblocks, each repeated in 8 consecutive radio frames.
Two scrambling stages : one on the 1600 bits every 64 frames, and one on the symbols every radio frame.
The mapping assumes the worst case : resource elements for four CRS ports and two NRS ports are always skipped.

What does MIB-NB carry today ?

The listing in the summary picture above is the Release 13 MIB-NB. The 34-bit size has not changed since, so every number in the processing chain still holds. What has changed is how those 34 bits are used, because later releases took bits from spare.

Following is based on 36.331 v19.3.0 (Release 19)

MasterInformationBlock-NB ::=   SEQUENCE {
    systemFrameNumber-MSB-r13       BIT STRING (SIZE (4)),
    hyperSFN-LSB-r13                BIT STRING (SIZE (2)),
    schedulingInfoSIB1-r13          INTEGER (0..15),
    systemInfoValueTag-r13          INTEGER (0..31),
    ab-Enabled-r13                  BOOLEAN,
    operationModeInfo-r13           CHOICE {
        inband-SamePCI-r13              Inband-SamePCI-NB-r13,
        inband-DifferentPCI-r13         Inband-DifferentPCI-NB-r13,
        guardband-r13                   Guardband-NB-r13,
        standalone-r13                  Standalone-NB-r13
    },
    additionalTransmissionSIB1-r15  BOOLEAN,
    ab-Enabled-5GC-r16              BOOLEAN,
    partEARFCN-r17                  CHOICE {
        spare                           BIT STRING (SIZE (2)),
        earfcn-LSB                      BIT STRING (SIZE (2))
    },
    spare                           BIT STRING (SIZE (6))
}

Three fields are new. The first, additionalTransmissionSIB1-r15, tells the UE that additional SIB1-NB transmissions are present, and the network sets it only when schedulingInfoSIB1-r13 indicates 16 NPDSCH repetitions. The second, ab-Enabled-5GC-r16, enables access barring for UEs connected to 5GC, next to ab-Enabled-r13 for EPC. The third, partEARFCN-r17, carries the 2 least significant bits of the EARFCN for NTN bands that use the 100 kHz raster.

These fields take 5 bits in total: 1, 1 and 3, where the CHOICE itself costs one bit. So spare shrinks from 11 bits to 6 bits, and the MIB-NB stays at 34 bits. TDD cells send a separate message, MasterInformationBlock-TDD-NB.

The first two fields also show how NPBCH and MIB-NB share the job of telling the UE the time. The field systemFrameNumber-MSB-r13 carries only the 4 most significant bits of the SFN. The UE acquires the other 6 bits from NPBCH itself, because a MIB-NB spans 64 radio frames and 64 is 2 to the power of 6. In the same way, hyperSFN-LSB-r13 carries the 2 least significant bits of the hyper SFN, and SystemInformationBlockType1-NB carries the rest.

One more field needs a closer look, because the rest of the NB-IoT physical layer depends on it. The field operationModeInfo-r13 tells the UE how the NB-IoT carrier sits relative to an LTE carrier. Each of its four branches is 5 bits long. With the 2 bits that select the branch, the field always takes 7 bits. The branches carry different information, as the listing below shows.

Following is based on 36.331 v19.3.0 (Release 19)

Inband-SamePCI-NB-r13 ::=       SEQUENCE {
    eutra-CRS-SequenceInfo-r13      INTEGER (0..31)
}

Inband-DifferentPCI-NB-r13 ::=  SEQUENCE {
    eutra-NumCRS-Ports-r13          ENUMERATED {same, four},
    rasterOffset-r13                ChannelRasterOffset-NB-r13,
    spare                           BIT STRING (SIZE (2))
}

Guardband-NB-r13 ::=            SEQUENCE {
    rasterOffset-r13                ChannelRasterOffset-NB-r13,
    spare                           BIT STRING (SIZE (3))
}

Standalone-NB-r13 ::=           SEQUENCE {
    spare                           BIT STRING (SIZE (5))
}

ChannelRasterOffset-NB-r13 ::=  ENUMERATED {khz-7dot5, khz-2dot5, khz2dot5, khz7dot5}

In the inband-SamePCI case, the NB-IoT cell and the LTE cell share the physical cell ID and the number of reference signal ports. The field eutra-CRS-SequenceInfo-r13 maps to the E-UTRA PRB index of the carrier. The index counts from the middle of the LTE system. The LTE CRS sequence depends on where the PRB sits in the LTE carrier. So the UE needs this index to rebuild the LTE CRS inside the NB-IoT PRB.

In the inband-DifferentPCI case, the UE does not know the LTE cell ID, so it cannot rebuild the LTE CRS sequence. It still has to skip the CRS resource elements. The field eutra-NumCRS-Ports-r13 tells it how many there are: the same number of ports as NRS, or four ports. The inband-DifferentPCI and guardband branches also carry rasterOffset-r13. This field gives the offset from the LTE channel raster: -7.5, -2.5, 2.5 or 7.5 kHz. The standalone branch carries only spare bits, because no LTE carrier is nearby.

The operation mode matters as soon as the UE reads SIB1-NB. 36.213 clause 16.4.1.4 uses the field to choose the first OFDM symbol of the SIB1-NB NPDSCH. An in-band carrier has to leave room for the LTE control region.

Still 34 bits : the new fields came out of spare, so NPBCH coding is unchanged.
Release 15 added SIB1-NB repetitions : additionalTransmissionSIB1-r15 signals extra SIB1-NB transmissions.
Release 16 added 5GC barring : ab-Enabled-5GC-r16 sits next to ab-Enabled-r13.
Release 17 added NTN : partEARFCN-r17 carries two bits of the EARFCN for NTN bands.
operationModeInfo sets the LTE context : it tells the UE whether LTE CRS surround the carrier, how many ports they use, and how far the carrier sits from the LTE raster.

Reference

[1] 36.211 Physical channels and modulation

[2] 36.212 Multiplexing and Channel Coding

[3] Robust scrambling for NB-IoT broadcast channels

[4] 3GPP TS 36.211 v19.3.0 - clause 10.2.4, narrowband physical broadcast channel

[5] 3GPP TS 36.212 v19.3.0 - clause 5.3.1 and clause 6.4.1, broadcast channel

[6] 3GPP TS 36.331 v19.3.0 - MasterInformationBlock-NB and its field descriptions