Back in the ‘good old days’, things were simple on the LTE air interface. It served one purpose and one purpose only: Fast Internet connectivity. This allowed to keep most things about the air interface static. The 5G NR interface on the other hand tries to keep all options open for the future and the only constant used in the spec seems to the speed of light. Everything else has been kept flexible. In this and a number of future post I’d like to describe a number of concepts that have been standardized for the 5G NR air interface that do not exist in LTE. So let’s start with the Bandwidth Parts (BWPs).
In LTE, the maximum channel bandwidth is 20 MHz. All devices have to support it. Most devices today support even broader bandwidths and the network then bundles several carriers with a method referred to as Carrier Aggregation. While this is great for high speed Internet access, decoding even a 20 MHz channel is relatively power hungry and is thus not ideal for devices that only send or receive little data and should be as energy efficient as possible. Therefore, 3GPP extended the LTE standard many years after its initial creation to support low speed devices that only require a narrow channels. Refer to my articles on NB-IoT (Narrowband Internet of Things) and CAT-M devices for further info. But it was an afterthought and quite a kludge.
So when it came to 5G it was decided to build this in right from the start. Why add complexity later when you can do it from the start? Here, even the basic specification assumes that a device might not want to support the full 100 MHz channel bandwidth below 6 GHz or the full 400 MHz in the mmWave spectrum. In other words, they might only support a part of the full bandwidth, i.e. a Bandwidth Part, or BWP for short.
When connecting to the network, a 5G device can indicate which bandwidths it supports today in certain steps up to 100 MHz in a bitmap. Unfortunately, some spectrum auctions resulted in 90 MHz licenses which was not quite foreseen, so 90 MHz support was hacked into the standards a bit later. Devices now have to indicate 90 MHz support separately to the maximum value supported. For details see 38.101 table 5.3.5-1. And they thought they were flexible…
So let’s come back to the BWPs. All 5G NR NSA devices on the market today support the full bandwidth of a 5G NR channel of 100 MHz today as far as I can tell. Typically, they are then assigned a single Bandwidth Part that spans the complete bandwidth of the channel. The 3GPP specification allows up to 4 different BWPs to be assigned to a mobile device and non of them necessarily has to span the complete bandwidth. In practice, however, one BWP is assigned to a smartphone and it spans the complete carrier. This is the easiest network configuration I have observed in practice. I’ve seen other implementations in practice that configure two BWPs to a smartphone, an initial BWP only spanning part of the spectrum and another BWP over the full channel. Perhaps this is done to reduce UE power consumption when only little data is transferred, but I wonder if that really makes a huge difference.
There are several ways for the network to switch between the different BWPs and a common implementation seems to be to indicate which BWP is to be used in bandwidth assignments to UEs on the Physical Downlink Control Channel (PDCCH). The BWPs can have different sizes in the uplink and downlink directions but this doesn’t seem to be used in practice.
And here’s how a Bandwidth Part is configured in a RRCReconfiguration message that adds a 5G cell to an existing LTE connection:
SCS-SpecificCarrier offsetToCarrier: 0 subcarrierSpacing: kHz30 carrierBandwidth: 217 [...] initialDownlinkBWP genericParameters locationAndBandwidth: 16499 subcarrierSpacing: kHz30 [...]
While the subcarrier spacing information element is straight forward, the Location and Bandwidth information element is quite obscure. As the name suggests it encodes at which Resource Block (RB) from the bottom it starts and how many RBs it spans. This page over at Sharetechnote contains a detailed discussion on how the value is calculated. In my example above, the carrier bandwidth is 217 Resource Blocks. At a subcarrier spacing of 30 kHz, this results in a total carrier bandwidth of 217 RB * 12 symbols * 0,03 MHz = 78,12 Mhz, i.e. 80 MHz. When you use the formula linked to above and assume that the BWP starts at 0 and spans the full 217 RBs, you end up with a locationAndBandwidth value of 16499 as in the example above. The value for a 90 MHz channel with 245 RB in total is 8799. Totally non-intuitive…
So here we go, this is the story on the Bandwidth Part!