Amarisoft

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)

NR BWP 01

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

Introduction

Bandwidth Part (BWP) is a pivotal feature introduced in 5G New Radio (NR) that enables dynamic and efficient utilization of radio resources by partitioning the overall channel bandwidth (CBW) into multiple sub-bandwidths, known as BWPs. Each BWP represents a contiguous subset of the total available channel bandwidth, allowing User Equipment (UE) to operate within a narrower, more energy-efficient frequency range, rather than always processing the entire channel bandwidth. This architectural enhancement was standardized by 3GPP and is designed to address the diverse requirements of modern 5G networks, where use cases range from high-throughput data applications to ultra-low-power Internet of Things (IoT) devices. By configuring up to four BWPs within a single CBW, network operators and equipment vendors can flexibly allocate spectrum resources based on real-time traffic demands, service types, and UE capabilities. The gNB (5G base station) can dynamically trigger BWP switching using a variety of mechanisms, optimizing for power efficiency, latency, and throughput as network conditions change. This tutorial focuses on the practical aspects of adding additional BWPs and triggering BWP switching, equipping readers with the architectural understanding and procedural knowledge necessary for effective configuration and management in a 5G NR environment. The concepts covered herein are foundational to achieving both spectral efficiency and energy savings, which are critical goals in the evolution of mobile wireless technology.

Summary of the Tutorial

This tutorial covers multiple test procedures for configuring and verifying Bandwidth Part (BWP) switching in a 5G NR Standalone (SA) environment using an Amarisoft Callbox. The tests demonstrate both DCI-based and RRC-based BWP switching, with detailed setup, configuration, execution, and analysis steps. The procedures are structured as follows:

Throughout the tutorial, strict attention is given to configuration hierarchy, correct parameter placement, and the use of both GUI and command-line tools for verification and troubleshooting. Each test provides a structured methodology for validating BWP switching functionality in both downlink and uplink directions, using dynamic, RRC, and RemoteAPI triggers.

Test Setup

Test setup for this tutorial is as shown below. Note : I will be using IP throughput as a trigger for bwp switching and I will use Speedtest site on the internet to generate IP traffic, this is why I need to configure Internet access test setup here. If you think this is too much to bother and want to use simpler way to generate IP data (e.g, iperf or LteSimserveron callbox) you would not need to setup the internet environment)

TestSetup Callbox Internet 01

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.

TestSetup Callbox Internet 02

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.

Key Configuration Parameters

Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.

Test 1 : DCI 1_1 based BWP Switching with Dynamic Switch

The purpose of this test is to verify that the UE can correctly switch the active Bandwidth Part (BWP) when the network dynamically commands the switch using DCI format 1_1. This test confirms that the UE properly interprets the BWP indicator in DCI 1_1 and immediately applies the new active BWP during ongoing scheduling.

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 .

NR BWP Test1 Configuration 01

I am using the default mme(mme-ims.cfg) , ims (ims.default.cfg) config as shown below.

NR BWP Test1 Configuration 02

The major modification/addition in gnb-sa-n78-40Mhz-BwpSwitch.cfg goes as follows :

The main modification in this configuration is the addition of all BWP-related configuration parameters into nr_cell_default. This change allows the BWP behavior to be controlled from a common default cell configuration block.

NR BWP Test1 Configuration 03

Within nr_cell_default, the BWP related parameters are added to define the initial downlink Bandwidth Part configuration. The exact physical location of these parameters inside the configuration file is not strictly critical, but the configuration hierarchy level must be correct so that the gNB parser can interpret them properly.

In this example, the parameters are placed between prach {} and pdcch {} sections. first_active_dl_bwp_id defines which DL BWP becomes active when the cell starts. dl_bwp_rb_start specifies the starting RB position of the DL BWP within the carrier, and dl_bwp_rb_size (or equivalent parameter) defines the BWP width. The configuration also ensures that the BWP bandwidth is larger than CORESET 0 so that the control resources remain fully contained within the active BWP.

NR BWP Test1 Configuration 04

Between pdsch {} and pdcch {} sections, a new DL BWP configuration block is defined using dl_bwp[]. This block defines an additional Downlink Bandwidth Part that the gNB can switch to during operation.

bwp_id identifies the BWP instance. dl_bwp_rb_start specifies the starting RB of this BWP and dl_bwp_l_crb defines the BWP size. If these parameters are omitted, the system automatically sets the start RB to 0 and the BWP size to the maximum RB allowed for the carrier bandwidth.

Inside the BWP configuration, the PDCCH and PDSCH parameters are also defined. The pdcch section configures the dedicated CORESET, search space parameters such as n_candidates, and enables DCI formats like 0_1 and 1_1 for scheduling. The pdsch section defines the data channel behavior including DMRS configuration, MCS table selection, resource allocation type, and VRB-to-PRB interleaving. These parameters together define how control and data channels operate within this specific BWP.

NR BWP Test1 Configuration 10

Between csi_report_config {} and pucch {} sections, the UL BWP related parameters are added to define the uplink Bandwidth Part. This sets the RB start position and the RB size for UL BWP #0.

ul_bwp_rb_start defines where the uplink BWP begins in the carrier, and ul_bwp_l_crb defines the width of the uplink BWP. In this configuration, these values should match the downlink BWP setting so that UL and DL BWPs stay aligned for the test scenario.

NR BWP Test1 Configuration 06

Between pusch {} and bwp_dynamic_switch {} sections, an additional uplink BWP configuration block is defined using ul_bwp[]. This block describes another UL Bandwidth Part that can be activated when the network performs BWP switching.

bwp_id identifies the uplink BWP instance. ul_bwp_rb_start specifies the starting RB position of this BWP and ul_bwp_l_crb defines the BWP size. If these parameters are not specified, the system automatically sets the start RB to 0 and the BWP size to the maximum RB allowed by the carrier bandwidth.

Within this BWP configuration, the pucch and pusch sections define the control and data channel behavior for the uplink. The pusch section specifies parameters such as beta offset for ACK, DMRS configuration, transform precoding setting, and MCS table selection. These parameters determine how uplink data transmission operates when this UL BWP becomes active.

NR BWP Test1 Configuration 07

Between ul_bwp[] and mac_config {} sections, the parameter block bwp_dynamic_switch {} is added to enable automatic BWP switching based on the current traffic throughput.

This configuration allows the gNB to dynamically switch between two BWPs depending on the measured DL or UL bit rate. When the throughput exceeds the configured threshold values, the system switches to the high-bandwidth BWP (bwp_id_high). When the throughput drops below the lower threshold, it switches back to the low-bandwidth BWP (bwp_id_low).

dl_high_rate_threshold and ul_high_rate_threshold define the trigger bit rates for downlink and uplink respectively. The low thresholds are automatically derived as half of the configured high thresholds. The switching decision is triggered when either DL or UL bit rate exceeds the configured threshold.

Additional parameters such as probe_interval and probe_counter_threshold control how often the throughput is measured and how many consecutive measurements above the threshold are required before initiating the BWP switch.

NR BWP Test1 Configuration 08

Additional CSI configuration entries are added in csi_resource_config[] so that CSI-RS resources are associated with specific DL BWPs. Each configuration entry defines which CSI resource set is used and which BWP contains the CSI-RS transmission.

The parameter bwp_id specifies the DL BWP where the CSI-RS resource exists. In this example, the first configurations are associated with BWP 0, while an additional configuration (enabled when USE_TRS is defined) associates CSI-RS with BWP 1. This allows the UE to perform channel measurements correctly when the active DL BWP changes.

NR BWP Test1 Configuration 09

Check Up before trying UE connection

Before attempting UE internet connectivity, it is important to verify that the basic network interfaces on the Callbox system are operating correctly. The interface that provides external internet access must be active, and the internal tunnel interfaces used by the core network must also be running.

In this example, the LAN interface eno1 is connected to the local network and has received an IP address from the WiFi access point. This interface provides the path to the external internet. The interfaces tun0, tun1, tun2, and tun3 are virtual tunnel interfaces created by the Callbox EPC. These interfaces carry UE data traffic inside the core network and the IP addresses assigned to them are defined in the MME configuration file.

The IP subnet of eno1 does not need to match the subnet used by the tunnel interfaces. Network Address Translation performs the packet forwarding between the UE tunnels and the external network interface. As long as the interfaces are up and properly configured, the system can route UE traffic to the internet.

TestSetup Callbox Internet CheckUp 01

TestSetup Callbox Internet CheckUp 02

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)

This explains how the Linux routing table on the CallBox PC determines the outgoing interface for each packet.

Linux decides the outgoing path of every IP packet by checking the routing table. The routing table contains a list of destination networks and the interface that should be used to reach each network.

When a packet is generated, Linux first checks whether the destination address belongs to one of the explicitly defined networks. In this example, the routing table contains entries for several networks such as 10.0.0.0/24 and 192.168.2.0/24 to 192.168.5.0/24.

If the destination IP belongs to the 10.0.0.x network, the packet is sent through interface eno1. If the destination belongs to 192.168.2.x, the packet is routed through tun0. Similarly, packets destined for 192.168.3.x, 192.168.4.x, and 192.168.5.x are routed through tun1, tun2, and tun3 respectively. These tun interfaces usually represent tunnel interfaces used to carry UE traffic between the eNB/gNB and the core network components.

If the destination address does not match any of these specific network entries, Linux uses the default route. In this example, the default route points to gateway 10.0.0.1 through interface eno1, meaning that all other traffic is forwarded to this gateway.

The routing entries for tun0, tun1, tun2, and tun3 are typically created automatically when the tunnel interfaces are configured by the mme-ifup script. When UE packets arrive through one of these tunnel interfaces and the destination is outside the UE subnet, the NAT configuration in the lte_init.sh script translates the packet and forwards it to the default gateway so that the traffic can reach external networks.

TestSetup Callbox Internet CheckUp 03

Make sure that the CallBox PC has internet connectivity before starting the LTE/5G test environment. This is important because the CallBox may need to access external servers such as DNS or software repositories.

A simple way to verify internet connectivity is to send an ICMP ping to a well-known public server. In this example, the destination address is 8.8.8.8, which is the public DNS server operated by Google. This address is commonly used for connectivity tests and is also configured as the default DNS server in mme.cfg.

When the command `ping 8.8.8.8` is executed, the system sends ICMP echo requests to the remote server. If the network connection is working properly, the server responds with ICMP echo replies. Each reply line shows information such as the sequence number, TTL value, and round-trip time.

If the replies are received successfully with reasonable latency values, it confirms that the CallBox can reach external networks through the configured gateway. This also indicates that the routing table and NAT configuration are functioning correctly and that the system is able to communicate with internet hosts.

TestSetup Callbox Internet CheckUp 04

Try pinging a domain name to verify that DNS resolution is working correctly on the CallBox PC.

Instead of using a raw IP address, the command `ping www.google.com` sends a request to a hostname. Before the packet is transmitted, the system must resolve the hostname to an IP address using the configured DNS server. If DNS is working properly, the hostname will be translated into an IP address and the ping command will start sending ICMP packets to that address.

In the example shown, the hostname `www.google.com` is successfully resolved to an IPv6 address. The output displays the resolved host name and its IP address, followed by ICMP reply messages. Each reply indicates that the system was able to resolve the domain name and communicate with the remote server.

Successful replies confirm two things. First, the DNS configuration in the system (typically defined in mme.cfg or the system resolver settings) is functioning correctly. Second, the CallBox has proper internet connectivity and can reach external hosts using domain names.

TestSetup Callbox Internet CheckUp 05

Optionally, you can directly query the DNS server to find the IP address associated with a specific domain name. This helps verify that the DNS server is responding correctly and also allows you to test connectivity using both the domain name and the resolved IP address.

The command `nslookup www.google.com` sends a DNS query to the configured DNS server. The output first shows the DNS server that handled the request, including its IP address and port number. This confirms which DNS server the system is currently using for name resolution.

The result section labeled “Non-authoritative answer” shows the IP addresses returned for the requested domain name. In this example, the domain `www.google.com` resolves to both an IPv4 address and an IPv6 address. This means the DNS server successfully translated the hostname into reachable network addresses.

Once the IP address is known, you can perform additional connectivity tests. For example, you can run `ping www.google.com` to test DNS resolution and connectivity together, and you can run `ping <resolved IP address>` to test direct network reachability without relying on DNS resolution. This helps isolate whether a connectivity issue is related to DNS configuration or general network routing.

TestSetup Callbox Internet CheckUp 06

Perform the Test

Before attempting to access the internet from the UE (DUT), it is recommended to check a few conditions on the device. The first step is to disable WiFi on the UE. Most smartphones give higher priority to WiFi connections when both WiFi and cellular connectivity are available. If WiFi remains enabled, the device may attempt to access the internet through the WiFi network instead of the cellular connection provided by the CallBox.

For this reason, WiFi should be turned off to ensure that all data traffic goes through the cellular interface during the test. This helps verify that the LTE or 5G connection established with the CallBox is actually providing the internet connectivity.

The exact behavior may vary depending on the UE firmware implementation. Some devices may automatically switch between WiFi and cellular depending on signal strength or internal policy. However, disabling WiFi ensures consistent and predictable behavior during the test procedure and avoids ambiguity when validating the cellular data connection. (NOTE : This behavior would vary depending on UE firmware implementation, but it would be better to disable WiFi for consistency of the test).

NR BWP Test1 Run 01

Power on the UE and perform the initial attach procedure to confirm that the UE successfully connects to the CallBox. Before powering on the UE, it is recommended to start the `t` command on the CallBox so that the system begins capturing radio traces.

If the trace is already running when the UE starts the attach procedure, you will be able to observe the PRACH attempt from the UE. The appearance of a PRACH message in the trace indicates that the UE has detected the cell and is attempting to start the Random Access procedure. This is an important troubleshooting indicator when analyzing initial attach issues.

If the PRACH is properly received by the eNB and the full RACH procedure is successfully completed, the connection setup usually proceeds to the RRC and NAS procedures required for the initial attach. After the attach is completed, the trace will start showing traffic statistics and radio link information for the connected UE.

The trace output displayed by the `t` command shows various radio parameters such as CQI, MCS, retransmissions, throughput, and signal quality indicators. These values provide useful insight into the uplink and downlink radio conditions between the UE and the CallBox. For detailed explanations of each column and how to interpret the trace for troubleshooting purposes, refer to the linked tutorial.

Regarding the details on the meaning of each column of this log and how to use the information for troubleshoot, refer to this tutorial.

NR BWP Test1 Run 02

After the UE completes the attach procedure, verify that the UE has been assigned an IP address by the network. This can be checked from the MME console using the `ue` command.

The output shows a list of currently connected UEs along with key identifiers and connection parameters. The fields include identifiers such as SUPI (or IMSI), IMEISV, the core network type, temporary identifiers like M-TMSI or 5G-TMSI, registration status, tracking area code (TAC), the number of active bearers, and the IP address assigned to the UE.

The most important field to verify at this stage is the IP_ADDR column. If the attach procedure and default bearer setup have been completed correctly, the UE should have at least one IP address assigned. In the example shown, the UE has been assigned the address 192.168.3.2.

If no IP address appears in this list, it usually indicates that the PDN connectivity procedure or default bearer establishment did not complete successfully. In that case, the issue should be investigated before proceeding further, because without a valid IP address the UE will not be able to send or receive data traffic through the network.

NR BWP Test1 Run 03

After confirming that the UE has been assigned an IP address, the next step is to verify basic connectivity between the CallBox and the UE. This can be done by sending ICMP ping packets from the CallBox to the UE’s assigned IP address.

In this example, the CallBox sends a ping request to the UE at address 192.168.3.2. If the network configuration and bearer setup are correct, the UE will respond with ICMP echo replies. Each reply indicates that packets are successfully traveling through the data path between the CallBox and the UE.

The output shows multiple reply messages with sequence numbers, TTL values, and round-trip times. The presence of these replies confirms that the user plane path between the CallBox and the UE is functioning correctly and that the UE is reachable through its assigned IP address.

If the ping fails or no reply is received, it usually indicates a problem in the data path, such as an issue with bearer establishment, routing configuration, tunnel interface setup, or NAT configuration. Therefore, successful ping responses provide a simple but effective validation that the UE data connectivity within the test network is working properly.

NR BWP Test1 Run 04

After confirming basic connectivity between the CallBox and the UE, the next step is to verify that the UE can access the internet through the cellular connection.

Open a web browser application on the UE and try visiting a well-known website such as [www.google.com](http://www.google.com). If the network configuration, routing, and NAT settings are correct, the page should load successfully through the cellular data connection provided by the CallBox.

Successful browsing confirms that the entire data path is functioning properly. This includes the UE data bearer, the tunnel interfaces between the CallBox and the core network components, the routing configuration on the CallBox PC, and the NAT configuration that forwards UE traffic to the external internet.

During this type of light data activity such as simple web browsing, the UE typically remains in BWP 0. This bandwidth part is usually configured for low throughput operation and is sufficient for small amounts of data traffic such as loading a web page or sending basic requests.

NR BWP Test1 Run 05

After confirming that basic internet browsing works, the next step is to generate higher data traffic to observe how the network behaves under heavy load.

Open a browser on the UE and go to any internet speed test website. There are many available speed test services, and any of them can be used to generate high data throughput. When the speed test begins, the UE will start downloading and uploading large amounts of data in a short period of time.

During this high data rate operation, the network scheduler may switch the UE from the initial low-bandwidth configuration to a wider bandwidth configuration. In this example, the UE initially operates in BWP 0, which is typically configured for low data rate operation and minimal bandwidth usage. When the speed test generates high traffic demand, the network triggers a BWP switch so that the UE moves from BWP 0 to BWP 1.

BWP 1 is usually configured with a larger bandwidth and higher throughput capability. This allows the UE to achieve higher data rates and efficiently handle the heavy traffic generated by the speed test application. Observing this behavior confirms that the dynamic BWP switching mechanism is working as expected and that the network can adapt its bandwidth allocation according to traffic demand.

NR BWP Test1 Run 06

Log Analysis

Sample Log

First verify the initial BWP configuration broadcast in SIB1 and confirm that it matches the configuration defined in the gNB configuration file. This step ensures that the UE receives the correct initial bandwidth part information during cell acquisition.

In SIB1, the parameter initialDownlinkBWP should reflect the values configured in the file, particularly the starting RB position and the BWP size defined by dl_bwp_rb_start and dl_bwp_l_crb for DL BWP 0. If the values in SIB1 match the configuration, it confirms that the gNB is broadcasting the intended initial BWP settings.

NR BWP Test1 Log 01

Next verify the uplink BWP configuration broadcast in SIB1 and confirm that it matches the parameters configured in the gNB configuration file. This ensures that the UE receives the correct uplink bandwidth configuration during the initial system information acquisition.

In SIB1, the parameter initialUplinkBWP should reflect the values configured in the file, particularly the starting RB position and the BWP size defined by ul_bwp_rb_start and ul_bwp_l_crb for UL BWP 0. If the values shown in SIB1 match the configuration, it confirms that the uplink BWP is being broadcast correctly by the gNB.

NR BWP Test1 Log 02

BWPs other than the initial BWP are typically configured through the RRC Setup message after the UE begins the connection procedure. This message delivers additional BWP configurations that the UE may later switch to during operation.

In this example, DL BWP 1 is included in downlinkBWP-ToAddModList in the RRC Setup message. The parameters in this message should match the values configured in the gNB configuration file within the dl_bwp block, including bwp_id, dl_bwp_rb_start, and dl_bwp_l_crb. This confirms that the gNB correctly signals the additional BWP configuration to the UE during the RRC connection setup stage.

NR BWP Test1 Log 03

Additional uplink BWPs are also configured through the RRC Setup message. This message informs the UE about uplink BWPs other than the initial one so that the UE can switch to them later if instructed by the network.

In this example, UL BWP 1 appears in uplinkBWP-ToAddModList within the RRC Setup message. The parameters in this message should match the configuration defined in the gNB configuration file inside the ul_bwp block, including bwp_id, ul_bwp_rb_start, and ul_bwp_l_crb. This confirms that the uplink BWP configuration is correctly delivered to the UE during the RRC connection setup.

NR BWP Test1 Log 04

You can verify the actual BWP switching in lower layer logs. The active BWP can be identified by checking the bwp field carried in DCI 1_1 and DCI 0_1.

If BWP switching is working properly, there should be a point in the lower layer log where the bwp value changes. In this example, the bwp field stays at 0 while the system is operating on the initial BWP, and then changes to 1 when the traffic condition triggers the switch to the higher bitrate BWP. A practical way to find this point is to use the Search function in WebGUI and look for bwp=1 or related DCI entries.

NR BWP Test1 Log 05

A simpler way to identify the BWP switching point is to check the high level message description in the Message column of the log. Instead of analyzing individual DCI fields, you can directly look for messages that indicate the BWP change event.

In the Amarisoft WebGUI log viewer, the MAC layer prints a message such as “switching to BWP index = X” when the active BWP changes. By using the Search function and searching for the keyword “switching to BWP index”, you can quickly locate the exact moment when the BWP transition occurs. This makes it much easier to verify that the dynamic BWP switching mechanism is working as expected.

NR BWP Test1 Log 06

If different BWP sizes are configured and sufficient user traffic is generated, the throughput should change according to the active BWP configuration. A larger BWP allows more physical resource blocks, which results in higher achievable data throughput compared to a smaller BWP.

This behavior can be easily confirmed using the throughput plot in the WebGUI statistics window. When the traffic rate exceeds the configured threshold and the system switches to a wider BWP, the throughput increases accordingly. You can move the mouse over the plot to identify the moment when the bit rate crosses the threshold and click that point to trace back to the corresponding log entry. The selected point will be highlighted in the trace log, allowing you to correlate the throughput change with the BWP switching event.

NR BWP Test1 Log 07

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

To enable RRC-based BWP switching, two configuration parameters need to be activated: rrc_based_bwp_switch and allow_rrc_bwp_switch.

The parameter rrc_based_bwp_switch enables dynamic BWP switching based on traffic throughput conditions. When the configured DL or UL bit rate thresholds are exceeded, the system triggers a BWP change through RRC procedures. The parameter allow_rrc_bwp_switch is configured at the cell level and enables the creation of the necessary PUCCH resources so that the UE can properly handle the RRC-based BWP switching process.

NR Bwp Test2 Config 01

Sub Test 1 : Throughput triggered RRC Transmission

Since the switching condition depends on the data rate, it is necessary to generate IP traffic between the network and the UE.

In this example, IP traffic is generated from the gNB toward the UE using the ltesim_server  tool. The command sends continuous traffic to the UE so that the throughput can exceed the configured threshold, which then triggers the RRC based BWP switching procedure. .

NR Bwp Test2 SubTest 1 LteSimServer 01

NOTE : If you want to capture the full stack log with high throughput and still want to collect the complete /full stack log without losing any data, I would suggest not to run WebGUI during the test. Just run and collect to log from /tmp directly and post process the log using WebGUI after the test.

NOTE : If you are using commercial UE as DUT, the simplest way would be to download files from the UE like watching a YouTube or downloading a big file.

Followings are some highlights from the log you may pay attention to.

Sample Log

First verify which BWP is configured as the active BWP before any switching occurs. This can be confirmed in the RRC Setup message.

In the RRC Setup, the parameters firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id indicate which DL and UL BWPs are initially active after the UE establishes the RRC connection. By checking these fields in the log, you can confirm the starting BWP configuration before any dynamic or RRC-triggered BWP switching takes place.

NR Bwp Test2 SubTest 1 Log 01

Next check whether an RRC Reconfiguration message is transmitted to change the active BWP. This message is used by the network to command the UE to switch from the current BWP to another configured BWP.

In the RRC Reconfiguration message, the parameters firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id are updated to the target BWP ID. When these fields change from the previous value (for example from 0 to 1), it indicates that the gNB is instructing the UE to activate BWP 1 for both downlink and uplink.

After receiving this message, the UE applies the new BWP configuration and begins operating on the new bandwidth part. In the log, this can be confirmed by locating the RRC Reconfiguration message and checking the updated values of firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id. Once the UE processes the command and sends the RRC Reconfiguration Complete message, the BWP switch procedure is considered successfully completed.

NR Bwp Test2 SubTest 1 Log 02

When the traffic throughput drops below the configured threshold again, the network triggers another RRC Reconfiguration to return the active BWP to the previous lower-bandwidth configuration.

In this situation, the gNB sends a new RRC Reconfiguration message where the parameters firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id are changed back to the original BWP ID (for example from 1 back to 0). This indicates that the network has decided that the high-bandwidth BWP is no longer necessary and that the UE should return to the smaller BWP.

After the UE receives this message, it reconfigures its active bandwidth part accordingly and continues communication using the lower-bandwidth configuration. As before, the successful completion of this procedure can be confirmed when the UE sends the RRC Reconfiguration Complete message in the log.

NR Bwp Test2 SubTest 1 Log 03

You can also confirm the BWP switching behavior at the lower layer by observing the DCI formats transmitted on PDCCH. During the BWP transition period, the scheduling behavior temporarily changes before the UE fully switches to the new BWP.

In this example, during the transition phase after the RRC Reconfiguration is sent but before the UE completes the reconfiguration, the network schedules data using DCI 1_0 in the common search space. In this phase, the DCI does not carry the BWP field because the scheduling still follows the previous configuration context.

Once the UE processes the RRC Reconfiguration and sends the RRC Reconfiguration Complete message, the scheduling returns to the normal configuration. At this point, the gNB starts transmitting DCI 1_1 again, and the DCI explicitly includes the bwp field indicating the target BWP (for example bwp=1). This confirms that the UE has successfully switched to the new active BWP and the scheduling now operates on the new bandwidth part.

NR Bwp Test2 SubTest 1 Log 04

You can also visually confirm the BWP switching by observing the resource allocation view in the WebGUI. The resource block allocation display shows which portion of the carrier bandwidth is being used for scheduling at any given time.

When the system operates on BWP 0, the scheduled resources appear only within the RB region defined for BWP 0. After the BWP switch occurs, the scheduling moves to the RB region corresponding to BWP 1. As a result, the location and width of the resource allocations on the grid change according to the target BWP configuration.

This type of visual confirmation works only when the BWPs have different bandwidth sizes or different frequency locations. If the BWPs have identical size and position, the resource allocation pattern would appear the same and the BWP change would not be visually distinguishable. (NOTE : This kind of visual confirmation would work only when the bandwidth and location for the source and destination BWP are different).

NR Bwp Test2 SubTest 1 Log 05

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).

In this test, the BWP switch is triggered by sending a RemoteAPI command to the gNB. The command requests an RRC connection reconfiguration for the target UE and specifies the desired downlink and uplink BWP IDs. When this command is executed, the gNB generates an RRC Reconfiguration message toward the UE with the specified dl_bwp_id and ul_bwp_id values. After the UE processes this message and sends the RRC Reconfiguration Complete response, the UE begins operating on the newly selected BWP.

NR BWP Test2 RemoteApi 01

If the remoteAPI command is successfully processed, RrcReconfiguration for BWP switching is sent as shown below.

Sample Log

hen the gNB receives the RemoteAPI command, it immediately triggers an RRC Reconfiguration toward the target UE. This message carries the new BWP configuration that the UE should switch to.

In the RRC Reconfiguration message, the parameters firstActiveDownlinkBWP-Id and firstActiveUplinkBWP-Id are updated to the destination BWP ID specified in the RemoteAPI command. This indicates that the network is instructing the UE to activate the new BWP for both downlink and uplink operation.

After the UE receives this message and applies the configuration, it responds with an RRC Reconfiguration Complete message. At this point the BWP switch is finished and the UE continues communication using the newly selected BWP.

NR Bwp Test2 SubTest 2 Log 01

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.

In this test, the parameter bwp_switch_k0 is added inside the pdsch {} configuration block. This parameter defines the slot offset used when the BWP switch is triggered through DCI 1_1 scheduling. Although this parameter is not strictly required for DCI 0_1 based switching, it is included here so that the same configuration file can be used for both DCI 0_1 and DCI 1_1 based BWP switching tests.

NR BWP Test3 Config 01

The second change is to disable the bwp_dynamic_switch configuration that was used in Test 1. In this test, automatic throughput-based switching is not needed because the BWP change is triggered explicitly by DCI signaling.

If bwp_dynamic_switch remains enabled, the gNB may automatically move the UE to another BWP based on traffic conditions. That can interfere with the intended DCI-based test flow. Therefore this block should be commented out so that the BWP changes only when the specific DCI trigger is sent.

NR BWP Test3 Config 02

Start the Callbox and attach the UE. After the attach procedure is completed and the UE is in the connected state, you can trigger the BWP switching using the RemoteAPI command.

It is recommended to run a continuous ping after the UE attaches so that the connection remains active and the UE stays in RRC Connected mode. Then execute the RemoteAPI command dci_bwp_switch with the target uplink BWP ID. When this command is sent, the gNB triggers the BWP switching procedure using DCI signaling for the specified UE.

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}'

NR BWP Test3 RemoteAPI 01

Sample Log

The parameter bwp_switch_k0 modifies the pdsch-TimeDomainAllocationList configuration broadcast in SIB1. When this parameter is configured, the value of k0 in the PDSCH time domain allocation entries becomes non-zero.

The k0 value represents the slot offset between the DCI scheduling command and the actual PDSCH transmission. By setting bwp_switch_k0, the system introduces a scheduling delay that allows the BWP switching procedure to be properly handled before the scheduled PDSCH transmission occurs. As a result, several pdsch-ConfigCommon entries in the broadcast configuration show non-zero k0 values, reflecting the updated scheduling timing associated with the BWP switching configuration.

NR BWP Test3 Log 01

Before the BWP switching is triggered, all DCI messages indicate that the active BWP is 0. This can be verified by checking the bwp field included in the DCI entries in the lower layer log.

In this state, every transmitted DCI 1_1 shows the bwp field set to 0, which means that both scheduling and data transmission are occurring within BWP 0. This confirms that the UE is still operating on the initial bandwidth part before the switching procedure is initiated.

NR BWP Test3 Log 02

After the BWP switching is triggered, the active BWP changes to BWP 1. This can be verified by checking the bwp field in the DCI entries in the lower layer log.

In this state, the DCI messages indicate that the bwp field is set to 1. This means that the scheduling commands are now associated with BWP 1 and the UE is operating on the new bandwidth part. The change of the bwp value in the DCI entries confirms that the BWP switching procedure has successfully taken effect.

NR BWP Test3 Log 03

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.

In this configuration, the parameter bwp_switch_k0 is added inside the pdsch {} block. This parameter introduces a scheduling offset between the DCI transmission and the corresponding PDSCH transmission. The offset allows sufficient time for the UE to apply the BWP switch before the scheduled data transmission occurs. Although this parameter is mainly required when BWP switching is triggered through DCI 1_1, it is included here so that the same configuration file can be reused for both DCI 0_1 and DCI 1_1 based switching tests.

NR BWP Test4 Config 01

The second modification is to disable the bwp_dynamic_switch configuration that was used in Test 1. In this test the BWP switching is triggered directly by DCI signaling, so automatic throughput-based switching should not be active.

If the dynamic switching configuration remains enabled, the system may automatically switch the BWP again based on traffic conditions after the DCI-triggered switch. This could interfere with the intended test behavior. Therefore the bwp_dynamic_switch block should be commented out so that the BWP changes only when the DCI-based trigger is executed.

NR BWP Test4 Config 02

Start the Callbox and let the UE complete the attach procedure. After the UE enters the connected state, you can trigger the downlink BWP switch by sending the RemoteAPI command.

It is recommended to run a continuous ping after attach so that the UE remains in RRC Connected mode during the test. Then execute the dci_bwp_switch command with dl_bwp_id set to the target BWP. When the gNB receives this command, it initiates the DCI-based BWP switching procedure for downlink scheduling on the specified UE. (NOTE : I would recommend you to do continous ping after attach so that the call status remain in connected mode).

NR BWP Test4 RemoteAPI 01

Sample Log

The parameter bwp_switch_k0 modifies the pdsch-TimeDomainAllocationList that is broadcast as part of the cell configuration. When this parameter is applied, the value of k0 in the PDSCH time domain allocation entries becomes non-zero.

The k0 value defines the slot offset between the DCI scheduling command and the actual PDSCH transmission. By introducing this offset, the scheduler provides sufficient time for the UE to apply the BWP switch before the scheduled PDSCH transmission occurs. As a result, several entries in pdsch-ConfigCommon show non-zero k0 values in the configuration, reflecting the updated scheduling timing required for BWP switching.

NR BWP Test4 Log 01

Before the BWP switching is triggered, the active BWP remains BWP 0. This can be confirmed by checking the bwp field included in the DCI messages in the lower layer log.

In the log shown here, every transmitted DCI indicates that the bwp field is set to 0. This means that scheduling and data transmission are still occurring within BWP 0, confirming that the UE has not yet switched to the target BWP.

NR BWP Test4 Log 02

When the BWP switching command is received by the gNB, the scheduler triggers the switching procedure through the DCI mechanism. At the switching point, the gNB sends a DCI 1_1 message that includes the switching timing defined by the parameter bwp_switch_k0 in the configuration.

In the log shown here, the highlighted DCI entry indicates the moment when the switching command is applied. The DCI format used is DCI 1_1, and the k0 value included in the message is 6, which matches the configuration parameter bwp_switch_k0. This value specifies the delay in slots between the DCI scheduling command and the PDSCH transmission that will occur on the new BWP.

This means that the UE receives the DCI 1_1 scheduling command and prepares to switch the active BWP after the specified k0 delay. The highlighted log entry therefore marks the exact scheduling point where the BWP switching process begins.

NR BWP Test4 Log 03

After the BWP switching procedure is completed, the active bandwidth part becomes BWP 1. From this point onward, the scheduler generates DCI messages assuming that the UE is operating on BWP 1.

In the log shown here, all subsequent DCI entries indicate that the bwp field is set to 1. This confirms that both DCI 0_1 and DCI 1_1 are now referencing BWP 1 for uplink and downlink scheduling. The highlighted region shows the transition point, and after this moment every new scheduling command is associated with the new active BWP.

This behavior verifies that the BWP switching triggered by the DCI command has been successfully applied and that the UE is now operating on BWP 1.

NR BWP Test4 Log 04

RRC / NAS Signaling

SIB1 (SA)

: This is the SIB1 message sent by gNB  to configure NR SA. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

{

  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. (NOTE : You would see some IEs that has a specific assigned vale here, but consider it as just an example value. Those values should vary depending on test requirement)

  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:

NOTE : As of the release 2023-11-23, there is no explicit statement of the detailed procedure of RRC based BWP switching, but we tried to improve the process as shown in Test 2 based on our observation and assumption.

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.

NR Bwp Limitation UlBW 01

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

                        ra_type: "type0",

                    }

                }

            ],

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.

© 2025 All rights reserved | Legal notice |