BWP Setup / BWP Switching
The purpose of this tutorial is to show you how to add additional BWPs and Trigger BWP switching.
BWP is a mechanism newly introduced in NR by which we can split a channel bandwidth (CBW) into multiple (max 4) sub bandwidth so that a UE can perform all the call processing within a specified subband instead of handling the full bandwidth. Usually the bandwidth of a subband(i.e, a BWP) is configured to be smaller than the CBW (NOTE : In terms of the 3GPP standards, the bandwidth of a BWP can be same as a bandwidth of the whole channel, but in practice most of a BWP is configured to be smaller than the CBW).
If more than one BWPs are configured, it is possible for gNB to switch the current communication bandwidth (active BWP) to different BWPs as necessary. The switching is done by gNB using various triggers as illustrated below. Amarisoft gNB support all types of BWP switching mechanism shown below (NOTE : There are still some of the details that are not explictely specified in 3GPP, the detailed implemetation of some BWP switching mechanism is implemented with some assumption. Refer to Limitation section for the details)
Image Source : BWP switching in Sharetechnote
In 3GPP specification, it is allowed to configure a max 4 BWPs within a CBW, but in the field I don't see many cases where a network configures the max number of BWPs as of writing this note. Most common mode of usage seems to be to configure two BWPs, one with wide bandwidth (e.g, almost same as CBW) and the other one with very narrow bandwidth (like 20 Mhz) and use the wide band BWP in regular communication and switch it to the narrower BWP when there is no traffic or low traffic to save energy consumption.
Table of Contents
- BWP Setup / BWP Switching
- Test Setup
- Key Configuration Parameters
- Test 1 : DCI 1_1 based BWP Switching with Dynamic Switch
- Test 2 : BWP Switching with Rrc Trigger
- Configuration
- Sub Test 1 : Throughput triggered RRC Transmission
- Sub Test 2 : RemoteAPI triggered RRC Transmission
- Test 3 : DCI-based Switch - UL Trigger
- Test 4 : DCI-based Switch - DL Trigger
- RRC / NAS Signaling
- Limitations
- RRC Based Switching
- Search Space Selection During Switching
- UL Resource Allocation Not Changing after Switch
- Tips
Test Setup
Test setup for this tutorial is as shown below.
- SIM Card used in this tutorial is the one delivered with the system as it is.
- If you want to change the configuration, The tutorial Configuration Guide would help
There are several many ways to provide internet access to your CallBox. Followings are some of them I can think of. In this tutorial, I used the Case 4.
If you decided to use Case 2 and Case 3, following tips would be helpful.
Since Amari Callbox is running command line mode of Linux (Fedora or Ubuntu) NOT on GUI , it is not straightforward to enable / connect WiFi.
Followings are some of the command line command you would need to get WiFi connectivity. You may search these commands on internet for the detailed usage.
# nmcli dev status
# nmcli radio wifi
# nmcli device wifi rescan
# nmcli dev wifi list
# nmcli dev wifi connect network-ssid password "network-password"
Key Configuration Parameters
Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.
- dl_bwp
- ul_bwp
- bwp_id
- dl_bwp_id
- ul_bwp_id
- first_active_dl_bwp_id
- default_dl_bwp_id
- dl_bwp_rb_start
- dl_bwp_l_crb
- ul_bwp_rb_start
- ul_bwp_l_crb
- bwp_dynamic_switch
- bwp_switch_k0
- dci_bwp_switch
- rrc_cnx_reconf
- rrc_based_bwp_switch
- allow_rrc_bwp_switch
Test 1 : DCI 1_1 based BWP Switching with Dynamic Switch
Configuration
I used enb.default.cfg as the configuration for this tutorial but you may use any configuration as long as your DUT(UE) would support it.
I have used gnb-sa-n78-40Mhz-BwpSwitch.cfg which is copied and modified from gnb-sa.cfg .
I am using the default mme(mme-ims.cfg) , ims (ims.default.cfg) config as shown below.
The major modification/addition in gnb-sa-n78-40Mhz-BwpSwitch.cfg goes as follows :
I put all the bwp setting parameters in nr_cell_default: {}
Within nr_cell_default: { }, put bwp related parameters as follows. Actually the exact location of those parameters is not that critical, but the level (e.g, root level, sub parameter of a root level parameter etc) is important.
I put the following between prach:{} and pdcch:{}
I put the following between pdsch:{} and pdcch:{}
I put the following between csi_report_config:{} and pucch:{}
I put the following between pusch:{} and bwp_dynamic_switch:{}
I put the following between ul_bwp:[] and mac_config:{}
NOTE : The DL and UL bit rate is ORed to trigger BWP switching
NOTE : There are a few other parameters that are not used in this tutorial.
probe_interval (default set to 50 ms)
probe_counter_threshold (default set to 3)
when probe_counter_threshold consecutive measure of the throughput are above the threshold, then BWP switch is initiated
Add following lines to csi_resource_config: [ ]
Check Up before trying UE connection
Before you trying internet connection with UE, you need to check several basic things shown in this section and make it sure everything works as shown here, otherwise Internet connection from UE may not work.
Make it sure that the network interface with internet connectivity is up and tun0,1,2,3 are up.
Check up the routing table on CallBox PC. It would usually be as follows. (NOTE : The gateway Iface name may be different on your system depending on your system configuration. But you should see tun0, tun1, tun2, tun3 as shown below)
Make it sure that the call box can reach a server over the internet. I am checking the connectivity as follows
Try ping to 8.8.8.8. This is google DNS and this is configured as DNS by default in mme.cfg
Try ping to a url to check the DNS is working
[Optional] you may find the IP address to a specific url and try ping to the server with both in direct IP and url
Perform the Test
Before you trying to connect internet from your UE (DUT), you would suggest you to check up a few things first. Firs thing I would suggest is to disable WiFi on UE, otherwise most of UE would give higher priority to WiFi for data connection than cellular connection. So if WiFi is not disabled, UE would try to connect internet over WiFi instead of celluar network. (
Do the initial attach and confirm that UE is connected to Callbox. If you started 't' command before you powe on UE, you will get the traces for PRACH attempt. The presence of PRACH trace can be a good troubleshooting indicator for initial attach problem. If PRACH is properly received and the entire RACH process is completed, it is highly likely that the initial attach gets completed and start getting traffic log. Regarding the details on the meaning of each column of this log and how to use the information for troubleshoot, refer to this tutorial.
Confirm that UE is assigned with an IP. At least you should see at least one IP here. Otherwise, you need to troubleshoot it first to have at least one IP assigned to UE.
Ping from Callbox to UE and confirm that ping works
Try Browsing and make it sure that internet access works. Launch any type of browser app on your mobile phone and visit to any known sites (e.g, www.google.com) and see if it works.
Go to speedtest site and generate high data rate of traffic. There are various different sites for the speedtest and you can use any of them as you like.
Log Analysis
First check out initial BWP configuration in SIB1 and see if the message is set as you configured in the configuration file.
initialDownlinkBWP in SIB1 should be configured as you set in dl_bwp_rb_start and dl_bwp_l_crb for DL BWP 0 in the configuration file.
initialUplinkBWP in SIB1 should be configured as you set in ul_bwp_rb_start and ul_bwp_l_crb for UL BWP 0 in the configuration file.
BWPs other than initial BWP are usually configured in RRC Setup.
DL bwp 1 within downlinklinkBWP-ToAddModList in RRC Setup should be configured as you set in bwp_id, dl_bwp_rb_start, dl_bwp_l_crb within dl_bwp block in the configuration file.
UL bwp 1 within uplinkBWP-ToAddModList in RRC Setup should be configured as you set in bwp_id, ul_bwp_rb_start, ul_bwp_l_crb within ul_bwp block in the configuration file.
You can check on how BWP changes in low layer. Which BWP is in action can be confirmed by checking the bwp field in DCI 1_1 and DCI 0_1.
If you want to check if the bwp switching really happens, check if there is any point where bwp value changes in lower layer log. You may use 'Search' function in WebGUI to find those point easily.
An easier way to finding such a switching point is to check the high level description in Message column in the log. You can search the keywords 'switching to BWP index'.
If you configure different sizes of physical resources among different bwp and running high enough user traffic, you should see traffic changes according to the corresponding bwp configuration. You can easily confirm on this with WebGUI throughput plot.
Test 2 : BWP Switching with Rrc Trigger
In this test, I will show you how to switch BWP via RRC message, namely RRC triggered BWP switching. This is splitted into two sub categories depending on how the RRC message for BWP switching gets triggered. There are two different way to let gNB to transmit the RRC message for bwp switching. One is throughput threshold and the other one is Remote API.
Configuration
You need to enable two configuration parameter rrc_based_bwp_switch and allow_rrc_bwp_switch. rrc_based_bwp_switch is a parameter for the dynamic BWP switch based on throughput and allow_rrc_bwp_switch is at cell level and creates the PUCCH resources so that RRC based BWP switch works well
Sub Test 1 : Throughput triggered RRC Transmission
Since this is to trigger RRC switch by throughput, you need to generate some IP traffic. In this tutorial, I generated the IP throughput from gNB to UE using ltesim_server .
Followings are some highlights from the log you may pay attention to.
First check out which BWP are set as the active BWP before the switch. You can confirm on this by checking firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id in RRC setup.
Now check if there is any RRC Reconfiguration message that set firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id to target BWP id.
When the throughput gets lower again below the threshold you set in the configuration file, you should see another RRCReconfiguration with firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id back to previous state.
Now you can confirm the bwp switching at lower layer. As shown here, DCI type switches to DCI 1_0 in common search space during the transision period and then switched to DCI 1_1 with bwp=1 (target BWP) after RRC Configuration Complete message is recieved.
You can confirm on the BWP switching visually by checking out resource allocation in WebGUI. (
Sub Test 2 : RemoteAPI triggered RRC Transmission
You can use exact the same test setup and configuration file as in Test 1. The only difference is in how to trigger the switch. In this test, run the following RemoteAPI command (If you are not familiar with RemoteAPI, please go through the tutorial RemoteAPI first).
./ws.js enb '{"message":"rrc_cnx_reconf","enb_ue_id":1,"dl_bwp_id":1,"ul_bwp_id":1}'
If the remoteAPI command is successfully processed, RrcReconfiguration for BWP switching is sent as shown below.
When the gNB received the remote API, you should see a RRCReconfiguration with firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id switched to the destination BWP.
Test 3 : DCI-based Switch - UL Trigger
This test is for triggering BWP switching using DCI 0_1. The configuration is almost same as in Test 1 except the small changes as shown below. First, change is to add bwp_switch_k0 in pdsch : { } config. Actually this configuration is not requred for DCI 0_1, it is for DCI 1_1 triggering but I added this to use the same configuration file for both DCI 0_1 and DCI 1_1 triggering.
The second modification is to remove (comment out) bwp_dynamic_switch configuration from Test 1 configuration.
Now run the callbox and get UE attached. After the attach is complete and while the call is in connected state, run following RemoteAPI command. (NOTE : I would recommend you to do continous ping after attach so that the call status remain in connected mode).
./ws.js enb '{"message":"dci_bwp_switch","enb_ue_id":1,"ul_bwp_id":1}'
pdsch-TimeDomainAllocationList is modified by bwp_switch_k0 as shown below. Here you see that a couple of pdsch-ConfigCommon items which are set to be non-zero values.
Before the BWP switching, all the bwp in DCI is set to 0 as shown below.
Before the BWP switching, all the bwp in DCI is set to 1 as shown below.
Test 4 : DCI-based Switch - DL Trigger
This test is for triggering BWP switching using DCI 0_1. The configuration is almost same as in Test 1 except the small changes as shown below. First change is to add bwp_switch_k0 in pdsch : { } config. Actually this configuration is not requred for DCI 0_1, it is for DCI 1_1 triggering but I added this to use the same configuration file for both DCI 0_1 and DCI 1_1 triggering.
The second modification is to remove (comment out) bwp_dynamic_switch part from Test 1 configuration.
Now run the callbox and get UE attached. After the attach is complete and while the call is in connected state, run following RemoteAPI command. (
pdsch-TimeDomainAllocationList is modified by bwp_switch_k0 as shown below. Here you see that a couple of pdsch-ConfigCommon items which are set to be non-zero values.
Before the BWP switching, all the bwp in DCI is set to 0 as shown below.
When BWP switching command is recieved, gnb send DCI 1_1 with k0 as epecified in bwp_switch_k0 parameter.
After BWP switching happened, all the bwp in DCI 0_1 and DCI 1_1 is set to 1
RRC / NAS Signaling
SIB1 (SA)
: This is the SIB1 message sent by gNB to configure NR SA. (
{
message c1: systemInformationBlockType1: {
...
servingCellConfigCommon {
downlinkConfigCommon {
frequencyInfoDL {
frequencyBandList {
{
freqBandIndicatorNR 78
}
},
...
},
initialDownlinkBWP {
genericParameters {
locationAndBandwidth 13750,
subcarrierSpacing kHz30
},
offsetToPointA 36,
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz30,
carrierBandwidth 51
}
}
},
uplinkConfigCommon {
frequencyInfoUL {
scs-SpecificCarrierList {
{
offsetToCarrier 0,
subcarrierSpacing kHz30,
carrierBandwidth 51
}
},
p-Max 10
},
initialUplinkBWP {
genericParameters {
locationAndBandwidth 13750,
subcarrierSpacing kHz30
},
}
RrcSetup (SA)
: This is the RrcSetup message sent by gNB to configure NR SA. (
message c1: rrcSetup: {
rrc-TransactionIdentifier 0,
criticalExtensions rrcSetup: {
...
masterCellGroup {
cellGroupId 0,
rlc-BearerToAddModList {
{
...
},
mac-CellGroupConfig {
...
},
physicalCellGroupConfig {
pdsch-HARQ-ACK-Codebook dynamic
},
spCellConfig {
spCellConfigDedicated {
initialDownlinkBWP {
pdcch-Config setup: {
...
},
pdsch-Config setup: {
...
}
},
downlinkBWP-ToAddModList {
{
bwp-Id 1,
bwp-Common {
genericParameters {
locationAndBandwidth 28875,
subcarrierSpacing kHz30
},
pdcch-ConfigCommon setup: {
...
},
pdsch-ConfigCommon setup: {
...
}
},
bwp-Dedicated {
pdcch-Config setup: {
...
},
pdsch-Config setup: {
...
}
}
}
},
firstActiveDownlinkBWP-Id 0,
uplinkConfig {
initialUplinkBWP {
pucch-Config setup: {
..
},
pusch-Config setup: {
...
},
srs-Config setup: {
srs-ResourceSetToAddModList {
...
}
}
},
uplinkBWP-ToAddModList {
{
bwp-Id 1,
bwp-Common {
genericParameters {
locationAndBandwidth 28875,
subcarrierSpacing kHz30
},
pusch-ConfigCommon setup: {
...
},
pucch-ConfigCommon setup: {
...
}
},
bwp-Dedicated {
pucch-Config setup: {
...
},
pusch-Config setup: {
...
},
srs-Config setup: {
...
}
}
}
},
firstActiveUplinkBWP-Id 0,
pusch-ServingCellConfig setup: {
}
},
pdcch-ServingCellConfig setup: {
},
pdsch-ServingCellConfig setup: {
nrofHARQ-ProcessesForPDSCH n16
},
Limitations
If you see the document, you may find some of the parameters/configurations are labeled as 'Experimental'. It may imply that the detailed implementation may not match what you expected. You may call them as a kind of limitation, but most of the limitation comes from unclear statement in 3GPP specification. The implmentation will be revised / updated as 3gpp specification gets updated and clearer.
RRC Based Switching
RRC based BWP switching is still experimental, mainly because 3GPP specification is not really clear about it:
Concerning the PDCCH, the search space displayed in the log at the point of BWP switching is the common search space (it is not the search space belonging to any specific bwp), and that search space should be shared among all other BWP. It uses physical resources of the CoReSet 0.
Concerning the PUCCH used for A/N feedback, the eNB indeed expects it on the 'new' BWP because it considers that the UE has time to process the RRCReconfiguration before sending it, and the 3GPP specification 38.331 and 38.321 hints that BWP switch is immediate upon RRC Reconfiguration :
From 38.331 - 5.3.5.5.7 :
consider the bandwidth part indicated in firstActiveUplinkBWP-Id if configured to be the active uplink bandwidth part;
From 38.321 - 5.15.1 :
For each activated Serving Cell configured with a BWP, the MAC entity shall:
1> if a BWP is activated and the active DL BWP for the Serving Cell is not the dormant BWP:
[...]
2>transmit PUCCH on the BWP, if configured
Due to this ambiguity, there might be the case where it looks as if some message (RRC message directing the switching) , HARQ ack/nack) goes through wrong bwp. But it is not the case. It would be the matter of interpretation. Since those messages are going through the common search space linked to CoreSet 0, it looks as if it belong to any bwp.
Search Space Selection During Switching
The eNB always use the common search space for 'major' reconfiguration (and BWP switch is one of those).
Since the eNB has no way to know when the UE actually applies the configuration change until the reception of the RRC Reconfiguration Complete and during that time, the User specific search space is not safe.
In order to still be able to schedule the UE without risk, the eNB uses the Common search space. Per our understanding, scheduling on the common search space is always allowed by 3GPP so it shouldn't cause any issue.
UL Resource Allocation Not Changing after Switch
Sometimes you may see UL resource allocated in much smaller region than is configured in configuration file and in Rrc message. You may often see this issue when you switch from a narrow BWP0 to wider BWPn as shown in the following example.
This is due to 3GPP ambiguity regarding frequency hopping requirement of Common PUCCH. You may look into and compare PUCCH resource allocation for initial BWP and BWPn if you want to know further. To workaround this, you may change ra_type configuration for BWPn as shown below
ul_bwp: [
{
bwp_id: 1,
ul_bwp_rb_start: 0,
ul_bwp_l_crb: 273,
pucch: {
},
pusch: {
beta_offset_ack_index: 9,
dmrs_add_pos: 1,
dmrs_type: 1,
dmrs_max_len: 1,
tf_precoding: false,
mcs_table: qam64,
mcs_table_tp: qam64,
msg3_mcs: 4
}
}
],
Tips
Remove Warnings
Sometimes you may have some warning printed out on callbox screen (lte screen window) when you run with your configuration. Since it is (warning), it would not block the operation and still valid configuration in terms of 3GPP. But the connection may not be stable and even fail in applying the Rrc with the bwp configuration depending on UE implementation. So I would suggest to remove those warnings as much as possible. In this section, I would give you some tips on the meaning of these warnings and how to remove it.
CoReSet #0 not inside DL BWP #n
For stable operation of BWP, it is recommended for every DL BWP to include CoReSet0 in it. If you set BWP frequency region that does not include CoReSet0 frequency region, you will get this warning.
How to fix it ?
Open up gnb log in a text editor and you will see the information like following at the beginning of the file.
coreset0_prb=start_rb : n_rb ==> this indicates coreset0 occupies the rb between start_rb and (start_rb + n_rb - 1)
Make it sure that you assigned prb region for every BWP to include this PRB region in it.
for smooth SA RRC BWP switching, UL BWP #n must contain UL BWP #0
This suggest to configure every UL BWP to include UL BWP #0. Without removing this, initial attach to BWP 0 would work OK without problem, but the connection would not stable (or break in worst case) when you switch bwp from bwp0 to other bwp.
For example, if your UL PWP 0 as follows.
ul_bwp_rb_start: start_rb,
ul_bwp_l_crb: n_rb,
Configure rb region for UL BWP#n (Other UL BWPs) as follows :
ul_bwp_rb_start (for BWP#n) <= start_rb -----> let's call this start_rb_n
ul_bwp_l_crb (for BWP#n) >= (start_rb + n_rb) - start_rb_n
unused property
This is not only for BWP configuration, but applies to every configuration. If you see this warning, it is likely to be due to one of the following reason.
- The parameter is not supported by the callbox software
- The parameter is supported but it is configured in wrong place (check out enb.doc for the details)