Out of the Box Test - NR NSA

The purpose of this tutorial is to show you how to establish NR NSA connectivitybetween a UE and Amari Callbox. It is assumed that you don't have any previous experience with Amari callbox.

SA stands for "Non-Stand Alone". "Non Stand Alone" in NR NSA implies a fewthings as below

• It support NR with help of other technology (e.g, LTE). In most common form of NSA called ENDC, NR is supported with the help of LTE. In this configuration, LTE plays a role as an anchor (MCG) which performs the initial attach and most of signaling and NR plays a role as secondary cell (SCG) which provides additional pipe for user traffic
• (In ENDC) NR Core is not supported and NR is directly/indirectly connected to LTE Core.

According to NR deployment options described in RP-161266, There are many different forms of NSA is defined in this document, but when we say 'NSA' as of now, it usually mean Option 3.x (i.e, Option 3 and/or Option 3a)(NOTE : The terminology of these option is not explicitely used in the 3GPP final TS, but the term (e.g, option 2), option 3.x) etc are widely used in the industry). In Amarisoft Callbox, the single core network named 'mme' support both LTE core network and NR core network.

In terms of the frequency and bands, Amarisoft Callbox (gNB) support all the frequencies and bands that are specified in 3GPP. In terms of bandwidth, Amarisoft Callbox (gNB) support any 3gpp defined band upto 100Mhz per component carrieras of now.

NOTE : What if NSA does not work ? Check out this troubleshoot guide to figure out the root cause of NSA setup failure.

Table of Contents

• Out of the Box Test - NR NSA
• Introduction
• Summary of the Tutorial
• Test Setup
• Key Configuration Parameters
• Test 1 : Basic NSA (Single LTE + Single NR)
• Configuration
• Check if LTE service is Running
• Perform the Test
• Log Analysis
• Generating Traffic
• Analysis in Screen during traffic test
• Traffic Analysis on WebGUI
• Test 2: 6LTE CA+ Single NR
• Configuration
• 1st LTE Cell
• 2nd LTE Cell
• 3rd LTE Cell
• 4th LTE Cell
• 5th LTE Cell
• 6th LTE Cell
• Common to All LTE Cell
• NRCell
• Perform the Test
• Log Analysis
• Test 3: 5 LTE CA(FDD + TDD)+ Single NR
• Configuration
• Global Parameters
• 1st LTE Cell
• 2nd LTE Cell
• 3rd LTE Cell
• 4th LTE Cell
• 5th LTE Cell
• NRCell
• Common to All LTE Cell
• Perform the Test
• Log Analysis
• RRC / NAS Signaling
• rrcConnectionReconfiguration for NR Addition
• Tips
• Changing Configuration File
• Troubleshoot
• Requirement for UE Capability Information
• Requirement for UE Network Capability
• Requirement for UE Capability Equniry
• Requirement for measurement request
• Requirement for NR addition
• Common Issues
• Uninteded Measurement Configuration
• Uninteded Measurement Event Configuration
• No Measurement Report
• SCG Failure

Introduction

The evolution of mobile network technology has led to the development of 5G New Radio (NR), which is designed to deliver significantly higher data rates, ultra-low latency, and enhanced connectivity compared to previous generations. One of the pivotal deployment strategies for 5G NR is the Non-Stand Alone (NSA) architecture, where 5G NR is integrated with existing LTE infrastructure to facilitate a smoother transition from LTE to full 5G Stand Alone (SA) networks. In NSA mode, LTE serves as the Master Cell Group (MCG), managing initial network attachment and control signaling, while NR operates as the Secondary Cell Group (SCG), supplementing data throughput and network capacity. This dual-connectivity approach, commonly referred to as E-UTRA NR Dual Connectivity (ENDC), enables operators to leverage their existing LTE core networks (EPC) while introducing NR capabilities. The Amarisoft Amari Callbox provides a comprehensive test and development platform for both LTE and NR, allowing users to emulate network elements such as the gNB (NR base station) and eNB (LTE base station), and manage both LTE and NR core network functionalities through a unified 'mme' core. This is particularly significant for research, validation, and troubleshooting in NR NSA deployments, as the Callbox supports all 3GPP-defined frequency bands and bandwidths up to 100 MHz per component carrier. Understanding and establishing NR NSA connectivity between a User Equipment (UE) and the Amari Callbox is essential for network engineers, researchers, and developers aiming to validate device interoperability, optimize network performance, and accelerate 5G adoption in real-world scenarios.

• Context and Background
  • 5G NR NSA Architecture: Integrates NR with LTE, enabling early 5G deployments by utilizing existing LTE infrastructure as the primary control and signaling anchor.
  • ENDC (E-UTRA NR Dual Connectivity): Allows simultaneous connection of a UE to both LTE (eNB) and NR (gNB) nodes, with LTE handling mobility and initial attachment, and NR boosting user data performance.
  • Amarisoft Amari Callbox: A flexible network emulation platform supporting both LTE and NR, with a unified core network component ('mme') for comprehensive NSA testing.
  • Industry Deployment Options: Focuses on Option 3.x (Option 3 and Option 3a), the most prevalent form of NSA as per 3GPP RP-161266, where NR is anchored by LTE and connected to the LTE core.
• Relevance and Importance of the Tutorial
  •   Enables users to establish and validate NR NSA connectivity in a controlled environment, which is critical for device certification, interoperability testing, and performance benchmarking.
  •   Provides hands-on experience with Amarisoft Amari Callbox, a widely used platform for R&D, prototyping, and troubleshooting in 4G/5G mobile networks.
  •   Facilitates understanding of dual connectivity mechanisms, network architecture, and signaling flows in NR NSA deployments.
• Learning Outcomes
  •   Gain practical knowledge of configuring and operating the Amari Callbox for NR NSA scenarios.
  •   Understand the roles of LTE and NR in NSA, including signaling, data transfer, and core network integration.
  •   Learn to troubleshoot common NSA setup failures using dedicated guides and Callbox diagnostic tools.
  •   Acquire insights into 3GPP deployment options and how they map to real-world test and deployment environments.
• Prerequisite Knowledge or Skills
  •   Basic understanding of mobile network concepts (LTE, NR, core network architecture).
  •   Familiarity with RF fundamentals and 3GPP specifications is helpful but not mandatory.
  •   No prior experience with the Amari Callbox is required, as the tutorial is designed for beginners.

Summary of the Tutorial

This tutorial covers three main NSA (Non-Standalone) test scenarios using Amarisoft Callbox, focusing on configuration, execution, and verification methodologies. The procedures are outlined for basic NSA operation, advanced carrier aggregation with NSA, and mixed FDD/TDD carrier aggregation with NSA. Key troubleshooting and configuration management steps are also provided.

• Test 1: Basic NSA (Single LTE + Single NR)
  • Test Setup: Use the default NSA configuration file (gnb-nsa.cfg) without modification. The SIM card provided with the system is utilized.
  • Configuration:
    • Set up enb.cfg as a symbolic link to gnb-nsa.cfg in the eNB/gNB configuration directory.
    • Ensure that ims.cfg and mme.cfg are correctly linked in the /root/mme/config directory.
  • Execution:
    • Restart the Callbox to apply configuration changes.
    • Verify LTE service is running using service lte status.
    • Access the system via screen -r to monitor and control network components.
    • Switch to the ENB component (Ctrl+A+1), verify RF and cell configuration with cell phy and cell main commands.
    • Start trace logging with the t command.
    • Power on UE and observe the attach and NSA establishment process. Stop trace with the Enter key.
    • Check UE connectivity and IP assignment using ue command in ENB and MME.
  • Log Analysis:
    • Analyze /tmp/gnb0.log for NSA setup, focusing on measurement report configuration, RRC messages, and RACH procedure for NR cell addition.
  • Traffic Generation and Analysis:
    • Generate IP traffic (e.g., browser-based speed test) after NSA establishment.
    • Monitor throughput and troubleshoot using t, t spl, and t cpu commands in the screen session.
    • Optionally, use WebGUI for detailed throughput and retransmission analysis.
• Test 2: 6 LTE Carrier Aggregation (CA) + Single NR
  • Test Setup: Requires hardware resources for 7 cells (ideally 7 SDR cards, or multiple cells per SDR if supported).
  • Configuration:
    • Use gnb-6LTE-1NR-nsa.cfg, based on gnb-nsa.cfg.
    • Configure six LTE cells (each mapped to a separate rf_port with unique dl_earfcn values) as Primary or Secondary Component Carriers (SCC).
    • Configure one NR cell as TDD, band n78, mapped to rf_port 6.
    • Ensure NR measurement configuration (Event B1) is present in all LTE cells to trigger NR addition based on UE measurement report.
  • Execution:
    • Verify all cell configurations using cell phy and cell commands.
    • Start trace logging with t command, attach UE, and monitor for NR cell addition.
  • Log Analysis:
    • Review UE capability enquiry and information messages to ensure support for desired LTE CA and NSA configurations.
    • Confirm that measurement objects and report configurations are present for all LTE and NR cells.
    • Verify sequence: measurement report from UE, RRCConnectionReconfiguration messages, NR cell addition as SCG, and successful NR RACH procedure.
• Test 3: 5 LTE CA (FDD + TDD Mix) + Single NR
  • Test Setup: Requires hardware for 6 cells (6 SDR cards or multi-cell per SDR where feasible).
  • Configuration:
    • Use gnb-cc-mix_TDD_FDD-nsa.cfg, based on gnb-nsa.cfg.
    • Configure five LTE cells with a mix of FDD and TDD duplex modes, each mapped to a unique rf_port and dl_earfcn.
    • Apply TDD-specific parameters (uldl_config, sp_config, tdd_ack_nack_feedback_mode) for TDD cells.
    • Configure NR cell as TDD, band n78.
    • Set common parameters for all LTE cells, including periodic CSI reporting, TM3, and Measurement Report (B1) for NSA initiation.
  • Execution:
    • Verify all cell configurations with cell phy and cell commands.
    • Attach UE, start trace logging, and wait for NR cell addition.
  • Log Analysis:
    • Check UE capability enquiry and information for LTE CA and NSA band support.
    • Confirm configuration of measurement objects and report configurations for all involved bands.
    • Verify the sequence of measurement reports, RRCConnectionReconfiguration, NR cell addition, and completion of NR RACH procedure.
    • Ensure traffic flows and CSI reports are received for both LTE and NR as configured.
  • RRC/NAS Signaling:
    • Examine the structure of key RRC messages, especially rrcConnectionReconfiguration for NR addition.

Configuration File Management: Copy existing configuration files as templates for new tests, modify as required, and set symbolic links accordingly. Avoid modifying default files directly.

Troubleshooting Guidelines:

• Ensure UE supports the required NSA band combinations and DCNR.
• Verify correct measurement and report configuration in RRC messages.
• Check physical connections, gain settings, and UE logs if measurement reports are missing.
• Analyze SCG Failure messages for root cause analysis if NSA setup fails after RRC procedures.

This summary encapsulates the end-to-end procedures for NSA testing from configuration to troubleshooting, with emphasis on command-line interaction, RAN-side verification, capability checks, and log analysis.

Test Setup

Test setup for this tutorial is as shown below.

• Since this test is for Out of the box testing, I used the default nsaconfiguration(gnb-nsa.cfg) file without changing anything in it
• 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 Guidewould help

Key Configuration Parameters

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

• cell_list
• en_dc_scg_cell_list
• en_dc_support
• cell_default
• nr_cell_list
• band
• dl_nr_arfcn
• subcarrier_spacing
• ssb_pos_bitmap
• nr_cell_default
• bandwidth
• n_antenna_dl
• n_antenna_ul
• tdd_ul_dl_config
• ssb_period
• meas_config_desc : In this link you will get the descriptions for all the items listed below
• a1_report_type
• a1_rsrp
• a1_hysteresis
• a1_time_to_trigger
• a2_report_type
• a2_rsrp
• a2_hysteresis
• a2_time_to_trigger
• a3_report_type
• a3_offset
• a3_hysteresis
• a3_time_to_trigger
• rsrp_filter_coeff
• nr_b1_report_type
• nr_b1_rsrp
• nr_b1_hysteresis
• nr_b1_time_to_trigger
• nr_rsrp_filter_coeff
• meas_gap_config

Test 1 : Basic NSA (Single LTE + Single NR)

This is the simplest and the most basic test for NSA which involves only one LTE Cell and only one NR Cell. The main purpose is to introduce basic operation with default sample configuration.

This test configures one eNB LTE cell and one gNB NR cell to form the simplest NSA setup. The eNB acts as the master node and provides the initial access and control signaling. The UE first camps on LTE, performs attach, and establishes the RRC connection through the eNB. Then the eNB adds the NR cell as a secondary node using EN-DC procedure. This allows the UE to receive additional data throughput from NR while maintaining control on LTE. The configuration uses default parameters, so it is mainly used to verify basic connectivity, SIB broadcasting, EN-DC addition, and dual connectivity data flow. This test is typically used as the first validation step before moving to more complex multi-cell or multi-band NSA scenarios.

Configuration

By default, Amari Callbox uses enb.cfg for eNB/gNB configuration. This default configuration is configured for LTE band 3, band 4. If you want to use the call box for other RAT (Radio Access Technology) like 5G or other LTE bands (i.e, bands other than band 3, 7), you need to change the configuration.

In this step, you switch the configuration used by eNB/gNB without modifying the internal parameters. The system is already designed to load the configuration through a symbolic link, so you just change where that link points. First, move to the configuration directory where the enb.cfg link exists. Then update the symbolic link so that enb.cfg points to gnb-nsa.cfg. This makes the system load the NSA configuration instead of the default LTE-only setup. As a result, when the service is restarted, the node starts with NSA capability using the new configuration file. This approach is useful for quick testing because it avoids editing multiple parameters and allows fast switching between different predefined configurations.

Go to eNB/gNB configuration directory

change the symbolic link so that enb.cfg points to { enb.cfg -> gnb-nsa.cfg }using command : ln -sf gnb-nsa.cfg enb.cfg

After updating the symbolic link, you can verify the change by listing the configuration files in the directory. The output shows that enb.cfg is no longer a regular file but a symbolic link pointing to gnb-nsa.cfg. This confirms that the system will now use the NSA configuration when loading the eNB/gNB settings. If you need more detailed customization, you can directly modify the target configuration file instead of just switching the link. This step ensures that the configuration change is correctly applied before restarting the service and proceeding with the test.

Now you should see the enb.cfg is linked to gnb-nsa.cfg as shown below. (NOTE : If you want to change the contents of configuration file as per your own test requirement, refer to Tips : Changing Configuration File)

Now move to the MME configuration directory. In this directory, the system uses the same symbolic link mechanism as in eNB/gNB. The file mme.cfg is not an actual configuration file but a link that points to mme-ims.cfg. This means the MME will run with IMS-related configuration enabled.

By checking the file list, you confirm that both ims.cfg and mme.cfg are linked to their respective target files. This indicates that IMS functionality is already integrated into the setup. As a result, when the MME starts, it loads the IMS-capable configuration, allowing the UE to proceed with IMS registration and related procedures after attach.

This step ensures that the core network side is aligned with the NSA setup, so both radio and core configurations are consistent before running the test.

In short, just go to the directory /root/mme/config. You should see the configuration files as below.

NOTE :If ims.cfg and mme.cfg is not linked to the files as shown above, you may run following commands to make proper link. By doing this, you can manually correct them by recreating the links. The command ln -sf forces the link to be updated even if it already exists. First, link ims.cfg to ims.default.cfg so that the IMS configuration is properly referenced. Then link mme.cfg to mme-ims.cfg so that the MME loads the IMS-enabled configuration. After running these commands, the configuration structure becomes consistent with the expected setup, ensuring that both IMS and MME components operate with the correct configuration during the test.

Restart the callbox so that the new configuration file is applied.  The service restart triggers the system to re-read all configuration files, including the updated symbolic links for eNB/gNB and MME. During this process, the LTE service is stopped and started again through systemctl, and the new NSA and IMS configurations are applied. Once the restart is complete, the system is ready to operate with the updated setup, and you can proceed with UE connection and test validation.

Check if LTE service is Running

Whatever you want to test, the first thing you need to do is that call box program (LTE Service) is running. You can check on the execution status of the call box program by running following command and you should get the result as shown below.

Run the status command, which internally calls systemctl to check the state of the lte.service. The output should show that the service is loaded and active. The key indication is the state active (running), which means the Callbox software is operating normally. You can also see the main process ID, resource usage, and the execution path of the startup script. This step verifies that the system has successfully applied the new configuration and is ready for UE connection and further testing.

# service lte status

NOTE :This status check is only the first validation step. It confirms that the Callbox process has started and is currently running, but it does not guarantee that every internal function is operating correctly. There can still be problems in radio setup, configuration details, network connection, or signaling flow even when the service state looks normal. If you observe unexpected behavior during the test, restarting the LTE service is a common first recovery step. This reloads the program and configuration again and often helps clear temporary issues before deeper troubleshooting.

# service lte restart

Perform the Test

Once the LTE service is confirmed to be running, move into screen mode to interact with the Callbox process. The Callbox typically runs inside a screen session, so attaching to it allows you to monitor logs and control the system in real time. By running screen -r, you attach to an existing detached session. This brings you into the live console where the LTE and NR processes are running.

In most test scenarios, this step is essential because many operations, logs, and runtime messages are only visible inside the screen session. You can observe signaling flow, error messages, and system behavior directly. While some documents mention screen -x, which allows multiple simultaneous attachments, screen -r is commonly used to resume a single detached session and is sufficient for most cases.

This step prepares you for the next stages of testing, where you monitor UE attach, EN-DC setup, and overall system behavior from the live console environment.

For further commands you can use in this screen mode, refer to the tutorial : Command Line Command

First open the screen window with the 'screen' command. (NOTE : You might have seen 'screen -x' in other documents. 'screen -x' mean 'simultaneous screen attach, 'screen -r' mean 'resume attach (attatch to the detached screen)' There are slight difference between them but in most case you would have same result. You may google or ask AI for further details if you are interested)

When you enter the screen session, you see multiple windows representing each network component running inside the Callbox. Each component such as MME, ENB, IMS, and MBMSGW is assigned a number. This means each component is running in its own screen window, and you can switch between them easily.

To move between these components, use the Ctrl+A command followed by the window number. First press Ctrl+A, then release and press the number key. For example, Ctrl+A then 0 switches to the MME window, Ctrl+A then 1 switches to the ENB window, and other numbers correspond to IMS and MBMSGW. The currently selected window is typically highlighted, so you always know which component you are interacting with.

This mechanism allows you to monitor logs and execute commands for each network element independently within a single terminal session. It is especially useful during testing because you can quickly switch between MME signaling, eNB radio behavior, and IMS procedures without leaving the screen environment.

Putting it in short, with Ctrl+A and the number before the component name, you can switch to command line window for the specific component. For example, if you press Ctrl+A+1, the command line window switches to ENB and if you press Ctrl+A+0, the command line window switches to MME and so on.

Switch to [ENB] by pressing { Ctrl + A + 1 }.

Once you enter the ENB screen, you immediately see RF configuration information without running any command. This output shows key parameters such as sample rate, downlink frequency, uplink frequency, operating band, and antenna configuration for both LTE and NR.

This information gives a quick validation of how the radio is configured. For example, you can confirm that LTE is running on a specific band and frequency, and NR is configured on another band such as n78. You can also verify the number of antennas used for downlink and uplink. This step is important because it allows you to check whether the system RF setup matches your test intention before proceeding further.

If the configured band or frequency does not match what your UE supports, the UE will not be able to detect or connect to the cell. In that case, you need to modify the configuration file accordingly. This quick check helps prevent unnecessary troubleshooting later by ensuring that the RF parameters are correctly aligned with the DUT capability from the beginning.

To verify the detailed cell configuration, run the command cell phy in the ENB window. This command displays the physical layer configuration of all configured cells in the system. It shows key parameters such as RAT type, operating band, bandwidth, ARFCN, and subcarrier spacing for both downlink and uplink.

From this output, you can clearly see that one cell is configured as LTE and another as NR. For each cell, the table provides frequency-related information along with antenna settings and SCS. This allows you to confirm that the LTE cell and NR cell are configured as intended for NSA operation.

This step is important because it gives a structured view of the actual cell configuration being used by the system, not just the raw RF parameters. By checking RAT, BAND, BW, ARFCN, and SCS, you can ensure that the setup matches your test plan and that the UE will be able to properly detect and operate with the configured cells.

If you run cell main or simply cell, you can see additional configuration details that are not included in cell phy. This output focuses more on system-level identifiers and operational parameters rather than pure physical layer settings.

In this view, you can check values such as PCI, TAC, PLMN, and downlink gain. The LTE cell shows full information including TAC and PLMN, which are essential for UE registration and tracking area identification. The NR cell also shows its PCI and frequency-related information, but some fields like TAC may not be present depending on how NSA is configured.

This step provides a higher-layer perspective of the cell configuration. It helps you verify that the identity and access-related parameters are correctly set, which is critical for UE attach and mobility procedures. By combining this with the cell phy output, you get a complete understanding of both RF-level and system-level configuration before proceeding with the test.

To monitor detailed signaling and internal behavior, start trace logging by running the t command in the ENB window. Once this command is executed, the system begins printing real-time trace logs directly on the screen. These logs include various protocol messages, RF activities, and internal processing steps.

The trace continues to run continuously, allowing you to observe events such as UE detection, RRC signaling, and EN-DC procedures as they happen. If needed, you can stop the trace by pressing the return key. This feature is essential during testing because it provides immediate visibility into how the system behaves and helps you quickly identify issues during UE attach or data transfer.

Power On UE and let it complete the attach and NSA establishment. You would get trace as shown below. (NOTE : If you don't see PRACH to cell=02, it mean NSA establish failed and you need to check the log to find out the root cause)

The UE first performs initial access on the LTE cell. In the trace, this appears as PRACH to cell 01, which indicates that the UE is attempting random access to the LTE cell for initial attach. This is expected because LTE acts as the master node in NSA.

Once LTE attach is completed, the system proceeds with NSA establishment. At this stage, you should see another PRACH event to cell 02. This indicates that the UE is now performing random access to the NR cell as part of EN-DC setup. This is a key indicator that NSA is successfully being established.

In the trace, you will also notice two different cell IDs. Cell 01 corresponds to the LTE cell, and cell 02 corresponds to the NR cell. This dual presence confirms that both LTE and NR are active and the UE is operating in dual connectivity mode.

If you do not see PRACH to cell 02, it means that the NR addition step has failed. In that case, you need to analyze the trace logs to identify the issue, which could be related to RF configuration, UE capability mismatch, or signaling failure during EN-DC setup.

When you are done observing the trace, press the [Enter] key to stop the logging. The system then exits the continuous trace mode and returns to the ENB command prompt. This step is necessary because while the trace is running, the terminal is occupied and you cannot execute other commands.

Once you return to the prompt, you can run additional commands for further verification or troubleshooting. This allows you to switch between monitoring mode and command execution mode as needed during the test.

While the UE is in connected state, you can check the connection information using the ue command in the ENB window. This command shows the list of active UEs along with identifiers such as RAN UE ID, CN UE ID, serving cell, and RNTI.

From the output, you can see that the UE is associated with both LTE and NR cells. The LTE cell appears as the primary cell, and the NR cell appears as the secondary cell for NSA operation. This confirms that dual connectivity is successfully established.

If the UE is in idle state, this command will not show any entry because there is no active RRC connection. Therefore, this step is useful to verify that the UE is properly connected and that NSA is active at the system level.

You can also check UE connection information from the MME side using the ue command in the MME window. This command provides core network level information after the UE completes the attach procedure.

The output includes identifiers such as SUPI, IMEISV, and temporary IDs like M-TMSI or 5G-TMSI. It also shows the registration status and TAC, confirming that the UE is properly registered in the core network. One of the most important pieces of information here is the IP address assigned to the UE. This indicates that the default bearer has been successfully established and the UE is ready for data communication.

This step verifies that the attach procedure is fully completed from the core network perspective. Combined with the ENB ue command, it confirms both radio connection and core network connectivity, ensuring that the overall system is operating correctly.

Log Analysis

sample log-r20230215(b1-n41)

sample log-r20230215(b1-n78)

sample log-r20211014(b1-n78)

In this section, you will see how to confirm if UE is established with NSA. I will skip the initial registration part and focus only on NSA setup. Refer to the tutorial OutOfBox Test LTE if you are not familiar with the log for initial attach

NOTE : This section is just to check quickly some important points in the log, but it may be a little bit tricky to do the detailed log analysis (especially for lower layer log analysis). In that case, I strongly recommend you to use WebGUI for the log analysis. You may refer to WebGUI Tutorial

Open the gNB log file in the /tmp directory using a text editor such as nano. At the beginning of the log, you can see high level configuration information that the system prints when it starts. This includes details such as software version, RF configuration, cell parameters, bandwidth, ARFCN, PCI, and various physical layer settings.

This section acts as a summary of how the gNB is configured at runtime. It allows you to quickly verify key parameters without going back to the configuration file. For example, you can confirm operating mode, duplex type, resource block settings, PRACH configuration, and throughput limits.

This information is very useful for troubleshooting because it reflects the actual configuration applied by the system. By checking this section, you can ensure that the system started with the expected parameters and quickly detect any mismatch between intended configuration and actual runtime behavior.

Check out this tutorial to the details on this meta data.

After the LTE attach is completed, the eNB sends an RRCConnectionReconfiguration message to configure measurement for the NR cell. In the log, you can see that the message includes measObjectNR, which indicates that LTE is instructing the UE to start measuring the NR frequency. This is a key step for NSA because the UE needs to evaluate the NR cell before it can be added as a secondary node.

This message contains parameters such as NR carrier frequency, SSB configuration, and subcarrier spacing. These parameters tell the UE how to search and measure the NR signal. Once the UE receives this configuration, it starts measuring the NR cell and prepares to report the measurement results back to the eNB.

If this message is not observed in the log, it usually means that NSA cannot proceed. This can happen if the UE does not report NR capability during capability exchange, or if the configured band combination is not supported by the UE. In such cases, the eNB will not attempt to configure NR measurement, and EN-DC setup will not be triggered.

After the eNB sends the measurement configuration, the UE evaluates the NR cell and reports the result back using a Measurement Report message. In the log, you can see measResultNeighCells with NR-specific fields, which indicates that the UE has detected the NR cell and is reporting its signal quality.

This report includes parameters such as PCI, RSRP, RSRQ, and SINR for the NR cell. These values allow the eNB to decide whether the NR cell is suitable to be added as a secondary node. This step is essential because NSA addition is triggered based on this measurement feedback from the UE.

If this measurement report is not received, the eNB cannot proceed with NR addition. Even if the NR cell is configured correctly, NSA will fail if the UE does not report the NR measurement. This typically happens when the UE does not support the configured LTE-NR band combination or fails to detect the NR signal due to RF issues. This is one of the most common cause for NSA failure.

Once the measurement report from the UE is received, the eNB proceeds with NR addition by sending another RRCConnectionReconfiguration message. This message contains the configuration required to establish the NR secondary cell and complete the EN-DC setup.

In this message, you can see the NR specific configuration under nr-Config and secondaryCellGroup. This part defines how the NR cell should be added, including parameters for radio bearers, RLC configuration, and overall secondary cell group setup. It essentially provides all the information the UE needs to activate the NR connection alongside the existing LTE connection.

This step is the key transition point where the system moves from LTE-only operation to dual connectivity. Once the UE successfully processes this configuration, it establishes the NR link and starts using both LTE and NR simultaneously for data transfer.

If this message is not observed even after receiving the measurement report, it indicates that the decision to add NR has not been triggered. This could be due to configuration issues, policy settings, or thresholds not being met for NR addition.

After the UE receives the RrcConnectionReconfiguration message and successfully applies the configuration, it sends back RrcConnectionReconfigurationComplete. This message confirms that the UE has accepted the NR configuration and completed the setup of the secondary cell.

In the log, this message is a clear indication that the EN-DC procedure has been successfully executed from the UE side. It means the UE has configured the NR stack, activated the secondary cell group, and is now ready to use NR together with LTE.

If the UE cannot accept the configuration, it will not send this message. Instead, it may trigger a re-establishment procedure or indicate a failure. Therefore, the presence of RrcConnectionReconfigurationComplete is a key checkpoint confirming that NSA setup is completed successfully and the UE is operating in dual connectivity mode.

After the UE accepts the NR configuration, it performs the RACH procedure on the NR cell to establish the actual radio link. This is a standard 5-step random access procedure, but in this case it happens on the NR cell as part of NSA addition.

UE sends PRACH preamble to NR cell to initiate access. This is Msg1 and you can see PRACH with cell 02 in the log. This indicates that the UE is attempting to access the NR cell.

gNB responds with Random Access Response. This is Msg2 and includes timing advance and uplink grant. This allows the UE to align timing and prepare uplink transmission.

UE sends scheduled message using the granted resources. This is Msg3 and typically carries RRC related information or control signaling needed to continue the procedure.

gNB sends contention resolution message. This is Msg4 and confirms that the UE is successfully identified and the access procedure is progressing correctly.

UE sends final confirmation. This is Msg5 which completes the random access procedure and finalizes the connection to the NR cell.

If all these steps are completed successfully, the NR link is fully established and the UE can start transmitting and receiving data over NR along with LTE. If any of these steps fail, the NR addition does not complete and NSA establishment fails.

Generating Traffic

Once NSA is successfully established and the UE is in connected state, you can generate IP traffic to verify data connectivity and throughput. In this basic test, you can simply open a browser on the UE and run an internet speed test. This creates downlink and uplink traffic, allowing you to observe how LTE and NR work together for data transfer.

During this step, the UE utilizes dual connectivity, where LTE provides control and part of the data, and NR contributes additional throughput. By observing the speed test results, you can get a practical indication of system performance and confirm that the NR link is actively contributing to data transmission.

This step is mainly for validation and demonstration. It shows that the entire procedure from attach to NSA establishment is completed successfully and that the system is capable of delivering real user data over the combined LTE and NR links.

Analysis in Screen during traffic test

During the traffic test, you can monitor system behavior directly in the ENB screen using the t command. This provides real time statistics for each UE and each serving cell. The output shows both downlink and uplink information including CQI, MCS, retransmission count, SNR, and most importantly the bitrate.

For quick validation, the brate column is the most useful indicator. It shows the actual throughput currently achieved for downlink and uplink. When NSA is working properly, you will typically see higher throughput and activity on both LTE and NR cells. You can also observe that different cell IDs are contributing to the data flow, which confirms dual connectivity operation.

This view is very useful for troubleshooting. If throughput is low or unstable, you can correlate it with CQI, MCS, or retransmissions to identify radio issues. If one of the cells shows no activity, it may indicate that NSA is not properly configured or that the NR link is not contributing.

By continuously monitoring this screen during traffic generation, you can quickly verify performance and detect issues without needing deeper log analysis.. Refer to Command Line command tutorial for the various command line command you can use.

With t command, you can check various things. For the quick check on connectivity, just checking the throughput indicated by 'brate' columnwould be good enough. For further details on how to interpret this and how to use the information for troubleshooting, check out this tutorial.

If you suspect power related issues, you can run the t spl command in the ENB window. This command shows detailed TX and RX power levels for each RF path in real time. It provides values such as RMS and peak power for transmit and receive chains, along with dBFS measurements.

This information helps you understand whether the signal levels are within a reasonable range. For example, if RX power is too low, the UE may not properly detect the signal. If TX power is too high or distorted, it may cause signal quality issues or unexpected behavior. By checking both TX and RX levels, you can quickly identify problems related to gain settings, attenuation, or RF connection.

This command is especially useful when troubleshooting issues like poor throughput, unstable connection, or failure in cell detection. It gives direct visibility into the RF signal condition, which is often the root cause of many problems in wireless testing.

For further details on how to interpret this and how to use the information for troubleshooting, check out this tutorial.

If you suspect performance related issues such as timing mismatch or processing overload, run the t cpu command in the ENB window. This command shows CPU usage for different processing threads along with timing information between TX and RX operations.

The output provides per-process CPU utilization and processing rate, as well as timing statistics such as min, average, and max TX/RX delay with variation. These values indicate how consistently the system is processing real-time radio tasks. If the timing variation becomes large or the delay exceeds expected limits, it may lead to issues such as overflow, missed deadlines, or degraded performance.

This command is especially useful when you see symptoms like unstable throughput, dropped packets, or explicit overflow warnings in the log. By checking CPU load and timing stability, you can determine whether the system has sufficient processing capacity and whether real-time constraints are being met.

For further details on how to interpret this and how to use the information for troubleshooting, check out this tutorial.

Traffic Analysis on WebGUI

This section introduces an optional way to analyze traffic using WebGUI. Once NSA is established and traffic is running, you can use the WebGUI interface to visualize system behavior and performance in a more intuitive way.

Through WebGUI, you can monitor metrics such as throughput, resource utilization, scheduling behavior, and radio conditions over time. This provides a higher level view compared to the command line, making it easier to identify trends or performance issues during long running tests.

The specific analysis depends on your test objective. For basic validation, checking throughput and UE activity is usually sufficient. For deeper analysis, you may look into resource allocation, link adaptation, or error statistics. This step complements the screen-based analysis and helps you better understand overall system performance. (NOTE : If you are not familiar with how to setup and use WebGUI, refer to the tutorial : WebGUI. )

In WebGUI, one of the first things to check is the throughput plot. After selecting the ENB section, go to the Bitrate tab to open the throughput graph. This view shows real time data rate for each cell and the overall throughput.

The graph typically displays separate curves for LTE cell, NR cell, and total bitrate. By observing these curves, you can confirm whether NR is actively contributing to the traffic. In a proper NSA setup, you will see that the total throughput increases when both LTE and NR are active, and each cell contributes its portion to the overall data rate.

This visualization helps you quickly understand traffic behavior over time. You can see patterns such as burst transmission, steady throughput, or drops in performance. It is especially useful for verifying that dual connectivity is working as expected and that NR is not idle during data transfer.

In newer versions of WebGUI, the workflow is slightly different. Instead of directly seeing the plot, you first click the Analysis button. This opens the analysis window where various statistics and visualization tools are available.

From this window, select the Throughput tab to view the throughput graph. This plot shows the data rate over time for different layers such as PHY, MAC, and IP. It allows you to observe how traffic flows through the protocol stack and how efficiently data is being transmitted.

This view provides more detailed insight compared to the basic bitrate plot. You can analyze not only the overall throughput but also how each layer contributes to the transmission. This is useful for deeper performance analysis and for identifying bottlenecks within the protocol stack during traffic tests.

In WebGUI, you can also analyze retransmission behavior by selecting the TX RETX tab. This plot shows the number of retransmitted packets over time, which reflects how many transmissions failed at the receiver and had to be sent again.

Retransmissions are usually caused by poor radio conditions such as low SINR, interference, or incorrect configuration. When the link quality is good, the retransmission count should be low. If you see frequent or high spikes in this plot, it indicates that many packets are not being decoded correctly and require retransmission.

This view is useful for diagnosing performance issues. High retransmission rates often lead to reduced throughput and increased latency. By correlating this plot with throughput and radio metrics, you can identify whether performance degradation is due to RF conditions or other system issues.

In addition to these plots mentioned above, there are various additional analysis features are supported by WebGUI. If you want to know more about all other features of WebGUI, check out this tutorial.

Test 2: 6LTE CA+ Single NR

This is a kind of advanced test of NSA and I assume that the readers are already familiar with basic operations and overall verification procedures explained in Test 1. With that assumption, I would mainly focus on RAN side configuration and verification only. You can follow the procedure in Test 1 for user traffic.

NOTE : This test involves many cells. 7 cells in total. Before you try this, first make it sure that you have enough hardware resources (i.e, enough number of SDR card and PC performance).

• The best option is that you have 7 sdr cards.
• If you don't have enough number of sdr cards, you may put multiple cells in one sdr card if the requency and RAT requirement is met as mentioned in this tutorial.

Configuration

The configuration for this test is gnb-6LTE-1NR-nsa.cfg which is cbased on gnb-nsa.cfg. It may look complicated but it is just repetition of the same structure with minor modifications.

Following is the configurations for 6 LTE cells.

1st LTE Cell

This section describes how the first LTE cell is configured and how it acts as the anchor for NSA operation. The first LTE cell is mapped to RF port 0 and operates in FDD mode. The downlink frequency is defined by dl_earfcn, which is set to 300 in this example. This cell is the primary cell that provides initial access, control signaling, and acts as the master node in EN-DC.

The cell_id identifies this LTE cell uniquely, and TAC defines the tracking area used during attach. The root_sequence_index is used for PRACH configuration, and it is recommended to use different values across cells to avoid collision during random access.

Within the same configuration, additional LTE cells are listed under scell_list. These cells are configured as secondary component carriers for carrier aggregation. They are not used for initial access but can be activated later to increase throughput.

Finally, the en_dc_scg_cell_list specifies the NR cell that will be added as the secondary cell group. This is the NR cell used for NSA operation. Once the UE completes LTE attach and meets the conditions, this NR cell is added to provide additional data capacity.

Overall, this configuration defines the LTE anchor cell, optional LTE secondary carriers for CA, and the NR cell for dual connectivity, forming the complete NSA setup.

In short, 1st LTE cell is mapped to rf_port 0 and configured for FDD. dl_earfcn is set to 300. 5 LTE cells (cell id 2,3,4,5,6) are configured as SCC (Secondary Component Carrier) and one NR cell (cell id 7) is configured as SCG(Secondary Cell Group).

2nd LTE Cell

This section defines the 2nd LTE cell that can be used as another anchor or component carrier in the multi-cell configuration. This cell is mapped to rf_port 1, so it uses a different RF chain from the 1st LTE cell. It is configured in FDD mode, and dl_earfcn is set to 1476. This determines the downlink frequency of the 2nd LTE cell.

The cell is identified by n_id_cell 2 and cell_id 0x02. TAC is set to 0x0001, which means it belongs to the same tracking area as the other LTE cells in this example. The root_sequence_index is configured separately, and this is important because each LTE cell should preferably use a different PRACH root sequence to avoid random access conflict between cells.

The scell_list includes the other LTE cells as candidates for SCC. This means the 2nd LTE cell can work together with the other LTE cells for carrier aggregation. In this setup, cell 1, 3, 4, 5, and 6 are listed as secondary component carrier candidates associated with this cell.

The en_dc_scg_cell_list defines the NR cell to be added as SCG for NSA. In this example, NR cell 0x07 is linked to the 2nd LTE cell as the secondary cell group candidate. This means that once the UE attaches on this LTE cell and the NSA conditions are satisfied, the network can add NR cell 7 for dual connectivity.

Overall, this configuration makes the 2nd LTE cell another LTE serving cell with its own RF port and frequency, while also allowing LTE carrier aggregation and NR addition for NSA operation.

In short, 2nd LTE cell is mapped to rf_port 1and configured for FDD. dl_earfcn is set to 1476. 5 LTE cells (cell id 1,3,4,5,6) are configured as SCC (Secondary Component Carrier) and one NR cell (cell id 7) is configured as SCG(Secondary Cell Group).

3rd LTE Cell

This section defines the 3rd LTE cell as another component in the multi-cell carrier aggregation setup. This cell is mapped to rf_port 2, meaning it uses a separate RF chain from the previous LTE cells. It is configured in FDD mode, and dl_earfcn is set to 1674, which determines the operating downlink frequency for this cell.

The cell identity is defined by n_id_cell 3 and cell_id 0x03. TAC is set to 0x0001, so it belongs to the same tracking area as the other LTE cells. The root_sequence_index is configured as 202, and it is important to assign a different value from other cells to avoid PRACH collision during random access.

The scell_list defines the LTE cells that can be aggregated with this cell. In this case, cells 1, 2, 4, 5, and 6 are listed as SCC candidates. This means the 3rd LTE cell can operate either as a PCell or SCell depending on scheduling, and it supports LTE carrier aggregation with the listed cells.

The en_dc_scg_cell_list specifies the NR cell to be added for NSA dual connectivity. Here, NR cell 0x07 is configured as the SCG candidate. When NSA conditions are met, the UE connected to this LTE cell can be configured to add NR cell 7 as the secondary cell group.

Overall, this configuration sets up the 3rd LTE cell as an additional LTE carrier with its own frequency and RF port, while enabling both LTE carrier aggregation and LTE-NR dual connectivity within the same deployment.

In short, 3rd LTE cell is mapped to rf_port 2and configured for FDD. dl_earfcn is set to 1674. 5 LTE cells (cell id 1,2,4,5,6) are configured as SCC (Secondary Component Carrier) and one NR cell (cell id 7) is configured as SCG(Secondary Cell Group).

4th LTE Cell

This section defines the 4th LTE cell as another carrier in the aggregation setup. This cell is mapped to rf_port 3, so it uses a separate RF chain from the previous LTE cells. It is configured in FDD mode, and dl_earfcn is set to 3001, which determines the downlink frequency for this cell.

The cell identity is defined by n_id_cell 4 and cell_id 0x04. TAC is set to 0x0001, meaning it belongs to the same tracking area as the other LTE cells. The root_sequence_index is configured as 156. This parameter should be different across cells to reduce PRACH collision probability during random access.

The scell_list includes LTE cells 1, 2, 3, 5, and 6 as SCC candidates. This means the 4th LTE cell can participate in carrier aggregation with all the other LTE carriers except itself. Depending on scheduling, it can act as PCell or SCell within the aggregation group.

The en_dc_scg_cell_list specifies the NR cell to be added for NSA operation. In this case, NR cell 0x07 is configured as the SCG candidate. Once the UE is connected on this LTE cell and NSA conditions are satisfied, the network can add NR cell 7 as the secondary cell group.

Overall, this configuration sets up the 4th LTE cell as an additional LTE carrier with its own RF path and frequency, while enabling full LTE carrier aggregation across multiple cells and allowing NR addition through dual connectivity.

In short, 4th LTE cell is mapped to rf_port 3and configured for FDD. dl_earfcn is set to 3001. 5 LTE cells (cell id 1,2,3,5,6) are configured as SCC (Secondary Component Carrier) and one NR cell (cell id 7) is configured as SCG(Secondary Cell Group).

5th LTE Cell

This section defines the 5th LTE cell as another carrier participating in the overall carrier aggregation and NSA setup. This cell is mapped to rf_port 4, meaning it uses its own dedicated RF chain. It is configured in FDD mode, and dl_earfcn is set to 3199, which determines the operating downlink frequency for this cell.

The cell identity is defined by n_id_cell 5 and cell_id 0x05. TAC is set to 0x0001, so it belongs to the same tracking area as the other LTE cells. The root_sequence_index is configured as 86, and this should be different from other cells to minimize PRACH collision during random access.

The scell_list includes LTE cells 1, 2, 3, 4, and 6 as SCC candidates. This means the 5th LTE cell can aggregate with all other LTE carriers except itself. Depending on the scheduling and configuration, it can act as a PCell or SCell in the carrier aggregation group.

The en_dc_scg_cell_list specifies the NR cell to be added for NSA dual connectivity. In this configuration, NR cell 0x07 is defined as the SCG candidate. Once the UE is connected on this LTE cell and NSA conditions are satisfied, the network can add NR cell 7 as the secondary cell group.

Overall, this configuration sets up the 5th LTE cell as an additional LTE carrier with its own RF path and frequency, enabling full LTE carrier aggregation across multiple cells and allowing seamless addition of NR through dual connectivity.

In short, 5th LTE cell is mapped to rf_port 4and configured for FDD. dl_earfcn is set to 3199. 5 LTE cells (cell id 1,2,3,4,6) are configured as SCC (Secondary Component Carrier) and one NR cell (cell id 7) is configured as SCG(Secondary Cell Group).

6th LTE Cell

This section defines the 6th LTE cell as another carrier in the overall carrier aggregation and NSA configuration. This cell is mapped to rf_port 5, so it uses a separate RF chain from all the previous LTE cells. It is configured in FDD mode, and dl_earfcn is set to 9435, which determines the operating downlink frequency for this cell.

The cell identity is defined by n_id_cell 6 and cell_id 0x06. TAC is set to 0x0001, so it belongs to the same tracking area as the other LTE cells. The root_sequence_index is configured as 134, and it is important to assign different values across cells to reduce PRACH collision probability during random access.

The scell_list includes LTE cells 1, 2, 3, 4, and 5 as SCC candidates. This means the 6th LTE cell can aggregate with all the other LTE carriers except itself. It can operate as either a PCell or SCell depending on scheduling and configuration, enabling full LTE carrier aggregation across all defined LTE cells.

The en_dc_scg_cell_list specifies the NR cell to be added for NSA dual connectivity. In this configuration, NR cell 0x07 is defined as the SCG candidate. Once the UE is connected on this LTE cell and NSA conditions are satisfied, the network can add NR cell 7 as the secondary cell group.

Overall, this configuration sets up the 6th LTE cell as an additional LTE carrier with its own RF path and frequency, completing the multi-carrier LTE aggregation setup and enabling seamless integration with NR through dual connectivity.

In short, 6th LTE cell is mapped to rf_port 5and configured for FDD. dl_earfcn is set to 9435. 5 LTE cells (cell id 1,2,3,4,5) are configured as SCC (Secondary Component Carrier) and one NR cell (cell id 7) is configured as SCG(Secondary Cell Group).

Common to All LTE Cell

This section defines the parameters that are commonly applied to all LTE cells in the configuration. These settings control antenna configuration and measurement behavior, especially for triggering NR addition in NSA.

The cell_default part specifies the antenna configuration. n_antenna_dl defines the number of downlink antennas, and n_antenna_ul defines the number of uplink antennas. These parameters determine the basic MIMO capability of the LTE cells and affect throughput and spatial processing.

The meas_config_desc defines the measurement rules used by the UE. These rules determine when the UE should report measurement results to the network.

For LTE measurements, A1 and A2 events are configured.

A1 means the serving cell becomes good enough, based on a1_rsrp threshold.

A2 means the serving cell becomes worse than a certain level, based on a2_rsrp.

The hysteresis and time_to_trigger parameters are used to avoid unnecessary or unstable reporting by adding margin and delay.

The en_setup section is the key part for NSA operation. It defines the measurement configuration for NR using Event B1.

B1 event means the UE detects that the NR cell becomes better than a configured threshold.

Here, b1_rsrp is set as the threshold, and once the NR signal exceeds this level for the configured time_to_trigger, the UE sends a measurement report.

This measurement report is the trigger for the network to add the NR cell as SCG. Without this configuration, the UE would not report NR measurements, and EN-DC (NSA) would not be activated.

Finally, meas_gap_config defines the measurement gap pattern. This allows the UE to temporarily stop LTE transmission/reception to measure NR frequencies when needed.

Overall, this common configuration ensures that all LTE cells share the same antenna setup and measurement behavior, and more importantly, it enables the UE to detect NR cells and trigger dual connectivity through proper measurement reporting.

In short, for all LTE cell,the measurement configuration for NR cell (Event B1)is configured. The presence of this configuration indicates Measurement Report from UE is required to trigger NR Addition.

NRCell

This section defines the NR cell that will be used in NSA dual connectivity together with the LTE cells.

Only one NR cell is configured in this setup. It is mapped to rf_port 6, which means it uses a dedicated RF chain separate from all LTE cells. This ensures that LTE and NR transmissions can operate simultaneously without RF conflict.

The NR cell identity is defined by cell_id 0x07 and n_id_cell 500. The n_id_cell corresponds to the NR PCI. In this case, PCI 500 means

N_ID_1 = 166 and N_ID_2 = 2, which are used for generating PSS and SSS during NR synchronization.

The band is set to 78, which corresponds to n78 (around 3.5 GHz), one of the most commonly used 5G NR TDD bands. The dl_nr_arfcn is set to 636666, which defines the exact downlink frequency of the NR carrier.

This NR cell is configured as TDD. Unlike LTE cells in this setup (which are FDD), NR uses time-division duplexing, meaning uplink and downlink share the same frequency but are separated in time.

This NR cell is not used as a standalone serving cell. Instead, it is added as SCG (Secondary Cell Group) through the en_dc_scg_cell_list in each LTE cell configuration. The UE first connects to LTE (PCell), and when the measurement condition (Event B1) is satisfied, the network adds this NR cell.

Overall, this configuration defines a single NR carrier that operates in band n78 on rf_port 6, and it serves as the 5G layer that boosts throughput when combined with LTE through NSA dual connectivity.

In short, one NR cell is configured and it is mapped to rf_port 6. It is configured as TDD, band n78 and dl_nr_arfcn 636666.

Perform the Test

In this step, you verify that all configured LTE and NR cells are actually loaded by the system.

Run cell phy and check the output carefully. This command shows the physical layer configuration of every cell currently active in the eNB.

From the output, you can confirm RAT type, band, bandwidth, ARFCN, antenna setting, subcarrier spacing, and modulation related parameters for each cell. In this example, multiple LTE cells are listed first, followed by one NR cell. This confirms that the multi-LTE carrier aggregation setup and the NR cell for NSA are all configured in the system.

This is an important validation step before starting the actual test. Even if the configuration file looks correct, the real confirmation is whether the running system shows all cells with the intended parameters. If any cell is missing or if band, ARFCN, bandwidth, or SCS do not match your expectation, the test may fail or behave differently from what you intended.

This step verifies the logical cell configuration using the `cell` command. While `cell phy` shows physical layer parameters, this command focuses on higher-level identifiers and key configuration values.

From the output, each row represents one configured cell. The LTE cells (cell_id 0x001 to 0x006) show consistent TAC (0x0001), correct dl_earfcn values (300, 1476, 1674, 3001, 3199, 9435), and properly assigned PCI values (1 to 6). The prach_seq values are all different (120, 28, 202, 156, 86, 134), which confirms that PRACH root sequences are uniquely configured across LTE cells to avoid collision.

The NR cell (cell_id 0x007) is also shown correctly with band n78 and dl_nr_arfcn 636666. The PCI is 500, which matches the intended NR configuration.

This output confirms that all LTE and NR cells are instantiated with the correct identifiers, frequencies, and PRACH settings. If any mismatch appears here, it usually indicates a configuration issue in the enb.cfg or nr_cell_list. Since all values match the intended setup, the system is properly configured and ready for attach and NSA testing.

This step is the final validation where you confirm that LTE attach is successful and NR is added through NSA. (If you have any issues with NR addition, refer to troubleshoot section)

Run `t` command and observe the trace output. This shows real-time UE activity including PRACH, scheduling, throughput, and carrier usage.

At the beginning, you will see PRACH messages.

• UE → eNB send PRACH to do random access.
• Important Parameters are cell and snr which indicate which cell the UE is trying to access and how strong the signal is.

After random access, UE completes LTE attach. Then multiple CC (Component Carriers) start to appear.

• UE → eNB establish multiple LTE CC to do carrier aggregation.
• Important Parameters are the number of CC entries and throughput (brate).

When you see multiple lines with same UE_ID but different CC indexes, it means all LTE carriers are active.

This indicates that all 6 LTE CC are successfully configured and scheduled.

Then NR gets added.

• eNB → UE send RRCConnectionReconfiguration to add NR SCG.
• UE → eNB send RRCConnectionReconfigurationComplete to accept NR.

After this, a new entry appears with NR-related parameters.

• UE → gNB (via eNB) start using NR resources to increase throughput.
• Important Parameters are higher throughput values and additional entries beyond LTE CC.

The highlighted line “Indicates NR is added” means the UE is now operating in EN-DC mode (LTE + NR). This is the key success criteria of this test.

Overall flow is like this:

• UE → eNB send PRACH to start access
• UE → eNB complete LTE attach
• UE ↔ eNB establish multiple LTE CC (Carrier Aggregation)
• UE → eNB report NR measurement (Event B1)
• eNB → UE add NR via RRCConnectionReconfiguration
• UE → eNB confirm with RRCConnectionReconfigurationComplete
• UE → eNB/gNB operate in EN-DC (LTE + NR)

If you see all LTE CC active and then NR added, your configuration is working perfectly.

Log Analysis

Check out every details in the log. It will help you with understanding LTE CA and NSA protocol and troubleshoot process. Sample Log

This is the first and most important step in any carrier aggregation test because it tells you what the UE is actually capable of supporting. The network sends a UE Capability Enquiry, and the UE responds with UE Capability Information that describes its supported bands and features.

In the log, the requestedFrequencyBands field shows values 1, 3, 7, and 28. This means the UE supports LTE Band 1, 3, 7, and 28. This information must match the bands configured in your LTE cells. If the configured cells use bands that are not listed here, carrier aggregation will not work even if everything else is configured correctly.

In this case, the LTE cells are using Band 1, 3, 7, and 28, so they match the UE capability. This confirms that carrier aggregation is feasible with this UE.

The same message also includes MRDC-related capability, which indicates whether the UE supports LTE and NR dual connectivity. The presence of NR band information such as n78 confirms that the UE can support NSA operation with NR.

So from this step, you can conclude that the UE supports the required LTE bands for carrier aggregation and also supports NR band n78 for dual connectivity. This makes both CA and NSA operation possible in this setup.

In this step, instead of digging into the detailed ASN.1 structure of the UE Capability Information message, you check the decoded capability table, which makes interpretation much easier.

From this table, you can clearly see that the UE supports LTE bands 1, 3, 7, and 28, and also supports NR band 78. This already confirms that the UE is compatible with the LTE and NR bands used in your configuration.

More importantly, the CA combination list shows how these bands can be aggregated together. Each combination defines a specific set of bands that the UE can use simultaneously. You need to verify that at least one of these combinations matches your configured carrier aggregation scenario. For example, if your setup uses multiple LTE bands such as 1, 3, 7, and 28 together, there must be a corresponding CA combination in this list that includes these bands in downlink.

If such a combination exists, it confirms that the UE can support the intended carrier aggregation configuration. If not, even though the UE supports the individual bands, it will not be able to aggregate them simultaneously.

So this table gives you a direct and practical way to confirm whether your CA setup is feasible. It validates not only band support but also the exact aggregation combinations required for the test.

In this step, the network performs an additional UE Capability Enquiry specifically for NSA (EN-DC) capability. Unlike the earlier LTE-only capability check, this message explicitly requests combined LTE and NR capability using eutra-nr.

From the message, you can see that the enquiry includes LTE bands 1, 3, 7, and 28 together with NR band n78. This means the network is asking the UE whether it can support dual connectivity using these LTE bands as the anchor and NR n78 as the secondary cell group.

The UE responds with UE Capability Information that includes MRDC (Multi-Radio Dual Connectivity) capability. This confirms whether the UE can operate LTE and NR simultaneously under NSA. The presence of band combination information that includes both EUTRA and NR indicates that the UE supports EN-DC.

This step is important because even if the UE supports LTE CA and NR individually, NSA will not work unless the UE supports the specific LTE + NR band combination. By confirming LTE bands 1, 3, 7, 28 together with NR n78 in the capability exchange, you verify that the UE can support the exact NSA configuration used in this setup.

So this message confirms that the UE is capable of LTE carrier aggregation and also capable of adding NR n78 as SCG, which makes the EN-DC operation in your test feasible.

In this step, you verify NSA (EN-DC) capability using the UE capability table instead of analyzing the raw RRC message. This view makes it much easier to confirm whether the UE supports the required LTE + NR combinations.

From the table, you can see multiple EN-DC combinations listed. Each combination represents a supported configuration where LTE bands are used as the anchor and NR band n78 is added as SCG. The entries clearly show LTE bands such as 1, 3, 7, and 28 combined together with NR band n78 in both downlink and uplink.

The key point here is to check whether at least one of these combinations matches your actual test configuration. Since your setup uses LTE bands 1, 3, 7, and 28 together with NR n78, you need to find a combination that includes these bands. The presence of such combinations in the list confirms that the UE supports this specific EN-DC configuration.

This step is important because supporting LTE bands and NR band individually is not enough. The UE must support the exact LTE + NR combination as defined in the EN-DC capability. If the combination is not listed, NR will not be added even if all individual bands are supported.

So from this table, you can confirm that the UE supports the required EN-DC combinations, which means LTE carrier aggregation and NR addition through NSA should work correctly in your setup.

Once the UE capability confirms that the required LTE CA and EN-DC combination is supported, the network proceeds with measurement configuration through RRCConnectionReconfiguration.

In this message, the eNB configures measurement objects for multiple LTE carrier frequencies. You can see carrierFreq values such as 300, 1476, 1674, 3001, 3199, and 9435, which correspond exactly to the LTE cells configured earlier. This means the network is instructing the UE to monitor all these LTE frequencies.

Each measObject defines how the UE should measure a specific LTE carrier. Parameters like allowedMeasBandwidth and presenceAntennaPort indicate the measurement bandwidth and antenna configuration, while neighCellConfig provides additional neighbor cell information.

The purpose of this configuration is to enable the UE to continuously measure all configured LTE carriers so that the network can decide when to activate carrier aggregation. Based on these measurements, the UE will send measurement reports, which the eNB uses to add secondary cells (SCells).

This step is essential because without proper measurement configuration, the UE would not report the necessary signal conditions, and the network would not be able to trigger LTE carrier aggregation or proceed with NR addition in NSA.

In this step, the network configures measurement for the NR cell in addition to the LTE measurements. The measObject for NR is set with carrierFreq 636696, which corresponds to the SSB frequency of the target NR cell. Unlike LTE, NR measurements are based on SSB, so this frequency tells the UE where to look for NR synchronization signals and measure signal quality.

Along with the frequency, parameters such as subcarrierSpacingSSB and quantityConfig define how the UE should perform the measurement. The bandNR value is also specified as 78, confirming that the measurement is for the NR cell in band n78.

After defining the measurement object, the network configures the reporting criteria using Event B1. This event is used for inter-RAT measurement, specifically for detecting NR from LTE. The parameter b1-ThresholdNR defines the signal level that the NR cell must exceed for the UE to trigger a report. The timeToTrigger ensures that the condition is stable for a certain duration before reporting, preventing unnecessary or unstable triggers.

With this configuration, the UE continuously monitors the NR SSB at the specified frequency. Once the NR signal becomes strong enough and satisfies the B1 condition, the UE sends a measurement report to the network. This report is the key trigger for the eNB to initiate NR addition through RRCConnectionReconfiguration.

So this step enables the UE to detect the NR cell and provides the mechanism for the network to decide when to activate EN-DC based on real radio conditions.

In this step, the configured NR measurement is actually activated. The network links measObjectId 7, which represents the NR measurement at the SSB frequency, with reportConfigId 1, which corresponds to Event B1.

This means the UE is now instructed to monitor the NR cell defined in measObjectId 7 and apply the reporting condition defined in reportConfigId 1. In other words, the UE continuously measures the NR SSB signal at the configured frequency and checks whether the signal exceeds the B1 threshold.

Once the NR signal becomes strong enough and satisfies the Event B1 condition for the configured time, the UE triggers a measurement report. This report is sent from UE to eNB and indicates that the NR cell is now suitable for addition.

This is a key moment in NSA operation because it is the exact trigger point for NR addition. After receiving this measurement report, the eNB proceeds with RRCConnectionReconfiguration to add the NR cell as SCG.

So this step confirms that the measurement configuration is not only set but also actively used, and the UE is now ready to trigger NR addition based on real radio conditions.

In this step, LTE carrier aggregation starts to take effect within the same RRCConnectionReconfiguration message. The network adds LTE cell id 2 as a Secondary Cell (SCell).

eNB → UE send RRCConnectionReconfiguration to add SCell

Important Parameters are sCellIndex-r10 = 1 which identifies the first SCell, and physCellId = 2 which corresponds to LTE cell id 2. carrierFreq-r10 = 1476 indicates the frequency of this SCell.

This means the UE, which is already connected to the PCell, is now instructed to activate an additional LTE carrier. The UE will configure this cell as an SCell and start using it for data transmission.

After receiving this message, UE → eNB send RRCConnectionReconfigurationComplete to confirm the configuration.

This is the beginning of LTE carrier aggregation. The UE is no longer operating on a single LTE carrier but is now using multiple carriers simultaneously. As more SCells are added in subsequent steps, the UE will utilize multiple LTE component carriers, increasing the overall throughput.

In the same RRCConnectionReconfiguration message, the network continues to expand carrier aggregation by adding LTE cell id 3 as another Secondary Cell.

eNB → UE send RRCConnectionReconfiguration to add an additional SCell

Important Parameters are sCellIndex-r10 = 2 which identifies this as the second SCell, physCellId = 3 which corresponds to LTE cell id 3, and carrierFreq-r10 = 1674 which indicates the frequency of this cell.

This means the UE now configures a second SCell in addition to the first one. The UE is no longer operating with just one extra carrier, but now with multiple aggregated LTE carriers.

After processing this configuration, UE → eNB send RRCConnectionReconfigurationComplete to confirm that the new SCell has been successfully added.

At this stage, carrier aggregation is expanding step by step. The UE is gradually increasing the number of active component carriers, which allows higher throughput as more bandwidth becomes available..

In the same RRCConnectionReconfiguration message, the network continues adding more LTE component carriers by configuring LTE cell id 4 as another Secondary Cell.

eNB → UE send RRCConnectionReconfiguration to add SCell

Important Parameters are sCellIndex-r10 = 3 which identifies this as the third SCell, physCellId = 4 which corresponds to LTE cell id 4, and carrierFreq-r10 = 3001 which indicates the frequency of this cell.

This means the UE now activates a third SCell in addition to the previously added ones. The aggregation is expanding step by step, and the UE is now operating with multiple LTE carriers simultaneously.

After applying this configuration, UE → eNB send RRCConnectionReconfigurationComplete to confirm that the new SCell has been successfully added.

At this stage, the UE is using a larger aggregated bandwidth, and throughput will increase accordingly as more component carriers are utilized.

In the same RRCConnectionReconfiguration message, the network further extends carrier aggregation by adding LTE cell id 5 as another Secondary Cell.

eNB → UE send RRCConnectionReconfiguration to add SCell

Important Parameters are sCellIndex-r10 = 4 which identifies this as the fourth SCell, physCellId = 5 which corresponds to LTE cell id 5, and carrierFreq-r10 = 3199 which indicates the operating frequency of this cell.

This shows that the aggregation is being expanded step by step, and the UE is now configured with four LTE SCells in addition to the PCell. As more SCells are added, the UE can receive and transmit over multiple carriers simultaneously, which increases the overall throughput and bandwidth utilization.

After receiving this configuration, UE → eNB send RRCConnectionReconfigurationComplete to confirm that the fourth SCell has been successfully added.

At this point, the LTE carrier aggregation is reaching a higher order configuration, preparing the UE for full ENDC operation together with the NR cell.

In the same RRCConnectionReconfiguration message, the network adds one more LTE component carrier, configuring LTE cell id 6 as the fifth Secondary Cell.

eNB → UE send RRCConnectionReconfiguration to add SCell

Important Parameters are sCellIndex-r13 = 5 which identifies this as the fifth SCell, physCellId = 6 which corresponds to LTE cell id 6, and dl-CarrierFreq-r13 = 9435 which indicates the operating frequency of this cell.

This indicates that the UE is now configured with five LTE SCells in addition to the PCell, forming a high-order carrier aggregation scenario. The use of sCellIndex-r13 also shows that extended CA capability is being applied, allowing more than the basic number of SCells defined in earlier releases.

After receiving this configuration, UE → eNB send RRCConnectionReconfigurationComplete to acknowledge that the fifth SCell has been successfully added.

At this stage, the LTE side aggregation is fully expanded, and the system is ready to combine this with the NR cell to achieve full ENDC operation with maximum bandwidth utilization.

In the same RRCConnectionReconfiguration message, the network configures NR radio bearers using nrRadioBearerConfig1-r15, which is a key step for enabling user plane data over NR in ENDC.

eNB → UE send RRCConnectionReconfiguration to configure NR radio bearer

Important Parameters are nrRadioBearerConfig1-r15 which contains drb-ToAddModList, indicating that a DRB is being established over NR. Within this, cnAssociation is mapped to eps-BearerIdentity, meaning the NR DRB is linked to an existing LTE EPS bearer. The pdcp-Config defines PDCP behavior such as SN size, discardTimer, and status reporting, ensuring proper data handling across LTE-NR split architecture.

This configuration shows that the user plane is now extended to NR, meaning data can flow through the NR leg (gNB) while LTE remains the anchor for control plane signaling. It is a critical step where ENDC transitions from just measurement and cell addition into actual dual connectivity data operation.

SecurityConfig is also included, specifying cipheringAlgorithm and keyToUse, which ensures that the NR data path is properly secured using the derived keys from the LTE anchor.

After applying this configuration, UE → eNB send RRCConnectionReconfigurationComplete, confirming that the NR radio bearer has been successfully established.

At this point, both LTE carrier aggregation and NR dual connectivity are fully configured, enabling high throughput by combining multiple LTE carriers with NR resources.

Once all the RRC procedures are successfully completed, the system transitions from configuration phase to actual data transmission phase at MAC level.

eNB → UE send MAC CE to activate SCells

Important behavior is that MAC Control Elements are used to dynamically enable each configured SCell without requiring additional RRC signaling. In the log, messages like “enabling scell 1”, “enabling scell 2”, up to “enabling scell 5” indicate that all previously configured Secondary Cells are now activated for traffic.

This step is critical because even though SCells were configured earlier through RRCConnectionReconfiguration, they are not immediately used for data transmission. The MAC CE explicitly turns them on, allowing scheduling across all aggregated carriers.

After this activation, the UE starts utilizing multiple LTE carriers simultaneously for both uplink and downlink, and together with the already configured NR leg, the system achieves full ENDC operation with maximum throughput capability.

After LTE Carrier Aggregation is fully configured and all SCells are activated, the UE starts reporting measurements for the NR cell as configured earlier.

UE → eNB send MeasurementReport to provide NR measurement results

Important Parameters are measResultNeighCells which includes the measurement results for NR cells, pci-r15 which identifies the detected NR cell, rsrpResult-r15 and rsrqResult-r15 which indicate the received signal strength and quality, and ss-sinr-Result-r15 which represents the NR signal-to-interference-plus-noise ratio.

This report is triggered based on the previously configured reportConfigId (Event B1), meaning the UE sends the report when the NR cell quality meets the configured threshold. The measurement is based on SSB of the NR cell, which was configured using the SSB frequency earlier.

This step confirms that the UE has successfully detected and evaluated the NR cell under the configured measurement conditions. Based on this report, the network can decide to proceed with NR addition (PSCell addition) and fully activate dual connectivity.

At this point, the system completes the transition from LTE-only carrier aggregation to LTE-NR ENDC operation, where LTE remains the anchor and NR is added as a secondary node for high data throughput.

Once the eNB receives the MeasurementReport indicating that the NR cell meets the configured threshold, it proceeds with NR addition to establish ENDC.

eNB → UE send RRCConnectionReconfiguration to add NR (Secondary Node)

Important Parameters are nr-Config-r15 which contains the configuration for the NR side, including secondaryCellGroup that defines the NR cell group configuration. Within this, cellGroupId = 1 identifies the NR group, and rlc-BearerToAddModList configures the radio bearers for NR. The mac-CellGroupConfig and physical configurations are also included to fully initialize NR operation.

This message represents the actual NR addition step, where the UE is instructed to establish connection with the NR cell (PSCell) and configure all necessary protocol layers including RLC, MAC, and physical parameters.

After receiving this configuration, UE → gNB completes the NR setup internally and UE → eNB send RRCConnectionReconfigurationComplete to confirm successful ENDC establishment.

At this point, dual connectivity is fully activated. LTE continues to handle the control plane as the anchor (MeNB), while NR operates as the secondary node (SgNB) providing additional user plane capacity, enabling significantly higher throughput.

You can confirm from this RRCConnectionReconfiguration message that the NR cell is successfully added as part of the Secondary Cell Group (SCG).

eNB → UE send RRCConnectionReconfiguration to configure SCG (NR)

Important Parameters are spCellConfig which defines the NR Primary Secondary Cell (PSCell), physCellId = 500 which identifies the NR cell PCI, and absoluteFrequencySSB = 633696 which indicates the SSB frequency of the NR cell (band n78). The presence of these parameters confirms that the UE is now configured to operate on this NR cell.

This shows that the NR cell with band n78 and PCI 500 is not just detected but fully configured as the PSCell within the SCG. The PSCell acts as the anchor for NR operations in ENDC, handling scheduling and data transmission on the NR side.

After applying this configuration, UE → eNB send RRCConnectionReconfigurationComplete, confirming that the SCG setup is complete.

At this point, the UE is operating in full ENDC mode. LTE serves as the Master Cell Group (MCG) for control plane, and NR (n78, PCI 500) serves as the Secondary Cell Group (SCG) for high-speed user plane data.

You can confirm that the NR cell is successfully added by checking whether the RACH procedure toward NR is completed, because this is the point where NSA setup most often fails.

UE → gNB send PRACH to initiate random access on NR

Important Parameters are the PRACH sequence and timing (preamble transmission), which indicates that the UE has started access to the NR cell.

gNB → UE send Random Access Response (RAR) to allocate resources

Important Parameters are timing advance, uplink grant, and temporary C-RNTI, which allow the UE to proceed with the next step of the access procedure.

UE → gNB send Msg3 (scheduled transmission) to complete connection setup

This message carries the necessary identification and connection information over the allocated uplink resources.

gNB → UE send contention resolution (Msg4) to finalize access

This confirms that the UE is successfully recognized and that the random access procedure is completed.

This sequence shows that the UE has successfully completed the NR random access procedure and is now connected to the NR cell. It proves that the SCG addition is not only configured at RRC level but also operational at PHY/MAC level.

If this RACH procedure fails, the ENDC setup would fail even if all RRC signaling looks correct. That is why verifying these logs is a critical step in debugging NSA issues.

Test 3: 5 LTE CA(FDD + TDD)+ Single NR

This is a kind of advanced test of NSA and I assume that the readers are already familiar with basic operations and overall verification procedures explained in Test 1. With that assumption, I would mainly focus on RAN side configuration and verification only. You can follow the procedure in Test 1 for user traffic.

NOTE : This test involves many cells. 6cells in total. Before you try this, first make it sure that you have enough hardware resources (i.e, enough number of SDR card and PC performance).

• The best option is that you have 6sdr cards.
• If you don't have enough number of sdr cards, you may put multiple cells in one sdr card if the requency and RAT requirement is met as mentioned in this tutorial.

Configuration

The configuration for this test is gnb-cc-mix_TDD_FDD-nsa.cfg which is cbased on gnb-nsa.cfg. It may look complicated but it is just repetition of the same structure with minor modifications.

Following is the configurations for 5LTE cells. The key point to be noticed in this configuration is that not all LTE cells uses the same duplex pattern. It is mixture of FDD and TDD. Some of them are using FDD and some of them are using TDD.

Global Parameters

At the beginning of the configuration, a set of global parameters is defined to control duplex mode and bandwidth for each LTE and NR cell. These parameters allow flexible setup because the carrier aggregation in this example mixes FDD and TDD cells, which require different configurations.

Each LTE cell is assigned a duplex mode using TDD_x parameters. A value of 0 means LTE FDD and 1 means LTE TDD. This allows each cell to operate independently in either FDD or TDD mode depending on the deployment scenario. This is important because mixed CA scenarios often combine different duplex schemes.

For each LTE cell, bandwidth is defined using N_RB_DL_x parameters. These values represent the number of resource blocks, which directly determine the channel bandwidth. For example, 100 RB corresponds to 20 MHz. By configuring this per cell, the system can aggregate carriers with different bandwidths.

For NR, a separate set of parameters is defined. NR_TDD specifies whether the NR cell operates in FDD or TDD mode, and NR_TDD_CONFIG defines the TDD pattern that must be compatible with LTE TDD configuration. N_RB_DL defines the NR bandwidth in terms of resource blocks, and N_ANTENNA_DL and N_ANTENNA_UL define the MIMO configuration for downlink and uplink respectively.

NR_BANDWIDTH is derived depending on whether NR operates in TDD or FDD, ensuring that the correct bandwidth is applied automatically. Finally, NR_LONG_PUCCH_FORMAT controls the uplink control channel format, which affects how control information is transmitted in NR.

Overall, these global parameters provide a flexible framework to configure multi-cell LTE carrier aggregation together with NR ENDC, enabling precise control over duplexing, bandwidth, and antenna configurations for each individual cell.

1st LTE Cell

Then the physical configuration for the first LTE cell is defined. This cell is mapped to RF port 0, meaning it uses the first SDR or RF interface for transmission and reception. The broadcast PLMN is set to "00101", which is the network identity that the UE will detect during cell search.

The duplex mode of this cell is controlled by the TDD_1 parameter. If TDD_1 is set to 1, the cell operates in TDD mode and uses dl_earfcn 40620 corresponding to band 41. Otherwise, it operates in FDD mode with dl_earfcn 800, which corresponds to a downlink center frequency of 1950 MHz in band 2. In this configuration, it is set to FDD.

The bandwidth of the cell is configured using n_rb_dl, which is mapped to the global parameter N_RB_DL_1. This determines the channel bandwidth, for example 100 RB corresponds to 20 MHz. The number of downlink antenna ports is set to 1, indicating SISO operation.

The cell identity is defined as cell_id 0x01, and the tracking area code is set to tac 0x0001. These parameters are essential for mobility and identification within the network.

Finally, the PRACH configuration is partially defined through root_sequence_index, which determines the Zadoff-Chu sequence used for random access. This parameter is important for UE initial access and synchronization.

Overall, this first LTE cell acts as the primary serving cell (PCell), providing the anchor for control plane signaling and forming the basis for carrier aggregation and ENDC operation that follows.

In this configuration, the relationship between LTE carrier aggregation and NR ENDC is explicitly defined.

The en_dc_scg_cell_list specifies which NR cell will be added as the Secondary Cell Group. Here, cell_id 0x06 is defined, meaning LTE will later add this NR cell as SCG during the ENDC procedure. This is the NR cell that becomes the PSCell once the setup is complete.

The scell_list defines which LTE cells can be used as Secondary Component Carriers for carrier aggregation. In this case, LTE cell ids 2, 3, 4, and 5 are listed. These cells are candidates for SCell addition and will be activated step by step through RRCConnectionReconfiguration and MAC CE.

Each entry includes cross_carrier_scheduling set to false, which means each SCell schedules its own PDSCH/PUSCH rather than being scheduled by another carrier. This keeps scheduling independent across carriers.

Overall, this configuration clearly separates roles. LTE cell id 1 acts as the PCell, LTE cell ids 2 to 5 act as SCCs for carrier aggregation, and NR cell id 6 is reserved for SCG addition in NSA. This mapping ensures that the network can first build LTE carrier aggregation and then extend it with NR dual connectivity for higher throughput.

This LTE cell is configured in FDD mode, so any TDD-specific configuration is not applied. The conditional blocks controlled by TDD_1 are skipped, meaning parameters like uldl_config, sp_config, and TDD-specific ACK/NACK feedback modes are not used.

Instead, the configuration focuses on uplink control settings that are valid for FDD. The pucch_dedicated section defines how uplink control information is transmitted. The parameter n1_pucch_sr_count determines how many scheduling request resources are available, and cqi_pucch_n_rb defines how many resource blocks are allocated for CQI reporting. These parameters directly affect how many UEs can be supported and how efficiently control signaling is handled.

The parameter n1_pucch_an_cs_count defines the number of PUCCH format 1b channel selection resources, which determines how many UEs can send ACK/NACK simultaneously when carrier aggregation is used.

Since this is an FDD configuration, the ACK/NACK feedback mode is set using ack_nack_feedback_mode_ca, which is configured as pucch3. This means the UE uses PUCCH format 3 for ACK/NACK feedback when multiple carriers are aggregated, providing better scalability.

The parameter n3_pucch_an_n_rb defines how many resource blocks are allocated for PUCCH format 3. This controls the capacity for uplink control signaling under carrier aggregation.

Overall, this configuration ensures proper uplink control operation for an FDD-based LTE carrier aggregation setup while excluding all TDD-specific behavior.

2nd LTE Cell

Then the physical configuration for the second LTE cell is defined. This cell is mapped to RF port 1, meaning it uses a different RF chain from the first LTE cell. The broadcast PLMN is set to "00101", so the UE recognizes it as part of the same network.

The duplex mode is controlled by TDD_2. In this configuration, TDD_2 is set to 1, so the cell operates in TDD mode. As a result, dl_earfcn is set to 47290, which corresponds to a downlink frequency around 5200 MHz in band 46. If it were FDD, it would instead use dl_earfcn 3350 for band 7, but that path is not used here.

The bandwidth is configured using n_rb_dl mapped to N_RB_DL_2, allowing flexible bandwidth selection such as 5, 10, 15, or 20 MHz. This enables this cell to participate in carrier aggregation with potentially different bandwidth from other cells.

The physical cell identity is defined with n_id_cell = 2 and cell_id = 0x02, which uniquely identifies this LTE cell within the system. The tracking area code is set to tac 0x0001, consistent with the first cell.

The PRACH configuration uses root_sequence_index = 80, which determines the Zadoff-Chu sequence used for random access on this cell. This ensures proper separation of random access sequences between cells.

Overall, this second LTE cell is configured as a TDD cell on a different RF port and frequency band, making it a candidate for SCell addition in carrier aggregation and contributing additional capacity to the overall system.

In this configuration, one NR cell with cell_id 0x06 is defined in en_dc_scg_cell_list, meaning this cell will be added as the Secondary Cell Group for ENDC. This NR cell becomes the PSCell once dual connectivity is established.

The scell_list defines which LTE cells are available as Secondary Component Carriers for carrier aggregation. In this case, LTE cell ids 1, 3, 4, and 5 are listed, meaning these cells can be added as SCells on top of the PCell.

Each LTE cell entry includes cross_carrier_scheduling set to false, indicating that each carrier performs its own scheduling independently rather than being scheduled by another carrier.

Overall, LTE cell id 2 acts as the PCell in this setup, LTE cell ids 1, 3, 4, and 5 are configured as SCCs for carrier aggregation, and NR cell id 6 is configured as the SCG. This setup enables LTE carrier aggregation first and then extends it to ENDC by adding the NR cell for higher data throughput.

This cell is configured in TDD mode, so the TDD-specific parameters are actively applied.

The parameter uldl_config is set to 2, which defines the uplink and downlink slot pattern for this TDD cell. This determines how subframes are divided between UL and DL, directly impacting latency and throughput behavior.

The parameter sp_config is set to 7, which defines the special subframe configuration. This controls the structure of DwPTS, GP, and UpPTS within the special subframe and is important for proper UL/DL switching.

For uplink control, the pucch_dedicated section defines how control information is transmitted. Parameters like n1_pucch_sr_count and cqi_pucch_n_rb define the available resources for scheduling request and CQI reporting.

The parameter n1_pucch_an_cs_count determines how many UEs can transmit ACK/NACK simultaneously using PUCCH format 1b channel selection.

Since this is TDD, specific ACK/NACK feedback modes are configured. The parameter tdd_ack_nack_feedback_mode_r10 is set to cs, meaning channel selection is used for legacy Rel-10 behavior. The parameter tdd_ack_nack_feedback_mode is set to multiplexing, which allows multiple ACK/NACK bits to be transmitted efficiently in TDD operation.

For carrier aggregation, ack_nack_feedback_mode_ca is set to pucch3, meaning PUCCH format 3 is used when multiple carriers are active, providing better scalability.

Finally, n3_pucch_an_n_rb defines the number of resource blocks allocated for PUCCH format 3, which determines how many UEs can send ACK/NACK simultaneously under carrier aggregation.

Overall, this configuration enables proper UL/DL switching and efficient uplink control signaling for a TDD-based LTE cell participating in carrier aggregation.

3rd LTE Cell

Then the physical configuration for the third LTE cell is defined. This cell is mapped to RF port 2, meaning it uses another independent RF chain. The broadcast PLMN is set to "00101", keeping it consistent with the other cells in the same network.

The duplex mode is controlled by TDD_3, and in this configuration it is set to 1, so the cell operates in TDD mode. As a result, dl_earfcn is set to 47488, which corresponds to a downlink frequency around 5219.8 MHz in band 46. This configuration is aligned to support wideband operation in the unlicensed or shared spectrum range.

The bandwidth is configured using n_rb_dl mapped to N_RB_DL_3, allowing flexible selection such as 5, 10, 15, or 20 MHz depending on system requirements.

The physical cell identity is defined with n_id_cell = 3 and cell_id = 0x03, uniquely identifying this LTE cell. The tracking area code is set to tac 0x0001, consistent across all cells in this setup.

The PRACH configuration uses root_sequence_index = 68, which defines the Zadoff-Chu sequence used for random access. This helps avoid collision with other cells by assigning different root sequences.

Overall, this third LTE cell is another TDD carrier operating on a separate RF port and frequency, making it suitable as an SCell for carrier aggregation and contributing additional capacity to the system.

In this configuration, one NR cell with cell_id 0x06 is defined in en_dc_scg_cell_list, meaning this cell will be added as the Secondary Cell Group for ENDC and will act as the PSCell after setup.

The scell_list defines the LTE cells that can be used as Secondary Component Carriers for carrier aggregation. In this case, LTE cell ids 1, 2, 4, and 5 are listed, meaning these cells are candidates for SCell addition alongside the PCell.

Each LTE cell entry has cross_carrier_scheduling set to false, which means each carrier schedules its own resources independently.

Overall, LTE cell id 3 acts as the PCell in this setup, LTE cell ids 1, 2, 4, and 5 are configured as SCCs for carrier aggregation, and NR cell id 6 is configured as the SCG. This structure allows the system to first build LTE carrier aggregation and then extend it to ENDC by adding the NR cell for higher throughput.

This cell is configured in TDD mode, so the TDD-specific configuration is applied.

The parameter uldl_config is set to 2, which defines the uplink and downlink slot pattern for this TDD cell. This determines how radio frames are divided between UL and DL.

The parameter sp_config is set to 7, which defines the special subframe configuration, including DwPTS, GP, and UpPTS structure for UL/DL switching.

The pucch_dedicated section defines uplink control channel behavior. The parameter n1_pucch_sr_count specifies the number of scheduling request resources, and cqi_pucch_n_rb defines the resource blocks for CQI reporting.

The parameter n1_pucch_an_cs_count determines how many UEs can transmit ACK/NACK simultaneously using PUCCH format 1b channel selection.

Since this is TDD, the ACK/NACK feedback modes are explicitly configured. The parameter tdd_ack_nack_feedback_mode_r10 is set to cs, meaning channel selection is used for Rel-10 behavior. The parameter tdd_ack_nack_feedback_mode is set to multiplexing, allowing multiple ACK/NACK bits to be transmitted efficiently.

For carrier aggregation, ack_nack_feedback_mode_ca is set to pucch3, meaning PUCCH format 3 is used when multiple carriers are active.

Finally, n3_pucch_an_n_rb defines the number of resource blocks allocated for PUCCH format 3, which determines uplink control capacity.

Overall, this configuration enables proper UL/DL switching and efficient uplink control signaling for a TDD LTE cell participating in carrier aggregation.

4th LTE Cell

Then the physical configuration for the fourth LTE cell is defined. This cell is mapped to RF port 3, meaning it uses another independent RF chain. The broadcast PLMN is set to "00101", consistent with the rest of the cells.

The duplex mode is controlled by TDD_4, and in this configuration it is set to 1, so the cell operates in TDD mode. As a result, dl_earfcn is set to 47686, which corresponds to a downlink frequency around 5239.6 MHz in band 46. This continues the use of high-frequency TDD carriers for aggregation.

The bandwidth is configured using n_rb_dl mapped to N_RB_DL_4, allowing flexible bandwidth selection such as 5, 10, 15, or 20 MHz.

The physical cell identity is defined with n_id_cell = 4 and cell_id = 0x04, uniquely identifying this LTE cell. The tracking area code is set to tac 0x0001, maintaining consistency across the network.

The PRACH configuration uses root_sequence_index = 268, which defines the Zadoff-Chu sequence used for random access. Different root sequence indices across cells help avoid collision during random access procedures.

Overall, this fourth LTE cell is another TDD carrier on a separate RF port and frequency, making it suitable as an SCell for carrier aggregation and contributing additional capacity to the overall system.

In this configuration, one NR cell with cell_id 0x06 is defined in en_dc_scg_cell_list, which means this NR cell will be added as the Secondary Cell Group for ENDC.

The scell_list defines which LTE cells can be used as Secondary Component Carriers for carrier aggregation. In this case, LTE cell ids 1, 2, 3, and 5 are listed, meaning these cells are candidates for SCell addition together with the current PCell.

Each LTE cell entry has cross_carrier_scheduling set to false, which means each carrier schedules its own resources independently.

Overall, LTE cell id 4 acts as the PCell in this setup, LTE cell ids 1, 2, 3, and 5 are configured as SCCs for carrier aggregation, and NR cell id 6 is configured as the SCG. This allows the network to build LTE carrier aggregation first and then extend it to ENDC by adding the NR cell for higher throughput.

This cell is configured in TDD mode, so the TDD-specific configuration is applied.

The parameter uldl_config is set to 2, which defines the uplink and downlink slot pattern for this cell. This determines how the radio frame is divided between UL and DL transmissions.

The parameter sp_config is set to 7, which defines the special subframe structure, including DwPTS, GP, and UpPTS. This is important for proper UL/DL switching in TDD operation.

The pucch_dedicated section defines uplink control behavior. The parameter n1_pucch_sr_count specifies the number of scheduling request resources, and cqi_pucch_n_rb defines the resource blocks allocated for CQI reporting.

The parameter n1_pucch_an_cs_count determines how many UEs can transmit ACK/NACK simultaneously using PUCCH format 1b channel selection.

Since this is TDD, ACK/NACK feedback modes are explicitly configured. The parameter tdd_ack_nack_feedback_mode_r10 is set to cs, meaning channel selection is used for Rel-10 operation. The parameter tdd_ack_nack_feedback_mode is set to multiplexing, allowing multiple ACK/NACK bits to be transmitted efficiently.

For carrier aggregation, ack_nack_feedback_mode_ca is set to pucch3, meaning PUCCH format 3 is used when multiple carriers are active.

Finally, n3_pucch_an_n_rb defines the number of resource blocks for PUCCH format 3, which determines uplink control capacity.

Overall, this configuration ensures proper UL/DL switching and efficient uplink control signaling for a TDD LTE cell participating in carrier aggregation.

5th LTE Cell

Then the physical configuration for the fifth LTE cell is defined. This cell is mapped to RF port 4, so it uses a separate RF chain from the other LTE cells. The broadcast PLMN is set to 00101, which keeps it in the same network as the other cells.

The duplex mode is controlled by TDD_5. In this configuration, the cell is configured for FDD, so the TDD-specific path is not used. The dl_earfcn is set to 66836, which corresponds to a downlink center frequency of 2150 MHz in band 66. If TDD_5 were enabled, the alternative frequency would be 46090 for band 44, but that is not applied here.

The bandwidth is configured using n_rb_dl mapped to N_RB_DL_5. This determines the LTE channel bandwidth for this cell. The physical cell identity is defined with n_id_cell 5 and cell_id 0x05. The tracking area code is set to 0x0001, consistent with the other LTE cells.

The PRACH configuration uses root_sequence_index 116. This value defines the Zadoff-Chu root sequence for random access and helps separate this cell from the others during PRACH operation.

Overall, this fifth LTE cell is configured as an FDD carrier on RF port 4 and band 66. It can act as one of the LTE component carriers in the carrier aggregation setup and contribute additional bandwidth to the full ENDC configuration.

In this configuration, one NR cell with cell_id 0x06 is defined as the SCG, which means it will be added as the Secondary Cell Group during NSA EN-DC setup. This NR cell becomes the anchor for all NR radio resources once the dual connectivity procedure is completed.

At the same time, four LTE cells with cell_id 0x01, 0x02, 0x03, and 0x04 are configured as SCC candidates. These cells are listed under scell_list, meaning they can be activated as Secondary Component Carriers for LTE carrier aggregation depending on UE capability and network decision.

Each LTE cell in the scell_list has cross_carrier_scheduling set to false, which means scheduling is handled independently per cell rather than from a centralized scheduling cell.

Overall, this setup defines a typical EN-DC scenario where LTE acts as the Master Cell Group and provides multiple aggregated carriers, while a single NR cell is added as the Secondary Cell Group to boost throughput.

This cell is configured as FDD, so all TDD-specific configurations are not applied.

The conditional block controlled by TDD_5 is not executed, so parameters like uldl_config and sp_config are ignored. This means there is no need to define UL/DL switching patterns or special subframe structures, since FDD uses separate frequencies for uplink and downlink.

The pucch_dedicated configuration is still applied. The parameter n1_pucch_sr_count defines the number of scheduling request resources, and cqi_pucch_n_rb defines how many resource blocks are allocated for CQI reporting.

The parameter n1_pucch_an_cs_count determines how many UEs can transmit ACK/NACK simultaneously using PUCCH format 1b channel selection.

The TDD-specific ACK/NACK configuration block is also skipped. Therefore, parameters like tdd_ack_nack_feedback_mode_r10 and tdd_ack_nack_feedback_mode are not used in this cell.

For carrier aggregation, ack_nack_feedback_mode_ca is set to pucch3. This ensures that when multiple LTE carriers are active, ACK/NACK feedback is transmitted using PUCCH format 3.

Finally, n3_pucch_an_n_rb defines the number of resource blocks allocated for PUCCH format 3, which controls the uplink control capacity when carrier aggregation is enabled.

Overall, this configuration reflects a typical FDD LTE cell where duplexing is frequency-based, and only general uplink control parameters are applied without any TDD-specific behavior.

NRCell

Now the NR cell is configured for NSA operation.

The NR cell is defined under nr_cell_list and is mapped to RF port 5, meaning it uses a separate RF chain dedicated to NR transmission. The cell_id is set to 0x06, and the physical cell identity n_id_cell is set to 500, which is used for synchronization signals and overall NR cell identification.

The duplex mode is controlled by NR_TDD. In this configuration, NR_TDD is enabled, so the cell operates in TDD mode. The band is set to 78, which is a common mid-band 5G spectrum, and dl_nr_arfcn is set to 627300, defining the exact carrier frequency for this NR cell.

If NR_TDD were disabled, the alternative configuration would use band 7 with a different ARFCN, but that path is not used here.

This NR cell will later be added as the SCG in the EN-DC setup, meaning it will provide additional NR resources on top of the LTE anchor. Overall, this configuration prepares a TDD-based n78 NR cell that integrates into the NSA architecture alongside the LTE carrier aggregation setup.

Common to All LTE Cell

This section defines the default configuration that is applied to all LTE cells through cell_default.

The antenna configuration is set first. The parameter n_antenna_dl defines the number of downlink antennas, and n_antenna_ul is set to 1, meaning single uplink transmission is used for all LTE cells.

The CSI reporting is configured as periodic. The parameter cqi_period is set to 40 ms, which defines how often the UE reports channel quality. When multiple antennas are used, RI reporting is also enabled with m_ri set to 8, meaning the UE reports rank information at a slower periodicity derived from the CQI reporting interval. The transmission_mode is set to 3, which corresponds to TM3 and enables open-loop spatial multiplexing.

The measurement configuration defines how the UE evaluates LTE and NR signal conditions. For LTE, A1 and A2 events are configured using RSRP thresholds. A1 is used to indicate that the serving cell quality is good, and A2 is used to detect when the serving cell becomes weak. Each event includes hysteresis and time-to-trigger values to stabilize reporting.

For NSA setup, the most important part is the B1 event under en_dc_setup. This event configures inter-RAT measurement toward NR. The UE monitors NR signal strength and triggers a measurement report when the NR RSRP exceeds the configured threshold. The parameters b1_rsrp, b1_hysteresis, and b1_time_to_trigger define when this report is generated.

The meas_gap_config is set to gp0, which provides measurement gaps allowing the UE to measure NR frequencies while maintaining LTE connectivity.

Overall, this default configuration ensures consistent antenna behavior, periodic CSI reporting, and properly defined measurement conditions across all LTE cells, enabling reliable triggering of EN-DC setup when NR coverage is detected.

Perform the Test

In this step, you verify that all LTE and NR cells are loaded with the intended configuration by checking the cell phy output. This command shows the physical layer view of every configured cell, including RAT type, operating band, bandwidth, ARFCN, antenna setting, subcarrier spacing, and modulation related parameters.

From the output, you can confirm that LTE cell 1 is configured on band 2 with ARFCN 800, LTE cells 2, 3, and 4 are configured on band 46 with ARFCN 47290, 47488, and 47686, and LTE cell 5 is configured on band 66 with ARFCN 66836. You can also confirm that the NR cell is configured on band n78 with ARFCN 627300 and SSB information is present. This shows that both the LTE carrier aggregation cells and the NR cell for NSA are properly instantiated.

This is an important validation step before starting the actual attach and ENDC procedure. Even if the configuration file looks correct, the real confirmation is whether the running system reflects the intended band, frequency, bandwidth, and SCS values. If any cell is missing or any parameter is different from what you expected, the carrier aggregation or NSA setup may fail later.

Now run the t command on the eNB and monitor the trace while the UE performs the attach procedure. (If you have any issues with NR addition, refer to troubleshoot section)

As the UE connects, you will first see PRACH attempts from LTE cells, which indicates that the UE is performing random access and starting the connection establishment. Once the RRC connection is completed, the UE moves into normal operation and begins scheduling on LTE.

In the trace output, you can confirm that carrier aggregation is working by checking the CQI section. Multiple CQI values appear for different component carriers, which indicates that all configured LTE CCs are established and actively used.

After LTE is stable, the UE sends measurement reports for NR based on the B1 configuration. The eNB then triggers ENDC, and the NR cell is added as SCG. In the trace, this is reflected by additional entries corresponding to the NR cell, including its CQI and throughput related indicators.

At this point, you can see both LTE and NR activity in the trace. This confirms that ENDC is successfully established, LTE carrier aggregation is active, and the NR secondary cell is properly added and used for data transmission.

Log Analysis

Check out every details in the log. It will help you with understanding LTE CA and NSA protocol and troubleshoot process. Sample Log

The first step in any carrier aggregation test is to verify the UE capability exchange. In this log, the network sends a UE Capability Enquiry message to request the UE’s supported features.

The eNB sends UE capability enquiry to check UE support for specific LTE bands and EN-DC capability. Important parameter is requestedFrequencyBands, which includes band 2, band 46, and band 66. This means the network is explicitly asking whether the UE supports these bands for carrier aggregation.

The UE responds with UE capability information to indicate its supported LTE and NR features. Important parameters include bandInformationEUTRA for LTE bands and bandInformationNR for NR band support. In this case, NR band 78 is also included, which confirms that the UE supports EN-DC with LTE and NR combination.

The presence of MRDC band combinations in the response indicates that the UE supports dual connectivity between LTE and NR. This is a critical requirement for NSA operation.

This step is essential because if the UE does not report support for all required LTE bands or the NR band, the network will not proceed with carrier aggregation or EN-DC setup. Therefore, confirming the UE capability enquiry and response is the first validation point before analyzing further signaling.

For NSA capability verification, the network sends an additional UE Capability Enquiry that explicitly includes both LTE and NR requirements.

In this message, the network requests E-UTRA and NR capabilities together using the eutra-nr capability request. Important parameters include requestedFrequencyBands for LTE, which contains band 2, 46, and 66, and bandInformationNR, which includes NR band 78. This indicates that the network is checking whether the UE can support EN-DC with this specific LTE and NR band combination.

The UE responds with UE Capability Information that includes both LTE and NR capability structures. Important parameters are bandInformationEUTRA, which confirms support for LTE bands 2, 46, and 66, and bandInformationNR, which confirms support for NR band n78. The presence of MRDC related fields shows that the UE supports dual connectivity between LTE and NR.

This step is critical because NSA requires simultaneous support for both LTE anchor bands and the NR band. If the UE does not report support for this combination, the network will not proceed with adding the NR cell as SCG.

Overall, this second capability enquiry ensures that the UE is fully capable of operating in EN-DC mode with the specific LTE and NR band configuration used in the test.

In this step, instead of parsing the raw UE Capability Information message, you verify the UE capability using the summarized capability table, which provides a much clearer view of supported band combinations.

From the table, you can confirm that the UE supports LTE bands 2, 46, and 66, as well as NR band n78. The EUTRA combinations section shows various LTE carrier aggregation combinations, indicating that the UE can aggregate multiple LTE carriers across these bands.

More importantly, the EN-DC section lists the supported dual connectivity combinations between LTE and NR. You can see combinations where LTE bands 2, 46, and 66 are aggregated together and combined with NR band n78. This confirms that the UE supports the exact NSA configuration used in this test.

This verification is critical because even if individual LTE and NR bands are supported, EN-DC will only work if the specific band combination is supported by the UE. If the required combination is missing from this table, the NR cell will not be added during the procedure.

Overall, this table provides a quick and reliable way to confirm that the UE supports both LTE carrier aggregation and the LTE-NR dual connectivity combinations required for successful NSA operation.

Once the UE capability confirms support for the required LTE CA and EN-DC band combination, the eNB proceeds with RRC connection reconfiguration to configure measurement reporting.

In this message, the eNB sends RRC connection reconfiguration to define measurement objects for multiple LTE frequencies. Each measObject corresponds to a specific carrier frequency. Important parameters include carrierFreq, which indicates the target LTE frequency, and allowedMeasBandwidth, which defines the bandwidth for measurement.

In this example, measurement objects are configured for multiple LTE frequencies including 800, 47290, 47488, 47686, and 65535. This allows the UE to monitor all relevant LTE component carriers that may be used for carrier aggregation.

The presence of these multiple measurement objects means the UE is instructed to continuously evaluate signal quality across these frequencies. Based on this, the UE can report measurement results that help the network decide when to activate additional carriers or proceed with EN-DC setup.

This step is essential because EN-DC activation depends on measurement reports. Without properly configured measurement objects, the UE would not report the necessary information, and the NR cell addition procedure would not be triggered.

Overall, this RRC reconfiguration ensures that the UE is fully prepared to monitor LTE frequencies and provide the measurements required to initiate carrier aggregation and NSA operation.

In addition to LTE measurement objects, the eNB also configures measurement for the NR cell.

In this configuration, a measurement object for NR is defined with carrierFreq set to 624288. This value corresponds to the SSB frequency of the target NR cell rather than the exact center frequency. In NR measurements, the UE typically uses SSB-based measurements, so the configured frequency points to where synchronization signals are transmitted.

Important parameters include subcarrierSpacing, which defines the SSB subcarrier spacing, and quantityConfig, which specifies that the UE should measure SS-RSRP, SS-RSRQ, and SS-SINR. These metrics are used by the UE to evaluate NR signal quality.

The report configuration is based on event B1 for NR. This means the UE will trigger a measurement report when the NR signal becomes better than a configured threshold. Parameters like threshold, hysteresis, and timeToTrigger control when the report is generated to avoid unnecessary or unstable reporting.

The measId mapping connects this NR measurement object with the report configuration, ensuring that when the B1 condition is met, the UE sends the appropriate measurement report.

This configuration is critical for NSA operation because the NR cell is not added immediately. The UE must first detect sufficient NR signal quality and report it. Only after receiving this measurement report does the eNB proceed with adding the NR cell as SCG.

Overall, this step enables the UE to monitor the NR SSB frequency and trigger the event that initiates EN-DC setup.

After defining the NR measurement object, the report configuration is set using Event B1.

In this configuration, reportConfigId 1 defines the reporting condition for inter-RAT measurement toward NR. The triggerType is set to event, and eventId is configured as eventB1-NR. This means the UE will send a measurement report when the NR signal becomes better than a specified threshold. The parameter b1-ThresholdNR defines this threshold in terms of SS-RSRP, and hysteresis and timeToTrigger are used to avoid unstable or frequent triggering.

The report configuration also specifies reportQuantityCellNR, which includes ss-rsrp, ss-rsrq, and ss-sinr. This means the UE will report multiple NR signal quality metrics when the event is triggered.

The measId mapping links measObjectId 6, which corresponds to the NR measurement object, with reportConfigId 1. This association ensures that when the NR measurement meets the B1 condition, the UE generates a measurement report based on this configuration.

Once this setup is complete, the UE continuously monitors the NR SSB frequency. When the NR signal quality exceeds the configured threshold, Event B1 is triggered, and the UE sends a measurement report to the eNB.

This measurement report is the key trigger for EN-DC. Upon receiving it, the eNB proceeds with RRC connection reconfiguration to add the NR cell as SCG.

In the same RRCConnectionReconfiguration message, the eNB also configures CSI reporting for the LTE cells.

The eNB sends RRC connection reconfiguration to configure CSI reporting so that the UE can provide channel quality feedback for all LTE component carriers. Important parameters include cqi-ReportConfig, which defines how CQI is reported, and cqi-ReportPeriodic, which specifies that the reporting is periodic rather than aperiodic.

The configuration includes parameters such as cqi-PUCCH-ResourceIndex and cqi-pmi-ConfigIndex, which determine where and how the UE sends CQI and PMI reports on the uplink. The ri-ConfigIndex defines the reporting pattern for rank indication, which is important for MIMO operation.

The presence of simultaneousAckNackAndCQI set to true indicates that the UE can transmit ACK/NACK and CQI together, improving uplink efficiency when multiple carriers are active.

Additional configurations such as cqi-ReportConfig-v1130 and cqi-ReportConfigPCell-v1250 extend the reporting capability to support more advanced scenarios, including multiple serving cells and carrier aggregation.

This CSI configuration ensures that the UE continuously reports channel conditions for each LTE carrier. Based on these reports, the eNB can perform scheduling, link adaptation, and resource allocation efficiently across all aggregated LTE cells.

Overall, this step enables proper channel feedback for LTE carrier aggregation, which is essential for achieving high throughput and stable performance in the EN-DC setup.

In the same RRCConnectionReconfiguration message, the eNB starts building LTE carrier aggregation by adding a Secondary Cell.

The eNB sends RRC connection reconfiguration to add LTE cell with cellIndex-r10 1 as SCC. Important parameters are sCellToAddModList, which defines the list of secondary cells to be added, and sCellIndex-r10, which identifies this SCC within the UE context.

The parameter cellIdentification includes physCellId and dl-CarrierFreq, which specify the physical cell identity and frequency of the secondary LTE cell. In this case, dl-CarrierFreq corresponds to ARFCN 47290, meaning LTE cell 2 is being added as a secondary carrier.

The radioResourceConfigCommonSCell and radioResourceConfigDedicatedSCell sections define how this SCC operates, including bandwidth, antenna configuration, and transmission mode. The parameter crossCarrierSchedulingConfig is set so that scheduling remains independent, consistent with earlier configuration.

This step marks the beginning of LTE carrier aggregation. The UE now maintains the primary cell as PCell and adds this LTE cell as SCell. Additional LTE cells will be added in the same way to complete multi-carrier aggregation.

Overall, this configuration shows how the network incrementally builds LTE carrier aggregation before or alongside NR addition in the EN-DC procedure.

In the same RRCConnectionReconfiguration message, the eNB continues building LTE carrier aggregation by adding another Secondary Cell.

The eNB sends RRC connection reconfiguration to add LTE cell with sCellIndex-r10 set to 2 as SCC2. Important parameters are sCellToAddModList, which now includes this second secondary cell, and sCellIndex-r10, which uniquely identifies this cell within the UE context.

The parameter cellIdentification specifies physCellId and dl-CarrierFreq. In this case, dl-CarrierFreq corresponds to ARFCN 47488, which identifies LTE cell 3. This confirms that LTE cell 3 is being added as the second component carrier.

The configuration sections such as radioResourceConfigCommonSCell and radioResourceConfigDedicatedSCell define how this SCC operates, including bandwidth, antenna configuration, and transmission mode. The crossCarrierSchedulingConfig remains disabled, meaning each carrier operates with independent scheduling.

At this point, the UE maintains the primary LTE cell as PCell, while two secondary LTE cells are now configured as SCC1 and SCC2. This expands the available bandwidth through carrier aggregation.

Overall, this step shows the progressive addition of LTE component carriers, where each SCC is added with its own index and configuration, building toward full multi-carrier aggregation before or alongside NR addition in the EN-DC process.

In the same RRCConnectionReconfiguration message, the eNB continues expanding LTE carrier aggregation by adding another Secondary Cell.

The eNB sends RRC connection reconfiguration to add LTE cell with sCellIndex-r10 set to 3 as SCC3. Important parameters are sCellToAddModList and sCellIndex-r10, which identifies this third secondary cell within the UE context.

The parameter cellIdentification includes physCellId and dl-CarrierFreq. In this case, dl-CarrierFreq corresponds to ARFCN 47686, which indicates LTE cell 4 is being added as the third component carrier.

The radioResourceConfigCommonSCell and radioResourceConfigDedicatedSCell sections define the operating parameters of this SCC, including bandwidth, antenna configuration, and transmission mode. The crossCarrierSchedulingConfig remains disabled, meaning each carrier continues to operate with independent scheduling.

At this stage, the UE maintains one PCell and now three SCells, forming a larger LTE carrier aggregation group. This significantly increases the available bandwidth before the NR cell is added.

Overall, this step shows the sequential addition of LTE component carriers, where each new SCC is configured with its own index and frequency, building toward full carrier aggregation in preparation for EN-DC operation.

In the same RRCConnectionReconfiguration message, the eNB completes the LTE carrier aggregation setup by adding another Secondary Cell.

The eNB sends RRC connection reconfiguration to add LTE cell with sCellIndex-r10 set to 4 as SCC4. Important parameters are sCellToAddModList and sCellIndex-r10, which identifies this fourth secondary cell within the UE context.

The parameter cellIdentification includes physCellId and dl-CarrierFreq. In this case, dl-CarrierFreq corresponds to ARFCN 65535, indicating LTE cell 5 is being added as the fourth component carrier.

The radioResourceConfigCommonSCell and radioResourceConfigDedicatedSCell sections define the operating parameters for this SCC, including bandwidth, antenna configuration, and transmission mode. The crossCarrierSchedulingConfig remains disabled, so each carrier continues to operate independently.

At this point, the UE has one PCell and four SCells configured, meaning full LTE carrier aggregation is established across all configured LTE cells.

This completes the LTE aggregation stage. With all LTE component carriers active, the system is now ready for the next step, which is adding the NR cell as SCG to enable EN-DC and further increase throughput.

In the same RRCConnectionReconfiguration message, the eNB configures the NR radio bearer through nr-RadioBearerConfig1-r15.

The eNB sends RRC connection reconfiguration to establish NR data radio bearer for EN-DC. Important parameters include drb-ToAddModList, which defines the data radio bearer to be added, and eps-BearerIdentity, which links this NR bearer to the existing EPC bearer.

The parameter drb-Identity identifies the specific DRB instance, and pdcp-Config defines how data is handled at the PDCP layer. This includes settings such as discardTimer, PDCP sequence number length, and whether header compression is used. These parameters control reliability, reordering, and packet handling for the NR path.

The t-Reordering parameter defines how long the UE waits for out-of-order packets before delivering data to upper layers. This is important in EN-DC because data may arrive through both LTE and NR paths.

The securityConfig section defines the ciphering algorithm for NR communication. The keyToUse parameter indicates that the master key is used, ensuring that NR data transmission is properly secured.

This configuration is critical because adding the NR cell as SCG is not enough by itself. The data path must also be established. The NR radio bearer enables user data to flow over the NR link, allowing the UE to actually benefit from the added NR resources.

Overall, this step completes the EN-DC setup by configuring the NR data bearer, enabling simultaneous data transmission over LTE and NR.

After the measurement configuration is applied, the UE performs NR measurements and sends a measurement report to the eNB.

The UE sends measurement report to indicate the detected NR cell quality. Important parameters include measResultNeighCellsNR, which contains the measurement results for the NR cell, and pci, which identifies the NR cell (PCI 500 in this case).

The UE reports ss-rsrp, ss-rsrq, and ss-sinr values. These parameters represent the signal strength, signal quality, and signal-to-noise condition of the NR cell based on SSB measurements. These values are compared against the configured B1 threshold.

The report also includes measResultPCell and measResultServFreqList for LTE, which provide the current serving LTE cell measurements. This allows the eNB to evaluate both LTE and NR conditions together.

This measurement report is triggered by Event B1, meaning the NR signal has become strong enough to satisfy the configured condition. This is the key trigger point for EN-DC.

Once the eNB receives this report, it decides that the NR cell quality is sufficient and proceeds with adding the NR cell as SCG through another RRCConnectionReconfiguration.

Overall, this message confirms that the UE has detected the NR cell and that the conditions are met to move forward with NSA setup.

Once the eNB receives the NR measurement report, it proceeds with RRCConnectionReconfiguration to establish EN-DC.

The eNB sends RRC connection reconfiguration to add NR cell as SCG and complete NSA setup. Important parameters include secondaryCellGroup, which contains the full NR configuration delivered via LTE signaling.

Within this structure, cellGroupId identifies the NR secondary cell group. The rlBearerToAddModList defines the radio bearers that will use the NR resources. The logicalChannelIdentity and servedRadioBearerIdentity map the data flow between LTE and NR.

The rlc-Config defines how data is handled at the RLC layer, including parameters such as sequence number length, retransmission behavior, and reassembly timers. These are important for ensuring reliable data delivery over the NR link.

The mac-LogicalChannelConfig defines prioritization and scheduling behavior for the NR data channels. Parameters like priority, bucketSizeDuration, and logicalChannelGroup determine how traffic is handled across LTE and NR.

The physical layer configuration for NR is also included in this message, although it is encapsulated within the secondaryCellGroup container. This configuration enables the UE to synchronize, perform random access, and start communication with the NR cell.

This step is the key transition point in NSA. Until now, LTE handled all communication. After this message, the UE establishes a connection with the NR cell and starts using it as the Secondary Cell Group.

Overall, this RRCConnectionReconfiguration message completes the EN-DC setup, allowing simultaneous data transmission over LTE (MCG) and NR (SCG).

After the RRCConnectionReconfiguration is applied, you can verify that the NR cell (n78) is successfully added as the Secondary Cell Group.

The eNB sends RRCConnectionReconfiguration to configure the secondaryCellGroup, and the UE processes this message to establish the NR connection. Inside this configuration, spCellConfig defines the primary serving cell of the NR SCG.

The parameter absoluteFrequencySSB 624288 indicates the SSB frequency of the NR cell, confirming that the configured NR carrier matches the earlier measurement configuration. The frequencyBandList shows band 78, which confirms that the NR cell belongs to n78.

The subcarrierSpacing and carrierBandwidth parameters define the NR numerology and bandwidth, indicating how the UE should interpret the NR signal. These parameters ensure proper synchronization and demodulation.

The initialDownlinkBWP and pdcch-ConfigCommon sections define the initial bandwidth part and control channel configuration for the NR cell. This allows the UE to start decoding NR control information.

The presence of spCellConfig within the secondaryCellGroup confirms that the NR cell is now actively configured as SCG. This is the final confirmation that EN-DC setup is complete.

At this point, the UE is connected to LTE as MCG and NR as SCG, enabling dual connectivity and allowing data to be transmitted over both LTE and NR simultaneously.

After all RRC procedures are completed, the activation moves from signaling to actual data-plane readiness through MAC control.

The eNB sends MAC Control Elements to activate the configured Secondary Cells. In this log, MAC indicates “enabling scell 1”, “enabling scell 2”, “enabling scell 3”, and “enabling scell 4”. This means all configured LTE secondary component carriers are now being activated.

These MAC CE commands are the final step for LTE Carrier Aggregation. Although the SCCs were already configured earlier via RRCConnectionReconfiguration, they remain inactive until this MAC-level activation is performed.

Each “enabling scell” corresponds to one LTE secondary cell. This activates additional carriers for data transmission, increasing throughput by allowing simultaneous use of multiple LTE bands.

This step happens quickly after RRC reconfiguration and does not require additional UE signaling. The UE simply applies the MAC command and starts using the activated SCCs.

At this point, LTE Carrier Aggregation is fully operational with multiple SCCs, and together with the already established NR SCG, the system achieves full EN-DC operation with both LTE CA and NR dual connectivity active.

After NR is configured as SCG, the UE must complete the RACH procedure on the NR cell to finalize the addition.

The UE sends PRACH to initiate random access toward the NR cell. In the log, this is shown as PRACH with sequence index and timing information. This indicates that the UE is attempting to access the NR cell.

The gNB responds with RAR (Random Access Response), which provides timing advance and uplink grant. This step confirms that the NR cell has detected the UE’s PRACH.

The UE then transmits Msg3 using the allocated uplink resource. This carries the RRC-related or MAC information needed to complete the access procedure.

After that, contention resolution is performed. The presence of C-RNTI and successful decoding indicates that the UE is successfully identified and the random access process is completed.

Once this RACH process is completed successfully, the NR SCG is fully operational. The UE can now transmit and receive data on the NR cell.

This step is critical because many NSA failures occur here. Even if RRC configuration is correct, failure in PRACH detection, timing alignment, or contention resolution will prevent NR addition.

So this log confirms that the NR cell addition is not only configured but also physically established and usable for data transmission.

After LTE carrier aggregation and NR SCG addition are fully completed, the system transitions into steady-state operation where both LTE and NR actively carry traffic and report channel conditions.

The UE sends CSI reports for LTE through PUCCH, indicating channel quality for each LTE component carrier. At the same time, CSI reports for the NR cell are also transmitted, showing that the NR link is fully operational and being monitored.

These CSI reports include parameters such as CQI, PMI, and RI, which the network uses to optimize scheduling, modulation, coding, and MIMO transmission. Separate CSI reporting for LTE and NR confirms that both MCG and SCG are independently contributing to data transmission.

Along with CSI reporting, continuous UL and DL data traffic flows through both LTE and NR bearers. The presence of regular PUSCH and PDSCH activity indicates that user data is being transmitted over aggregated LTE carriers and the NR carrier simultaneously.

This stage confirms that the entire EN-DC setup is stable. LTE provides the anchor connection and multiple aggregated carriers, while NR provides additional high-throughput capacity.

Overall, this log verifies that the system has moved beyond setup and into normal operation, where both LTE and NR are fully utilized for data transfer and link adaptation.

RRC / NAS Signaling

: This section is to show you the overall structure of important Rrc messages and Information IE (IE) that are related to this tutorial. It is not intended to describe the details on every RRC/NAS Information elements. With the overall structure and key IEs shown here, it hope it would be easier / clearer to go through the sample log provided in this tutorial or any logs that you captured from your own test setup or live network.

NOTE : The purpose of this section is to show you the overall structure of the related Rrc messages and some key information elements. It is not to show the every details of the IE which is too much to be covered. I would suggest you to go through the sample log for further details of signaling flow and the contents of each message.

rrcConnectionReconfiguration for NR Addition

: This is the RRC message sent by eNB (LTE) to add NR. (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: rrcConnectionReconfiguration {

  rrc-TransactionIdentifier 0,

  criticalExtensions c1: rrcConnectionReconfiguration-r8 {

    ...

    nonCriticalExtension {

      nonCriticalExtension {

        nonCriticalExtension {

          nonCriticalExtension {

            nonCriticalExtension {

              nonCriticalExtension {

                nonCriticalExtension {

                  nonCriticalExtension {

                    nr-Config-r15 setup: {

                      endc-ReleaseAndAdd-r15 FALSE,

                      nr-SecondaryCellGroupConfig-r15 {

                        rrc-TransactionIdentifier 0,

                        criticalExtensions rrcReconfiguration {

                          secondaryCellGroup {

                            cellGroupId 1,

 

                            rlc-BearerToAddModList {

                              ...

                            },

 

                            mac-CellGroupConfig {

                              ...

                            },

 

                            physicalCellGroupConfig {

                              pdsch-HARQ-ACK-Codebook dynamic

                            },

 

                            spCellConfig {

                              servCellIndex 1,

 

                              reconfigurationWithSync {

                                spCellConfigCommon {

                                  physCellId 500,

 

                                  downlinkConfigCommon {

                                    frequencyInfoDL {

                                      absoluteFrequencySSB 632256,

 

                                      frequencyBandList {

                                        78

                                      },

 

                                      absoluteFrequencyPointA 632016,

 

                                      scs-SpecificCarrierList {

                                        {

                                          offsetToCarrier 0,

                                          subcarrierSpacing kHz30,

                                          carrierBandwidth 51

                                        }

                                      }

                                    },

 

                                    initialDownlinkBWP {

                                      genericParameters {

                                        locationAndBandwidth 13750,

                                        subcarrierSpacing kHz30

                                      },

 

                                      pdcch-ConfigCommon setup: {

                                        ...

                                      },

 

                                      pdsch-ConfigCommon setup: {

                                        ...

                                      }

                                    }

                                  },

 

                                  uplinkConfigCommon {

                                    frequencyInfoUL {

                                      scs-SpecificCarrierList {

                                        {

                                          offsetToCarrier 0,

                                          subcarrierSpacing kHz30,

                                          carrierBandwidth 51

                                        }

                                      }

                                    },

 

                                    initialUplinkBWP {

                                      genericParameters {

                                        locationAndBandwidth 13750,

                                        subcarrierSpacing kHz30

                                      },

 

                                      rach-ConfigCommon setup: {

                                        ...

                                      },

 

                                      pusch-ConfigCommon setup: {

                                        ...

                                      },

 

                                      pucch-ConfigCommon setup: {

                                        ...

                                      }

                                    }

                                  },

 

                                  dummy ms500,

                                  ssb-PositionsInBurst mediumBitmap: '80'H,

                                  ssb-periodicityServingCell ms20,

                                  dmrs-TypeA-Position pos2,

                                  ssbSubcarrierSpacing kHz30,

 

                                  tdd-UL-DL-ConfigurationCommon {

                                    ...

                                  },

 

                                  ss-PBCH-BlockPower -28

                                }

                              },

 

                              rlf-TimersAndConstants setup: {

                                ...

                              },

 

                              spCellConfigDedicated {

                                initialDownlinkBWP {

                                  pdcch-Config setup: {

                                    ...

                                  },

 

                                  pdsch-Config setup: {

                                    ...

                                  },

 

                                  radioLinkMonitoringConfig setup: {

                                    ...

                                  }

                                },

 

                                firstActiveDownlinkBWP-Id 0,

 

                                uplinkConfig {

                                  initialUplinkBWP {

                                    pucch-Config setup: {

                                      ...

                                    },

 

                                    pusch-Config setup: {

                                      ...

                                    },

 

                                    srs-Config setup: {

                                      ...

                                    }

                                  },

 

                                  firstActiveUplinkBWP-Id 0,

 

                                  pusch-ServingCellConfig setup: {

                                  }

                                },

 

                                pdcch-ServingCellConfig setup: {

                                },

 

                                pdsch-ServingCellConfig setup: {

                                  nrofHARQ-ProcessesForPDSCH n16

                                },

 

                                csi-MeasConfig setup: {

                                  ...

                                },

 

                                tag-Id 0

                              }

                            }

                          }

                        }

                      },

 

                      sk-Counter-r15 0,

 

                      nr-RadioBearerConfig1-r15 {

                        drb-ToAddModList {

                          {

                            drb-Identity 1,

                            reestablishPDCP true,

 

                            pdcp-Config {

                              moreThanOneRLC {

                                primaryPath {

                                  cellGroup 1,

                                  logicalChannel 4

                                },

 

                                ul-DataSplitThreshold b0

                              }

                            }

                          }

                        },

 

                        securityConfig {

                          ...

                        }

                      }

                    }

                  }

                }

              }

            }

          }

        }

      }

    }

  }

}

Tips

Changing Configuration File

When you create a your own configuration file, I strongly recommend you to copy a file from an existing example files as shown below. I suggest NOT to change the default configuration files that are provided by the installation software. These default files would overwritten by the new version when you install (or upgrade / downgrade) the new software release and you may lose your configuration.

Step 1 : Copy an existing configuration file to another file that you want to configure as shown in the following example.

Step 2 : Change the contents of the copied file as you want using a text editor as shown in the following example.

Step 3 : Make a symbolic link from the configuration file to enb.cfg as shown below.

Step 4 : Check if the symbolic link is properly made

Troubleshoot

Based on our observation, it seems that most of commercial UEs that claims to support NR NSA works well with Amarisoft Callbox. Most of the difficulties with NSA test that users faces comes from mismatch between UE NR band support and Callbox configuration or failing to meet RRC measurement criteria in terms of configuration or cell power during the test.

I would suggest you to go through each and every items in this section and check all of them one by one if you have any difficulties in getting NSA working

Requirement for UE Capability Information

By default, Amarisoft gNB triggers 'measurement report requestfor NR' and 'NR addition' based on UE Capability Information from UE. Followings are the configuration and the required UE Capability Information.

Requirement for UE Network Capability

Check out Attach Request message and make it sure that the UE support DCNR.

UE network capability:

0xf0 (EEA0=1, 128-EEA1=1, 128-EEA2=1, 128-EEA3=1, EEA4=0, EEA5=0, EEA6=0, EEA7=0)

0x70 (EIA0=0, 128-EIA1=1, 128-EIA2=1, 128-EIA3=1, EIA4=0, EIA5=0, EIA6=0, EIA7=0)

0xc0 (UEA0=1, UEA1=1, UEA2=0, UEA3=0, UEA4=0, UEA5=0, UEA6=0, UEA7=0)

0x40 (UCS2=0, UIA1=1, UIA2=0, UIA3=0, UIA4=0, UIA5=0, UIA6=0, UIA7=0)

0x19 (ProSe-dd=0, ProSe=0, H.245-ASH=0, ACC-CSFB=1, LPP=1, LCS=0, 1xSRVCC=0, NF=1)

0x80 (ePCO=1, HC-CP CIoT=0, ERw/oPDN=0, S1-U data=0, UP CIoT=0, CP CIoT=0, ProSe-relay=0, ProSe-dc=0)

0xb0 (15 bearers=1, SGC=0, N1mode=1, DCNR=1, CP backoff=0, RestrictEC=0, V2X PC5=0, multipleDRB=0)

Requirement for UE Capability Equniry

In order to get the UE capability information for both LTE and NR, you should send UE capability enquiry with both nr and uetra-nr requested as shown below. (NOTE : If you don't see this message firs to check if dcnr_support: true is configured in mme configuration)

message c1: ueCapabilityEnquiry {   rrc-TransactionIdentifier 0,     criticalExtensions c1: ueCapabilityEnquiry-r8 {     ue-CapabilityRequest {       nr,       eutra-nr     },       nonCriticalExtension {       nonCriticalExtension {         nonCriticalExtension {           nonCriticalExtension {             nonCriticalExtension {                 requestedFreqBandsNR-MRDC-r15 {                 bandInformationEUTRA: {                   bandEUTRA 3                 },                   bandInformationNR: {                   bandNR 78                 }               },                 nonCriticalExtension {                 nonCriticalExtension {                     requestedCapabilityNR-r15 {                   },                     nonCriticalExtension {                     nonCriticalExtension {                       rrc-SegAllowed-r16 enabled                     }                   }                 }               }             }           }         }       }     }   } }

Requirement for measurement request

If NR-B1 is configured in meas_config_desc, UE Capability Information should carry supportedBandListEN-DC-r15. This IE should contain the NR band you configured in the enb.cfg. Following is an example for this parameter.

NOTE : Make it sure that the NR band you configured in configuration file is listed in this IE, otherwise gNB does not configure the NR in "measConfig -> measObjectToAddModList" in RrcConnectionReconfiguration

irat-ParametersNR-r15 { en-DC-r15 supported, supportedBandListEN-DC-r15 { { bandNR-r15 1 }, { bandNR-r15 78 } } },

Requirement for NR addition

To let gNB to trigger NR addition in RRC, UE Capability Information should carry. This IE should contain the LTE andNR band you configured in the enb.cfg. Following is an example for this parameter. (NOTE : Especially pay attention to whether UE informs of supportedBandCombinationList and it shows the specific band combination that you configured in enb.cfg )

NOTE : Make it sure that the NR band you configured in configuration file is listed in this IE, otherwise gNB does trigger the NR addition in RrcConnectionReconfiguration.

srf-ParametersMRDC {   supportedBandCombinationList {     {       bandList {         eutra: {           bandEUTRA 1,           ca-BandwidthClassDL-EUTRA a,           ca-BandwidthClassUL-EUTRA a         },           nr: {           bandNR 78,           ca-BandwidthClassDL-NR a,           ca-BandwidthClassUL-NR a         }       },         featureSetCombination 0,         mrdc-Parameters {         dynamicPowerSharingENDC supported,         simultaneousRxTxInterBandENDC supported       },         powerClass-v1530 pc2     }   } }

Common Issues

These are common issues that you may come across for NSA call setup. Whenever you have any issues even when LTE attach is completed, always check out Requirement for UE Capability Information first and make it sure that all the requirement is met. And then check out the points listed below.

Uninteded Measurement Configuration

: If you see the unintended Measurement Configuration as shown in the left column of the following table, it is highly likely that you have following issues

• UE does not support NSA band combination that you configured in the configuration file. ==> Possible Solution : Change the band combination that are supported by the UE and make it sure that you get all the required UE capability Information as described in Requirement for UE Capability Information section.

Uninteded Measurement Configuration	Intended Measurement Configuration
measObjectToAddModList with only for MGC (LTE Cell). No SCG cell.No reportConfigToAddModList and No measIdToAddModList	measObjectToAddModList with both MCG(LTE) and SCG(NR) and reportConfigToAddModList and measIdToAddModList
message c1: rrcConnectionReconfiguration {   rrc-TransactionIdentifier 0,     criticalExtensions c1: rrcConnectionReconfiguration-r8 {     measConfig {       measObjectToAddModList {         {           measObjectId 1,           measObject measObjectEUTRA: {             carrierFreq 300,             allowedMeasBandwidth mbw100,             presenceAntennaPort1 TRUE,             neighCellConfig '01'B           }         }       },         quantityConfig {         quantityConfigEUTRA {         }       },         measGapConfig release: NULL     }   } }	message c1: rrcConnectionReconfiguration {   rrc-TransactionIdentifier 0,     criticalExtensions c1: rrcConnectionReconfiguration-r8 {     measConfig {       measObjectToAddModList {         {           measObjectId 1,           measObject measObjectEUTRA: {             carrierFreq 300,             allowedMeasBandwidth mbw100,             presenceAntennaPort1 TRUE,             neighCellConfig '01'B           }         },           {           measObjectId 2,           measObject measObjectNR-r15: {             carrierFreq-r15 632256,               rs-ConfigSSB-r15 {               measTimingConfig-r15 {                 periodicityAndOffset-r15 sf20-r15: 0,                 ssb-Duration-r15 sf1               },                 subcarrierSpacingSSB-r15 kHz30             },               quantityConfigSet-r15 1,             bandNR-r15 setup: 78           }         }       },         reportConfigToAddModList {         {           reportConfigId 1,           reportConfig reportConfigInterRAT: {             triggerType event: {               eventId eventB1-NR-r15: {                 b1-ThresholdNR-r15 nr-RSRP-r15: 56,                 reportOnLeave-r15 FALSE               },                 hysteresis 0,               timeToTrigger ms100             },               maxReportCells 8,             reportInterval ms120,             reportAmount r1,               reportQuantityCellNR-r15 {               ss-rsrp TRUE,               ss-rsrq TRUE,               ss-sinr TRUE             }           }         }       },         measIdToAddModList {         {           measId 1,           measObjectId 2,           reportConfigId 1         }       },         quantityConfig {         quantityConfigEUTRA {           filterCoefficientRSRP fc3         },           quantityConfigNRList-r15 {           {             measQuantityCellNR-r15 {               filterCoeff-RSRP-r15 fc3             }           }         }       },         measGapConfig setup: {         gapOffset gp0: 16       }     }   } }

Uninteded Measurement Event Configuration

: If you are trying to do measurement based NSA (i.e, NR Addition only after the expected measurement report) or various types of cell changes after NSA setup, you need to carefully check on the logics of measurement Event application. Even if various events are explicitely configured in meas_config_desc, whether they are applied to RRC Connection Reconfiguration or not is determined by various factors. Read carefully on the description of meas_config_descforLTE and meas_config_desc for NR in enb document for the details. For ENDC case, the logic would become even more complicated. So it is strongly suggested to read the entire section carefully before you start testing.

No Measurement Report

: If you don't have any measurement report even when you have no problem with UE capability Information and Intended Measurement Configuration as described above, I would recommend you to check followings

• Check if all the necessary antenna (or cable) is connected to sdr for NR (sdr 1 - the second sdr card by default).
• Check tx_gain and if the gain is is property set for your test setup. (Refer to this note to check and change tx_gain)
• Make it sure that cell_gain is set to 0 (the default value) for every cell. (Refer to this note to check the current cell gain for each of the cells)
• (If there is no problem with items listed above), check on UE log (or any display) to see if UE detects any power on NR cell (you may need to get access to UE log or any monitoring App for your DUT for this).

SCG Failure

: You may have some problem even after everything mentioned above went OK. One of the most common failure would be to get SCG Failure Information. SCG Failure happens in various stages and mode, UE send SCGFailureInformation with a specific cause. So the thing you need to do at this stage is to check out the cause specified in SCGFailureInformation and handle the problem accordingly. Check out this note for the description of each cause of SCG failure.