NR SA FDD Asymetric Channel Bandwidth
The purpose of this tutorial is to show you how to set different channel bandwidth for downlink and uplink in NR SA. It is assumed that you don't have any previous experience with Amari callbox.
Asymetric Channel Bandwidth in this tutorial indicates the case where Bandwidth for DL and UL are different. In most cases, it is assumed that the bandwidth of DL and UL is same in most of the default configuration. I think we can think of two ways to configure DL bandwidth and UL bandwidth differently as listed below.
- Setting the number of RBs differently for DL and UL within initial BWP
- Setting a BWP (non-initial BWP) with different bandwidth for DL and UL and switch to the BWP
The first method is used in this tutorial.
Table of Contents
- NR SA FDD Asymetric Channel Bandwidth
Introduction
In 5G New Radio (NR) Standalone (SA) deployments, the flexibility to configure radio resources is a defining feature that enables operators to optimize network performance for diverse use cases. One such configurable aspect is the channel bandwidth allocation for downlink (DL) and uplink (UL), which can be independently set to accommodate asymmetric traffic demands. Traditionally, NR systems assume symmetric bandwidth allocation, where both DL and UL operate over identical bandwidths, simplifying network planning and resource management. However, real-world scenarios often necessitate differing bandwidths due to varying uplink and downlink traffic profiles—such as in applications with heavy downlink streaming and minimal uplink data. Architecturally, NR introduces the concept of Bandwidth Parts (BWPs), which allow for granular control over the bandwidth assigned to a User Equipment (UE) for both DL and UL. By configuring the number of Resource Blocks (RBs) within a BWP, operators can tailor the channel bandwidth for each link direction. This capability is particularly significant in the context of 5G’s flexible numerology and spectrum utilization, positioning asymmetric configurations as a powerful tool for optimizing spectrum efficiency. Within the broader 5G ecosystem, such flexibility supports diverse service requirements, enhances user experience, and enables efficient network slicing. The Amari Callbox, a versatile 5G test platform, provides the infrastructure necessary to experiment with and validate these advanced configurations in a controlled environment.
-
Context and Background
- 5G NR SA supports flexible radio resource management, including independent configuration of DL and UL channel bandwidths.
- Bandwidth Parts (BWPs) enable separation and dynamic allocation of resources, allowing for asymmetric bandwidth assignment tailored to application needs.
- Amari Callbox is a widely used 5G test solution that facilitates practical experimentation with NR features such as asymmetric channel bandwidth.
-
Relevance and Importance
- Asymmetric bandwidth allocation is crucial for optimizing spectral efficiency in scenarios with uneven uplink and downlink traffic demands.
- Understanding how to configure these parameters is essential for network engineers, testers, and researchers working with emerging 5G use cases and deployments.
- The tutorial addresses a common limitation in default configurations and demonstrates how to overcome it using a real-world test platform.
-
Tutorial Objectives
- Provide step-by-step guidance on setting different channel bandwidths for DL and UL in a 5G NR SA environment using Amari Callbox.
- Explain the underlying technical concepts—such as BWPs and RB allocation—that enable asymmetric channel bandwidth.
- Demonstrate practical configuration using the first method: setting the number of RBs differently for DL and UL within the initial BWP.
-
Expected Learning Outcomes
- Gain a foundational understanding of bandwidth configuration in 5G NR SA.
- Acquire hands-on experience with Amari Callbox for radio resource management tasks.
- Develop the ability to implement and validate asymmetric channel bandwidth configurations.
-
Prerequisite Knowledge or Skills
- Basic familiarity with 5G NR concepts and terminology (recommended but not required).
- No prior experience with Amari Callbox is assumed; the tutorial is designed for beginners.
- General understanding of wireless communication principles is helpful for contextualizing the concepts covered.
Summary of the Tutorial
This tutorial demonstrates the procedure to test an NR Standalone (SA) asymmetric channel bandwidth configuration using a UE simulator and callbox setup.
-
Test Setup:
- The test environment involves a callbox and a UE simulator (UEsim) connected as shown in the referenced diagram.
-
Key Configuration Parameters:
- n_rb_dl: Number of downlink resource blocks.
- n_rb_ul: Number of uplink resource blocks.
-
Configuration Procedure:
- Proper alignment of configuration between UE simulator and callbox is critical.
- Default configuration files (ue.default.cfg, enb.default.cfg) are used unless otherwise noted.
- For this test, ue-sa-fdd-asym.cfg and gnb-sa-fdd-asym.cfg are utilized. These are derived from their respective default standalone configuration files.
- gnb-sa-fdd-asym.cfg (callbox): Configured with asymmetric bandwidth — n_rb_dl (DL) set for 20 MHz channel bandwidth and n_rb_ul (UL) set for 10 MHz. NR_TDD is set to 0 for FDD operation.
- ue-sa-fdd-asym.cfg (UEsim): Only n_rb_dl is configured; UL bandwidth is obtained from SIB1 decoding. Bandwidth parameter is commented out to allow for asymmetric DL/UL. NR_TDD is set to 0 for FDD operation.
-
Test Execution Procedure:
- Verify cell configuration using the cell phy command on the callbox; confirm intended setup.
- Use the cells command to check if the UE simulator detects the cell. Once detected, power on the UE.
- Use the t command to verify that the UE connects to the cell and completes the attach procedure.
- Test data path connectivity by pinging the UE from the callbox. Successful ping replies confirm that both uplink and downlink communications are functional with the asymmetrical bandwidth configuration.
-
Log Analysis:
- Inspect logs to verify DL and UL bandwidths as indicated in the SIB1 message.
- Confirm the bandwidth values of both downlink and uplink via locationBandwidth in the initialDownlinkBWP and initialUplinkBWP sections of SIB1.
- Use external tools (e.g., RIV calculator) for interpreting resource block assignments.
- Check UE capability information to ensure support for configured bandwidths (via featureSetDownlinkPerCC and featureSetUplinkPerCC).
- Amarisoft internal logs can also confirm the NR band combination and resource block allocations.
- It is observed that the maximum Physical Resource Block (PRB) does not exceed the configured limits for both PDSCH (DL) and PUSCH (UL), matching the asymmetric configuration.
The overall methodology validates the ability of the UE and gNB (callbox) to establish, configure, and maintain asymmetric bandwidth operation in NR SA FDD mode, confirming both configuration and functional connectivity through stepwise verification and log analysis.
Test Setup
Test setup for this tutorial is as shown below.
The Callbox and the UEsim are connected by RF cables between their SDR cards. There is no over the air link in this test. The cable connection keeps the radio condition stable, so any change in the result comes from the DL and UL bandwidth settings.

Key Configuration Parameters
Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.
Configuration
An important thing in using UE sim is to do proper matching between UE sim configuration and Call box configuration In this tutorial, I used the ue.default.cfg and and enb.default.cfg without any change
If you use other Network (e.g, other network simulator or real network), you have to make it sure to configure UE sim according to the settings on network side
I used ue-sa-fdd-asym.cfg which is copied from ue-nr-sa.cfg.

I used gnb-sa-fdd-asym.cfg which is copied from gnb-sa.cfg.

The configuration in gnb-sa-fdd-asym.cfg (Callbox) is set as follows. The keypoint is that the nuber of RB for n_rb_dl and n_rb_ul are set to be different. NR_TDD is set to 0 since this is for FDD test. The important point in this configuration is that n_rb_dl and n_rb_ul are set differently. n_rb_dl (Downlink bandwidth) is set to the channel bandwidth of 20 Mhz and n_rb_ul (Uplink bandwidth) is set to the channel bandwidth of 10 Mhz
In nr_cell_default, the line bandwidth: NR_BANDWIDTH is commented out. The bandwidth parameter applies the same bandwidth to both DL and UL. According to the lteenb documentation, n_rb_dl is ignored if bandwidth is provided. So bandwidth has to be removed before n_rb_dl and n_rb_ul take effect.
n_rb_dl: 51 with 30 kHz subcarrier spacing is the 20 MHz channel bandwidth. n_rb_ul: 24 is used for the UL. n_rb_ul is optional, and if it is not set it takes the same value as n_rb_dl.
The cell uses band: 65 with dl_nr_arfcn: 431000, ssb_nr_arfcn: 430850 and ssb_subcarrier_spacing: 15. These are in the #else branch, which is used because NR_TDD is 0. subcarrier_spacing is 30. The #if TDD == 1 branch with band 77 is not used in this test. N_ANTENNA_DL is 2 and N_ANTENNA_UL is 1.

The configuration in ue-sa-fdd-asym.cfg (Callbox) is set as follows. In this configuration, you would notice that only n_rb_dl is configured. UL bandwidth will be detected from SIB1 decoding. NR_TDD is set to 0 since this is for FDD test. In this configuration, bandwidth parameter is commented out since the different bandwidth will be used for DL and UL. Only dl bandwidth is configured with n_rb_dl for UEsim to detect the cell and decode SIBs. UL bandwidth will be informed to UE by SIB1.
In the UE cell, //bandwidth: CELL_BANDWIDTH is commented out and n_rb_dl: 51 is set. That is the 20 MHz DL channel bandwidth with 30 kHz subcarrier spacing. In this release UEsim does not use an n_rb_ul parameter. It takes the UL bandwidth from SIB1.
The UE uses the same band: 65, dl_nr_arfcn: 431000, ssb_nr_arfcn: 430850 and ssb_subcarrier_spacing: 15 as the gNB. subcarrier_spacing is 30 and N_ANTENNA_DL is 2. TDD is 0, so the #if TDD == 1 branch is not used. If you change the frequency or the DL RB count on the gNB, change the same values here.

Perform the Test
Check out cell configuration with cell phy command and see if the cell is configured as intended. NOTE that there is no information showing the different BW for DL and UL.
cell phy shows cell 0x001 in NR band n65 with BW 20. The DL ARFCN is 431000 with 2 antennas and 2 layers. The UL ARFCN is 393000 with 1 antenna and 1 layer. SCS is 30 in both directions and the SSB ARFCN is 430850 with SCS 15. The BW column has a single value, so it cannot show the smaller UL bandwidth. This may be improved in a future release.
rf_info shows TX0 and TX1 at 90.0 dB gain on 2155.000000 MHz, and RX0 at 60.0 dB gain on 1965.000000 MHz. The cell command shows pci 500 and plmn 00101.

If the cell is properly configured. Check if the cell can be detected by UEsim. You can check the cell detection status with cells command. Once cell is properly detected, power on UE.
The cells command shows PCI 500, FDD, with EARFCN DL=431000 and UL=393000. The RB line shows DL=51 UL=51. Both values are the same, and they do not change even after the UE decodes SIB1. This may be corrected in a future release. The UL bandwidth actually used is the one in SIB1.
rf_info on the UE shows TX0 on 1965.000000 MHz and RX0 and RX1 on 2155.000000 MHz. These are the reverse of the gNB. After power_on, the UE reports Cell 0: SIB found.

Now check if UE gets connected to the cell properly. You can do this with t command. If UE properly completes the attach, check if the IP data can go through both uplink and downlink. The simplest way to do this is to ping the UE. If you get the ping reply, it indicates both DL and UL connection is properly established with asymatric bandwidth configured in this test.
In the t trace, PRACH comes in with snr=29.0 dB and the UE gets RNTI 4601. The mme ue command shows the UE registered on 5GC with IP_ADDR 192.168.2.2. ping 192.168.2.2 gets replies. The first reply takes 276 ms and the later ones take about 30 to 35 ms.
I recommend running LteSim_Server and sending high throughput data. The DL PHY/MAC then schedules the maximum number of RBs. In this run I used cbr send 192.168.2.2 100M 20. That makes the RB limit easy to check in the log analysis below.

Log Analysis
You can confirm on DL and UL bandwidth in SIB1 message.
Confirm DL Bandwidth in locationBandwidth in initialDownlinkBWP. The start RB and bandwidth is configured as RIV in RRC. If you want to convert this RIV to start RB and NRB, use this calculator.
In the SIB1 frequencyInfoDL, freqBandIndicatorNR is 65 and offsetToPointA is 36. The scs-SpecificCarrierList has subcarrierSpacing kHz30 and carrierBandwidth 51. This carrierBandwidth comes from n_rb_dl.
In initialDownlinkBWP, locationAndBandwidth is 13750 with subcarrierSpacing kHz30. With the RIV calculator this gives start RB 0 and 51 RBs. So the initial DL BWP covers the whole 20 MHz carrier.

Confirm DL Bandwidth in locationBandwidth in initialUplinkBWP. The start RB and bandwidth is configured as RIV in RRC. If you want to convert this RIV to start RB and NRB, use this calculator.
In the SIB1 frequencyInfoUL, freqBandIndicatorNR is 65 and absoluteFrequencyPointA is 392136. The scs-SpecificCarrierList has subcarrierSpacing kHz30 and carrierBandwidth 24. This carrierBandwidth comes from n_rb_ul.
In initialUplinkBWP, locationAndBandwidth is 6325 with subcarrierSpacing kHz30. With the RIV calculator this gives start RB 0 and 24 RBs. The DL has 51 RBs and the UL has 24 RBs, so the asymmetric bandwidth is signalled to the UE here.

check if your UE (DUT) support the bandwidth that you configured. You can check it out via featureSetDownlinkPerCC and featureSetUplinkPerCC in UE Capability Information message from the UE.
In featureSetsDownlinkPerCC, supportedBandwidthDL is fr1: mhz20 with supportedSubcarrierSpacingDL kHz30, twoLayers for PDSCH and qam256. This matches the 20 MHz DL set by n_rb_dl. The appliedFreqBandListFilter asks for bandNR 65.
In featureSetsUplinkPerCC, supportedBandwidthUL is also fr1: mhz20, with oneLayer for PUSCH and qam256. It does not follow n_rb_ul. That is a UEsim capability report and may be improved in a future release. A 20 MHz UL capability still covers the 24 RB UL used here.

The same information can be confirmed by Amarisoft Internal log NR band combination.
The bands entry is DL N65A + UL N65A. features_dl is MIMO 2, 20 MHz, SCS 30 kHz. features_ul is MIMO 1, 20 MHz, SCS 30 kHz. These match featureSetsDownlinkPerCC and featureSetsUplinkPerCC in the UE capability information.

You would notice that the max PRB does not go over 51st RB for PDSCH (Downlink transmission)
I filtered the log with Info PDSCH while the cbr traffic was running. The largest allocation is prb=0:51, which means start RB 0 and 51 RBs. That is the full 20 MHz DL. The other slots use smaller allocations such as prb=0:18, prb=34:17 and prb=47:4. They all stay inside RB 0 to 50. In this run the PDSCH uses nl=2 with tb_len=9737.

You would notice that the max PRB does not go over 24th RB for PUSCH (Uplink transmission)
I filtered the log with Info PUSCH. The allocations are small, for example prb=2:3, prb=2:4, prb=16:6, prb=17:5 and prb=18:4. The last RB used is RB 21, so the PUSCH stays inside the 24 UL RBs. The cbr traffic is in the DL, so the UL carries only small packets here. To fill more of the UL, you can generate UL traffic from the UE side.

RRC / NAS Signaling
This section lists the RRC IEs that carry the asymmetric bandwidth to the UE. In this test only SIB1 is needed, because the DL and UL carrier bandwidth and the initial BWPs are all broadcast there. The values match the SIB1 in the Log Analysis section: carrierBandwidth 51 and 24, and locationAndBandwidth 13750 and 6325.
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 24
}
},
p-Max 10
},
initialUplinkBWP {
genericParameters {
locationAndBandwidth 6325,
subcarrierSpacing kHz30
},
}