NR SA CORESET0

The purpose of this tutorial is Not about creating any specific test cases. This is more about information sharing on how CORESET0 in NR SA is configured automatically by gNB software and how you can configure it manually when you want. SSB positioning and selecting an appropriate CORESET0 resource is one of the most complicated and confusing process in NR protocol, but Amari gNB specifies SSB and corresponding CORESET0 automatically. Of course, you can specify it manually as you like if you want any specific configuration.  This tutorial will show you how you can figure out the automatically set configuration and how you can manually change the configuration if you need.

It is assumed that you already have basic understandings on what is the CORESET (If you are not familiar with the concept of the coreset itself, I would suggest to check out this note). CORESET0 is a specially designed coreset only SIB1 scheduling. The details of this CORESET (i.e, SIB1 scheduling information) cannot be broadcasted to UE). Why not ?   Except MIB(PBCH), SIB1 is the first broadcast message, so there should be some other mechanism to provide the details of SIB1 sheduling to UE. The technique that 3GPP adopted for this is as follows.

• i) define various predefined set of configuration in 3GPP specification (both gNB and UE should have these predefined table in it)
• ii) Inform the UE on which table and which index of the table to use via MIB (PBCH)

The summary of this mechanism would be illustrated as below (as per my understanding).

Image Source : SIB1 decoding Procedure in Sharetechnote

In 3GPP, SSB SCS,PDCCH SCS, Min BW determines which table to apply and the MIB parameter determines the index of the selected table.  In Amarisoft gNB, SSB SCS,PDCCH SCS, Min BW determines which table to apply and the index of the table is specified in enb.cfg. (The index specified in the configuration file is populated in MIB).

Table of Contents

• NR SA CORESET0
• Introduction
• Summary of the Tutorial
• Automatic Configuration
• Example 1 >  CBW 20 Mhz
• Example 2 >  CBW 40 Mhz
• Example 3 >  CBW 10 Mhz
• Common Errors for CORESET Resource Allocation
• Example 1 >  Offset too big
• Example 2 >  Frequency Span too wide
• RRC / NAS Signaling
• MIB (SA)

Introduction

In the landscape of 5G New Radio (NR) Standalone (SA) deployments, the configuration of Control Resource Set 0 (CORESET0) is a critical aspect of initial cell access and broadcast operations. CORESET0 is a specially designated time-frequency resource used for scheduling the first System Information Block (SIB1) after the Master Information Block (MIB) is delivered to User Equipment (UE). This tutorial provides an in-depth look at how CORESET0 is automatically configured by gNB (next-generation NodeB) software, particularly in solutions such as Amarisoft gNB, and how operators or engineers can manually override these settings when specific configurations are desired. The selection and positioning of Synchronization Signal Blocks (SSBs) and their association with CORESET0 is governed by complex rules and standardized tables defined by 3GPP, which both the gNB and UE must interpret consistently. Since details regarding SIB1 scheduling cannot be dynamically broadcast to UEs before SIB1 itself is delivered, the 3GPP specification provides a mechanism where predefined configuration tables are referenced using parameters transmitted via the MIB on the Physical Broadcast Channel (PBCH). This mechanism ensures interoperability and efficient initial access across devices from different vendors. Understanding how these configurations are selected—either automatically by the gNB or manually by the operator—is essential for optimizing network deployment, troubleshooting access issues, and ensuring compliance with 3GPP standards. This tutorial aims to equip you with the knowledge to interpret the gNB's default behavior, recognize the mapping between SSBs and CORESET0, and perform manual configuration as needed to meet specific requirements or deployment scenarios.

• Context of CORESET0 Configuration in NR SA
  • 5G NR introduces a flexible and dynamic resource allocation framework, where the initial system information delivery is tightly coupled with CORESET0 configuration.
  • CORESET0 is crucial for SIB1 scheduling, which follows the initial synchronization established by the MIB and SSBs.
  • Automatic configuration by gNB software (e.g., Amarisoft) simplifies deployment, but manual configuration enables fine-tuning for specialized scenarios.
• Relevance and Importance of the Tutorial Topic
  • Correct CORESET0 configuration is essential for reliable UE access, proper system information acquisition, and overall network performance.
  • Misconfiguration or misunderstanding of CORESET0 and SSB mapping can lead to access failures or interoperability issues between UEs and the gNB.
  • This tutorial demystifies the automatic and manual configuration processes, helping network engineers ensure robust and standards-compliant deployments.
• What You Will Learn
  • How CORESET0 is automatically determined by gNB software based on predefined 3GPP tables and broadcast parameters.
  • How to interpret which CORESET0 configuration is active using both MIB parameters and gNB configuration files.
  • Practical steps to override the automatic configuration and manually specify CORESET0 parameters for custom deployment needs.
  • Understanding the linkage between SSB positioning, subcarrier spacing, bandwidth, and corresponding CORESET0 selection.
  • Best practices for ensuring compatibility and compliance with the 3GPP specification.
• Prerequisite Knowledge and Skills
  • Familiarity with the fundamentals of 5G NR, including SSB, CORESET, and system information broadcasting.
  • Basic understanding of how gNBs are configured, particularly with Amarisoft or similar platforms.
  • General knowledge of 3GPP specifications and the role of MIB and SIB1 in NR cell access procedures.
  • Optional: Experience with reading and interpreting configuration files (such as enb.cfg) and understanding broadcast channel parameters.

Summary of the Tutorial

This tutorial provides a detailed overview of the procedures for verifying and troubleshooting the automatic configuration of SSB and CORESET0 resources using the Amari gNB software, as well as identifying common misconfigurations related to CORESET0 resource allocation.

• Automatic Configuration Test Procedures
  •   The Amari gNB software automatically assigns SSB (Synchronization Signal Block) and CORESET0 configurations if these are not explicitly defined in the configuration file. This includes parameters such as ssb_arfcn, k_ssb, ssb_prb, coreset0_prb (position of coreset0), and coreset0_idx.
  •   The assigned values are printed as metadata in the gNB logfile. Users are advised to check the beginning of the logfile for these automatically configured values to ensure that the software is running correctly.
  • Example 1: 20 MHz Channel Bandwidth
    •   Set channel bandwidth to 20 MHz and subcarrier spacing to 30 kHz.
    •   The software automatically determines and logs SSB and CORESET0 parameters.
  • Example 2: 40 MHz Channel Bandwidth
    •   Set channel bandwidth to 40 MHz and subcarrier spacing to 30 kHz.
    •   The software automatically determines and logs SSB and CORESET0 parameters.
  • Example 3: 10 MHz Channel Bandwidth
    •   Set channel bandwidth to 10 MHz and subcarrier spacing to 30 kHz.
    •   The software automatically determines and logs SSB and CORESET0 parameters.
    •   Manual configuration is not recommended for narrow bandwidth scenarios due to increased complexity.
  •   Users may override the automatic configuration by manually specifying SSB and CORESET0 positions in the configuration file, but this is generally not recommended unless necessary.
• Common Error Identification Procedures for CORESET0 Resource Allocation
  •   The section outlines typical misconfigurations that may cause CORESET0 allocation errors and provides test cases to help users identify and rectify them.
  • Example 1: Offset Too Big
    •   Occurs when the CORESET0 boundary exceeds the channel bandwidth due to an excessively large offset value, even though the CORESET0 bandwidth is narrower than the CBW.
  • Example 2: Frequency Span Too Wide
    •   Happens when the configured CORESET0 bandwidth is wider than the channel bandwidth.
    •   Specifically, the number of resource blocks (n_rb_coreset0) assigned to CORESET0 exceeds the maximum supported for the given channel bandwidth and subcarrier spacing.
    •   For instance, assigning 48 resource blocks for CORESET0 is invalid if the channel bandwidth supports fewer than 48 resource blocks.
  •   These examples are intended to help users recognize and correct misconfiguration issues by adjusting relevant parameters.
• Additional Notes
  •   The tutorial briefly mentions that the Amarisoft Callbox does not print full MIB (PBCH) contents in the trace log, but metadata related to CORESET0 is included in the log for verification.
  •   For further details on parameter definitions or in-depth technical references, users are directed to external resources.

Automatic Configuration

If you don't specify SSB and CORESET0 configuration manually, those are set automatically by Amari gNB. Most of the sample configurations that are installed by the installation package uses the automatic configuration (meaning that those configurations are not set explicitely in the configuration file). Followings are some of the examples showing the result of automatic configuration.  You can check the specified SSB and coreset0 resource allocation from the gnb log file as shown below. (NOTE : If you don't see these information at the beginning of log file when you open it in text editor, it would imply that you are using very old software or you misconfigured something in enb.cfg and gNB is not properly initiated).

The example below shows this automatic behavior. First, you can check the cell physical configuration from the gNB console. In this example, the main DL ARFCN, bandwidth, antenna count, numerology, and other basic radio parameters are taken from the configuration file. However, some parameters such as the SSB ARFCN and CORESET0-related values are automatically derived by the gNB.

You can also confirm the same information from the gNB log file. Near the beginning of the log, the gNB prints the final cell configuration that it actually uses during runtime. This is useful because it shows not only the parameters explicitly configured in enb.cfg, but also the parameters that were automatically calculated by the software.

In the example log, the following values are shown.

• dl_nr_arfcn=632628
• ssb_nr_arfcn=632544
• ssb_prb=12:20
• k_ssb=0
• coreset0_prb=0:48
• coreset0_idx=10

Here, dl_nr_arfcn comes from the configured downlink frequency. The ssb_nr_arfcn is automatically selected based on the downlink ARFCN and the valid SSB raster rule defined by 3GPP. The ssb_prb and k_ssb values define the position of the SSB relative to the carrier resource grid. The coreset0_prb and coreset0_idx values define where CORESET0 is located and which predefined CORESET0 configuration index is used.

This is an important point when debugging NR SA initial access. Even if you do not specify SSB and CORESET0 explicitly in the configuration file, the gNB still needs to choose valid values internally. Therefore, the best way to check the actual configuration is to look at the beginning of the gNB log file.

If you do not see this information near the beginning of the log file when opening it in a text editor, it may indicate that you are using a very old software version, that the configuration is incorrect, or that the gNB was not properly initialized.

Example 1 >  CBW 20 Mhz

In this example, bandwith is configured to be 20Mhz and subcarrier spacing is configured to be 30Khz. Based on this, ssb_arfcn, k_ssb, ssb_prb, coreset0_prb (position of coreset0) and coreset0_idx are all automatically set by LTE software and printed in the logfile as metat data. (NOTE : you can manually specify SSB position, coreset 0 position manually in the configuration file, but it is recommended to let lte software automatically configure it unless you really want to configure them by yourself)

From the cell phy command, you can first check the basic cell configuration. In this example, the DL ARFCN is 632628, the bandwidth is 20 MHz, and the subcarrier spacing is 30 kHz. These are the main parameters configured in the configuration file.

The SSB ARFCN is shown as 632544. This value is not explicitly configured in the example configuration file. It is automatically selected by the gNB based on the configured carrier frequency and the valid SSB raster rule.

The same information is also printed near the beginning of the gNB log file. In the log, you can see the following automatically selected values.

• ssb_nr_arfcn=632544
• ssb_prb=12:20
• k_ssb=0
• coreset0_prb=0:48
• coreset0_idx=10

Here, ssb_prb and k_ssb indicate the SSB position relative to the carrier resource grid. coreset0_prb indicates the frequency-domain location of CORESET0, and coreset0_idx indicates the CORESET0 configuration index selected from the predefined 3GPP table.

This means that even though these values are not written explicitly in the configuration file, the gNB still calculates and applies valid SSB and CORESET0 parameters during runtime. For most normal test cases, it is recommended to let the software configure these values automatically. Manual configuration is useful only when you need to force a specific SSB position or CORESET0 location for a special test purpose.

Example 2 >  CBW 40 Mhz

In this example, bandwith is configured to be 40Mhz and subcarrier spacing is configured to be 30Khz. Based on this, ssb_arfcn, k_ssb, ssb_prb, coreset0_prb (position of coreset0) and coreset0_idx are all automatically set by LTE software and printed in the logfile as metat data. (NOTE : you can manually specify SSB position, coreset 0 position manually in the configuration file, but it is recommended to let lte software automatically configure it unless you really want to configure them by yourself)

From the cell phy command, you can check the configured carrier information first. In this example, the DL ARFCN is 632628, the bandwidth is 40 MHz, and the subcarrier spacing is 30 kHz. These values define the basic NR carrier configuration.

Compared to the 20 MHz case, the carrier center frequency is the same, but the channel bandwidth is wider. Because of this, the valid SSB position and CORESET0 position selected by the gNB can be different.

In this example, the SSB ARFCN is shown as 631968. This value is automatically selected by the gNB. It is not manually configured in the example configuration file.

The same automatically selected values are also printed near the beginning of the gNB log file.

• ssb_nr_arfcn=631968
• ssb_prb=15:21
• k_ssb=12
• coreset0_prb=3:48
• coreset0_idx=10

Here, ssb_prb and k_ssb indicate the SSB position relative to the carrier resource grid. coreset0_prb indicates the frequency-domain location of CORESET0, and coreset0_idx indicates the predefined CORESET0 configuration index used by the UE to find SIB1 scheduling.

This example shows that even when the DL ARFCN and subcarrier spacing are the same, changing the channel bandwidth can result in a different automatically selected SSB position and CORESET0 position. Therefore, when checking or debugging NR SA initial access, it is important to verify the actual runtime values from the gNB log, not only the values written in the configuration file.

For most normal test cases, it is recommended to let Amarisoft gNB configure these values automatically. Manual configuration is mainly useful when you need to force a specific SSB or CORESET0 location for a special test scenario.

Example 3 >  CBW 10 Mhz

In this example, bandwith is configured to be 10Mhz and subcarrier spacing is configured to be 30Khz. Based on this, ssb_arfcn, k_ssb, ssb_prb, coreset0_prb (position of coreset0) and coreset0_idx are all automatically set by LTE software and printed in the logfile as metat data. (NOTE : you can manually specify SSB position, coreset 0 position manually in the configuration file, but it is recommended to let lte software automatically configure it unless you really want to configure them by yourself. Especially for the narrow bandwidth as in this csae, it would be challenging to set these parameters manually)

From the cell phy command, you can first check the basic cell configuration. In this example, the DL ARFCN is 632628, the bandwidth is 10 MHz, and the subcarrier spacing is 30 kHz. These are the main carrier parameters configured in the configuration file.

The SSB ARFCN is shown as 632640. This value is automatically selected by the gNB. It is not explicitly configured in the example configuration file.

The same automatically selected values are also printed near the beginning of the gNB log file.

• ssb_nr_arfcn=632640
• ssb_prb=2:21
• k_ssb=12
• coreset0_prb=0:24
• coreset0_idx=2

Here, ssb_prb and k_ssb indicate the SSB position relative to the carrier resource grid. coreset0_prb indicates the frequency-domain location of CORESET0, and coreset0_idx indicates the predefined CORESET0 configuration index used for SIB1 scheduling.

Compared to the 20 MHz and 40 MHz examples, this 10 MHz case has a much narrower carrier bandwidth. Because of this, there is less room to place SSB and CORESET0 inside the carrier. The automatically selected CORESET0 bandwidth is also smaller, as shown by coreset0_prb=0:24.

This is why manual configuration can be more difficult in narrow bandwidth cases. The SSB, CORESET0, and carrier bandwidth must all satisfy the allowed 3GPP combinations. If one parameter is changed manually without considering the others, the resulting configuration may become invalid or the UE may fail to decode SIB1.

For this reason, it is usually better to let Amarisoft gNB configure these values automatically unless you have a specific reason to force a certain SSB or CORESET0 position.

Common Errors for CORESET Resource Allocation

Followings are some of the common misconfigurations causing CORESET0 related errors. (NOTE : This is not the exhaustive list of misconfigurations. These are only examples of common misconfiguration and you may come across various other cases as well). In the examples below, the configuration is intentionally changed to create errors. However, the same parameters can also be used to fix CORESET0-related problems when the automatically selected values need to be adjusted manually.

The most basic rule is that CORESET0 should be placed safely within the channel bandwidth. Since CORESET0 is used for SIB1 scheduling, the UE must be able to monitor the corresponding PDCCH region after decoding MIB. If CORESET0 is placed outside the valid carrier bandwidth, or if the selected CORESET0 bandwidth is too large for the configured carrier, the configuration becomes invalid.

Another common error is placing CORESET0 too far from the SSB. In NR initial access, the UE detects SSB first and then uses the information from MIB to determine where to monitor CORESET0 for SIB1. Therefore, the relationship between SSB and CORESET0 is not arbitrary. The selected CORESET0 configuration must satisfy the allowed relationship defined by the 3GPP tables.

As illustrated in the figure, a valid case is when CORESET0 is fully inside the configured channel bandwidth and has a valid relationship with the SSB position.

One invalid case is when the CORESET0 bandwidth is wider than the configured channel bandwidth. In this case, CORESET0 cannot fit inside the carrier, so the gNB cannot create a valid initial-access configuration.

Another invalid case is when the offset between SSB and CORESET0 is too large. Even if CORESET0 itself is inside the carrier bandwidth, the selected SSB and CORESET0 combination may not match any valid predefined 3GPP configuration.

A third invalid case is when the SSB is moved closer to the carrier bandwidth boundary, causing the associated CORESET0 position to fall outside the channel bandwidth. This can easily happen when manually adjusting SSB ARFCN, k_ssb, ssb_prb, or CORESET0-related parameters without checking the final calculated position.

For this reason, manual CORESET0 configuration should be done carefully. When an error occurs, first check the final runtime values printed in the gNB log, such as ssb_nr_arfcn, ssb_prb, k_ssb, coreset0_prb, and coreset0_idx. These values usually give the clearest indication of whether the SSB and CORESET0 relationship is valid or not.

Example 1 >  Offset too big

This is an example where the CORESET0 bandwidth itself is not wider than the configured channel bandwidth, but the selected CORESET0 position becomes invalid because the offset is too large.

In this test, the channel bandwidth is configured as 10 MHz and the subcarrier spacing is 30 kHz. Then coreset0_index is manually set to 4 in the configuration file.

This value was intentionally selected to create an error. With this carrier bandwidth and frequency configuration, the selected CORESET0 index results in a CORESET0 position that cannot be placed properly within the valid channel bandwidth.

When the gNB starts, it checks whether the selected SSB frequency and CORESET0 parameters can create a valid initial-access configuration. In this case, the check fails and the gNB prints the following error.

Could not find a SSB frequency compatible with the channel bandwidth and the CoReSet #0 parameters: modify dl_nr_arfcn or the CoReSet #0 parameters, or use ssb_nr_arfcn or gscn to manually set the SSB frequency.

This error means that the gNB could not find a valid combination of SSB position and CORESET0 position for the configured carrier. The problem is not simply that CORESET0 is too wide. The problem is that, with the selected coreset0_index, the required CORESET0 placement has too much offset and cannot be fitted into the carrier in a valid way.

To fix this kind of problem, you can change coreset0_index to another valid value, modify dl_nr_arfcn, or manually specify the SSB frequency using ssb_nr_arfcn or gscn. In most normal cases, the easiest and safest solution is to remove the manual CORESET0 setting and let Amarisoft gNB select the SSB and CORESET0 configuration automatically.

Example 2 >  Frequency Span too wide

This is the case where the coreset 0 bandwidthis wider than the configured channel bandwidth. This case can be interpreted as follows :

• The number of RB of the configured coreset 0(n_rb_coreset0) is larger than the max number of RB for the configured channel bandwidth (You can check out the max number of RB for each channel bandwidth and subcarrier spacing in this note)
• For example, you cannot allocate coreset 0 with the NRB(number of RB) of 48 for the channel bandwidth with the max NRB of smaller than 48 (e.g, CBW 5Mhz with SCS 15Khz or CBW 10Mhz with SCS 30Khz).

In this test, the channel bandwidth is configured as 10 MHz and the subcarrier spacing is 30 kHz. With this bandwidth and subcarrier spacing, the number of available RBs in the carrier is limited. However, the configuration manually sets n_rb_coreset0 to 48.

This creates an invalid configuration because CORESET0 requires 48 RBs, but the configured carrier bandwidth does not have enough RBs to contain that CORESET0 allocation. For example, you cannot allocate a 48 RB CORESET0 inside a carrier whose maximum available RB count is smaller than 48, such as 10 MHz with 30 kHz SCS.

In the configuration file, the problematic part is as follows.

n_rb_coreset0: 48

n_symb_coreset0: 1

This setting was intentionally selected to cause an error. The issue is not mainly the number of CORESET0 symbols. The main problem is the frequency-domain span of CORESET0. The configured CORESET0 bandwidth is too large for the configured carrier bandwidth.

When the gNB starts, it tries to find a valid SSB frequency and CORESET0 placement that satisfies the channel bandwidth and CORESET0 parameters. Since the requested CORESET0 size cannot fit into the carrier, the gNB fails and prints the following error.

Could not find a SSB frequency compatible with the channel bandwidth and the CoReSet #0 parameters: modify dl_nr_arfcn or the CoReSet #0 parameters, or use ssb_nr_arfcn or gscn to manually set the SSB frequency.

This error means that the selected CORESET0 parameters cannot be used with the current carrier configuration. To fix this, reduce n_rb_coreset0 to a value that fits within the configured channel bandwidth, change to a wider channel bandwidth, or remove the manual CORESET0 setting and let Amarisoft gNB select a valid CORESET0 configuration automatically.

In most cases, the automatic configuration is safer because the gNB selects CORESET0 parameters together with the SSB position, carrier bandwidth, and 3GPP-defined CORESET0 table constraints.

RRC / NAS Signaling

MIB (SA)

: Amarisoft Callbox does not print out the full contents of MIB (PBCH) in the trace log (The MIB contents related to CORESET 0 is printed in the log at meta data section as shown above). The ASN.1 structure of NR SA MIB is as shown below.

NOTE: For further details of each of the parameters, refer to this note from sharetechnote.com