Amarisoft

NR SA SRS : Codebook

The purpose of this tutorial is to show you how to test SRS in NR SA. In this tutorial, it is assumed that you are faimiliar with basic operations of Amari Callbox operation. So in this tutorial, I will explain only about the configuration and analyzing the test result in the WebGUI log.  This tutorial is mainly for SRS configuraton in default configuration (gnb-sa.cfg) with usage=codebook. For SRS with usage = antenna switching, refer to this tutorial.

SRS is a kind of reference signal for Uplink (i.e, transmitted by UE) so that gNB can perform channel quality estimation for uplink. gNB can perform UL channel estimation from PUSCH DMRS, but PUSCH DMRS is transmitted only when PUSCH is scheduled and only with the bandwidth in which PUSCH is scheduled. On the contrary, SRS can be transmitted independantly of PUSCH scheduling and PUSCH bandwidth(number of PUSCH RB).

In short, the role of SRS is similar to CSI RS. CSI-RS is a reference signal for downlink channel quality estimation independent of PDSCH DMRS and SRS is a reference signal for uplink channel quality estimation independent of PUSCH DMRS

SRS plays more important role in NR because TDD is dominant mode of deployment. In TDD, gNB can utilize the channel estimation result from SRS not only for UL scheduling but also for DL scheduling as well based on channel reciprocity in TDD.

Table of Contents

Introduction

Sounding Reference Signal (SRS) in 5G New Radio (NR) Standalone (SA) is a critical uplink reference signal that enables the gNB (next-generation NodeB) to perform precise uplink channel quality estimation, independent of scheduled uplink data transmissions. Unlike PUSCH (Physical Uplink Shared Channel) DMRS (Demodulation Reference Signal), which is only present during active uplink transmissions and limited to the allocated bandwidth, SRS can be transmitted at configurable intervals and bandwidths, providing the gNB with a broader and more flexible mechanism to gather channel state information. This capability is particularly significant in Time Division Duplex (TDD) deployments, which are predominant in NR, as it allows the gNB to exploit channel reciprocity for both uplink and downlink scheduling. SRS thus fulfills a role analogous to CSI-RS (Channel State Information Reference Signal) in the downlink, facilitating efficient and dynamic resource allocation, beamforming, and link adaptation in the uplink. Within the context of test environments like the Amari Callbox, SRS configuration and analysis are essential skills for engineers seeking to validate NR uplink performance, understand SRS signaling behavior, and optimize radio resource management. This tutorial focuses on the practical aspects of configuring SRS in the default gNB standalone configuration using the "codebook" usage mode and provides guidance on interpreting test results via the WebGUI log, thereby equipping users with the expertise required to effectively test and analyze SRS in NR SA systems.

Summary of the Tutorial

This tutorial details multiple test procedures for configuring and verifying Sounding Reference Signal (SRS) operation in a 5G NR Standalone (SA) environment using Amarisoft systems. The focus is on low-layer testing, emphasizing configuration steps and log analysis to validate SRS behavior. The tests cover manual and automatic SRS resource setups, periodic and aperiodic triggering, codebook and non-codebook usage, and bandwidth configuration.

Test Setup

Test setup for this tutorial is as shown below.  This is just for low layer testing, you may not need any complicated IP layer setup.

TestSetup Callbox UE 1sdr 01

Key Configuration Parameters

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

Reference Configuration  : Auto SRS Configuration

NOTE : This feature is supported after 2022-09-16. If you are using the older version or you want to configure the SRS configuration as per your own requirement, refer to various Test configurations shown in this tutorial. If you don't care much of the detailed SRS configuration and you just need some configuration good enough to get SRS signal from UE, I would recommend you to use the auto configuration as in gnb-sa.cfg file. This section is not for testing anything.. this is just to show how the SRS is configured by default for information sharing purpose. The detailed configuration shown in the RRC message varies depending on the number of UL antenna, BWP bandwidth and TDD Pattern you selected in the configuration. The example shown in this section is based on UL SISO and TDD Pattern 2 in gnb-sa.cfg.

Configuration

From the release 2022-09-16, the default configuration gnb-sa.cfg itself already configured auto srs, but I copied the gnb-sa.cfg and renamed to gnb-sa-srs-auto-condebook.cfg just because I changed one parameter "#define USE_SRS".  (NOTE :I suggest you to copy and change name for any configuration file if you made even the slightest change (like even a single parameter) from the default configuration.)

NR SA SRS ReferenceConfig Config 01

In the configuration file, you can select a specific TDD pattern by using the parameter NR_TDD_CONFIG. Before applying the TDD configuration, you first need to set the duplex mode parameter NR_TDD to 1. This means that the cell is configured as NR TDD. In this example, NR_TDD_CONFIG is set to 2, which is one of the default sample TDD configurations provided in the Amarisoft sample configuration.(NOTE : This is just for this sample test. TDD is not mandatory for SRS operation). And then make it sure that you set USE_SRS to 1 to enable srs configuration. )

This TDD setting is used only for this sample test. TDD itself is not mandatory for SRS operation. SRS can also be configured in FDD. However, TDD is commonly used in NR, and SRS is especially useful in TDD because the uplink channel estimation can also help downlink scheduling and beamforming based on channel reciprocity.

In this example, USE_SRS is set to 1. This enables SRS configuration. With this setting, Amarisoft automatically generates the required SRS configuration according to the selected cell configuration, such as TDD pattern, NR bandwidth, number of uplink antennas, and BWP configuration.

In the shown configuration, NR_TDD is set to 1, so the cell operates in TDD mode. FR2 is set to 0, so the configuration is for FR1. NR_TDD_CONFIG is set to 2 in the FR1 case, and NR_BANDWIDTH is set to 20. N_ANTENNA_DL is set to 2, meaning the downlink is configured for 2 antenna ports. N_ANTENNA_UL is set to 1, meaning the uplink is configured as SISO. Finally, USE_SRS is set to 1, which enables periodic SRS.

When USE_SRS is enabled, the SRS resources are automatically configured. Therefore, in this auto SRS configuration example, you do not need to manually define each SRS resource, SRS resource set, periodicity, offset, or frequency-domain allocation. These details are generated internally by Amarisoft and can be checked later in the RRC message and WebGUI log.

NR SA SRS ReferenceConfig Config 02

You can configure SRS with automatic resource configuration by using the resource_auto parameter inside the srs object. With this method, you do not need to manually define all the detailed SRS resource parameters one by one. You only need to specify the basic SRS usage type and the transmission period, and Amarisoft automatically generates the detailed SRS resource configuration.

In this example, resource_auto is used with codebook configuration. The resource_type is set to periodic, which means that the UE transmits SRS repeatedly at a fixed interval. The period is set to 80, meaning that the SRS is transmitted every 80 slots.

This configuration is useful when you want to enable SRS quickly without manually configuring parameters such as SRS resource ID, SRS resource set ID, frequency-domain position, comb size, cyclic shift, number of symbols, start position, and slot offset. These detailed parameters are automatically selected by Amarisoft based on the current cell configuration, such as bandwidth, TDD pattern, BWP configuration, and uplink antenna configuration.

After applying this configuration, the actual SRS resource generated by Amarisoft can be checked in the RRC message. In the WebGUI log, you can also verify whether the UE is configured with SRS and whether SRS transmission is observed according to the configured periodicity.

NR SA SRS ReferenceConfig Config 03

The following table shows an example comparison between the old manual SRS configuration and the newer auto SRS configuration. From this comparison, you can see how much simpler the configuration becomes when the auto SRS feature is used.

Before auto SRS was supported, you had to configure many SRS-related parameters manually. For example, you had to define srs_symbols differently depending on the selected NR_TDD_CONFIG value. You also had to manually configure srs_resource, including resource ID, number of ports, resource type, period, c_srs, b_srs, and b_hop. In addition, you had to configure srs_resource_set, including the SRS resource list, slot offset, and usage.

With auto SRS configuration, most of these detailed parameters are no longer required in the configuration file. You only need to enable the resource_auto section under srs and specify the basic codebook configuration. In this example, resource_type is set to periodic and period is set to 80 slots. Based on this information, Amarisoft automatically generates the required SRS resource and SRS resource set.

Another important point is that srs_symbols is not explicitly configured in the auto SRS example. This is because Amarisoft automatically determines the proper SRS symbol location based on the selected TDD configuration. Therefore, the SRS symbol allocation can adapt to the selected NR_TDD_CONFIG without requiring the user to manually prepare a different srs_symbols list for each TDD pattern.

In short, the old configuration gives you full manual control, but it requires more detailed knowledge and more parameters. The auto SRS configuration is much simpler and is suitable when your main purpose is to enable SRS and verify SRS operation, rather than testing a very specific SRS resource structure.

Configuration without AutoSRSI

Configuration with AutoSRS
This is the configuration in gnb-sa.cfg before AutoSRS feature is supported This is the configuration in gnb-sa.cfg after AutoSRS feature is supported

#if USE_SRS

    srs: {

#if NR_TDD

#if NR_TDD_CONFIG == 1 || NR_TDD_CONFIG == 2

      srs_symbols: [ 0, 0, 0, 0, 0, 0, 0, 2, 0, 0 ],

#elif NR_TDD_CONFIG == 3

      srs_symbols: [ 0, 0, 0, 0, 0, 0, 2, 0, 0, 0 ],

#elif NR_TDD_CONFIG == 4

      srs_symbols: [ 0, 0, 0, 4, 0, 0, 0, 0, 0, 0 ],

#elif NR_TDD_CONFIG == 10

      srs_symbols: [ 0, 0, 0, 2, 0 ],

#endif

#else

      srs_symbols: [ 1, 0, 0, 0, 0, 1, 0, 0, 0, 0 ],

#endif

      srs_resource: [

        {

          srs_resource_id: 0,

          n_ports: N_ANTENNA_UL,

          resource_type: "periodic",

          period: 80, /* in slots */

          c_srs: 13,

          b_srs: 1,

          b_hop: 0,

        }

      ],

      srs_resource_set: [

        {

          srs_resource_id_list: [ 0 ],

          slot_offset: 7,

          usage: "codebook",

        },

      ],

    },

#endif

#if USE_SRS

    srs: {

      resource_auto: {

        codebook: {

          resource_type: "periodic",

          period: 80, /* in slots */

        }

      }

    },

#endif

Log Analysis

This section is only to show the association between the configuration shown above and the corresponding IE in the RRC message. This check is not mandatory for normal SRS testing, but it is useful when you want to understand how the configuration is reflected in the actual RRC signaling.

First, I would check SIB1 and look at scs-SpecificCarrierList and initialDownlinkBWP. This is mainly to confirm that enough bandwidth is allocated for the carrier and the initial BWP before checking the SRS configuration in detail.

In the SIB1 message, scs-SpecificCarrierList shows the carrier-level bandwidth configuration. In this example, the subcarrier spacing is kHz30 and carrierBandwidth is set to 51. This means that the carrier bandwidth is configured with 51 resource blocks for 30 kHz subcarrier spacing.

Then, initialDownlinkBWP shows the bandwidth and location of the initial downlink BWP. In this example, genericParameters includes locationAndBandwidth 13750 and subcarrierSpacing kHz30. This indicates how the initial BWP is positioned and how much bandwidth is assigned to it.

This step is not directly checking SRS itself. However, it gives a useful reference point because the SRS configuration generated later is based on the overall cell and BWP configuration. If the carrier bandwidth, BWP bandwidth, or subcarrier spacing is different, the automatically generated SRS resource configuration may also be different.

After confirming this basic bandwidth information from SIB1, you can move to the RRC Reconfiguration message and check the actual SRS configuration assigned to the UE. In the WebGUI log, you can also see PHY log entries showing SRS reception. These entries confirm that the UE is transmitting SRS and that the gNB is receiving and measuring it.

NR SA SRS ReferenceConfig Log 01

By the same logic, I would also check scs-SpecificCarrierList and initialUplinkBWP in SIB1 to make sure that enough uplink bandwidth has been allocated for the SRS configuration.

In the SIB1 message, uplinkConfigCommon includes frequencyInfoUL. Under this IE, scs-SpecificCarrierList shows the uplink carrier bandwidth configuration. In this example, subcarrierSpacing is set to kHz30 and carrierBandwidth is set to 51. This means that the uplink carrier is configured with 51 resource blocks using 30 kHz subcarrier spacing.

Then, initialUplinkBWP shows the bandwidth and location of the initial uplink BWP. In this example, genericParameters includes locationAndBandwidth 13750 and subcarrierSpacing kHz30. This indicates that the initial uplink BWP is configured with the same subcarrier spacing and corresponding bandwidth allocation.

This check is useful because SRS is an uplink reference signal, and the generated SRS resource must fit within the configured uplink carrier and BWP. If the uplink BWP is too narrow, or if the subcarrier spacing and bandwidth configuration are different from what you expected, the automatically generated SRS configuration may also be different.

Again, this step does not directly verify the SRS resource itself. It only confirms the basic uplink frequency-domain configuration from SIB1. After this, the actual SRS resource and SRS resource set should be checked in the RRC Reconfiguration message, where the UE-specific SRS configuration is provided.

NR SA SRS ReferenceConfig Log 02

Now check how srs-Config is configured in the RRC Setup message. Since auto SRS configuration is used, these values are not manually selected one by one in the configuration file. However, it is still useful to check them because it shows how Amarisoft automatically generated the actual SRS configuration from the selected BWP bandwidth and TDD pattern.

In the RRC Setup message, srs-Config is included under the uplink BWP configuration. In this example, srs-ResourceSetToAddModList includes one SRS resource set. The resource set has srs-ResourceSetId 0 and points to srs-ResourceId 0. The resourceType is configured as aperiodic, and usage is set to codebook. This shows that the generated SRS configuration is intended for codebook-based operation.

The same srs-Config also includes srs-ResourceToAddModList. In this example, srs-ResourceId 0 is configured with one SRS port. The transmission comb, cyclic shift, resource mapping, frequency-domain position, frequency-domain shift, frequency hopping, and group/sequence hopping parameters are all automatically generated. These are the detailed physical SRS resource parameters that the UE will use for SRS transmission.

You can also see that the SRS bandwidth-related parameters such as c-SRS, b-SRS, and b-hop are configured in the RRC message. These values are not directly written in the simple auto SRS configuration, but Amarisoft selects them internally based on the cell bandwidth, BWP configuration, and TDD pattern.

After checking the RRC Setup message, you can verify the actual SRS reception from the PHY log. In the WebGUI log, SRS entries appear repeatedly, showing that the gNB is receiving SRS from the UE. The log includes measured values such as power, SNR, EPRE, timing advance, and uplink CQI. This confirms that the UE has received the SRS configuration and is transmitting SRS as expected.

NR SA SRS ReferenceConfig Log 03

Test 1 : Periodic/Codebook SRS

The purpose of this test is to show you how to configured the detailed srs configuration manually. It is a little bit complicated to configure comparing to auto configuration, but the advatage is that you can configure the detailed configuration as you want.

Configuration

I have used gnb-sa-srs.cfg which is copied and modified from gnb-sa.cfg.

NR SA SRS Config 01

I am using the default mme, ims config as shown below.

NR BWP Test1 Configuration 02

In gnb-sa-srs.cfg, I made a modification as follows (this is because the commercial UE that I have support TDD only. You may use whatever configuration that your UE support). Note that I set USE_SRS to 1 to enable SRS configuration.

In the configuration file, you can select any specific tdd pattern with the parameter NR_TDD_CONFIG.  To apply TDD configuration, you first need to configure the duplex mode (NR_TDD) to 1 (TDD). And then I set NR_TDD_CONFIG to 2 which is one of default sample configuration provided by Amarisoft sample configuration. (NOTE : This is just for this sample test. TDD is not mandatory for SRS operation).

NR SA SRS Config 02

In the tutorial, I will try a couple of tests with the modification to the parameters highlighted below. In default configuration, c_srs, b_srs, b_hop is not configured and the call box will use the default configuration if it is not configured in the configuration file.

NOTE : In the configuration in this release (2022-01-17), resource periodicity slot offset is configured automatically by callbox. It is not user configurable.  The slot offset in periodicity is configured differently for each SRS resources depending on the overall cell configuration. You can check up RRC message for the specific slot offset applied for each srs resources.

The main purpose of this test is to manually configure c_srs, b_srs, and b_hop and check how these parameters affect SRS operation. These three parameters are related to SRS bandwidth configuration. Check out this note if you are new to SRS bandwidth configuration details.

In this example, SRS is configured manually under the srs object. Unlike the auto SRS configuration, the srs_symbols list is explicitly configured depending on the selected NR_TDD_CONFIG. This defines which symbols can be used for SRS transmission according to the selected TDD pattern.

The srs_resource section defines the actual SRS resource. In this example, srs_resource_id is set to 0 and n_ports is set to N_ANTENNA_UL. The resource_type is set to periodic, so the UE transmits SRS periodically. The period is set to 80, meaning that the SRS transmission repeats every 80 slots.

The highlighted part shows the bandwidth-related parameters. c_srs is set to 13, b_srs is set to 1, and b_hop is set to 0. These values determine the SRS bandwidth and hopping behavior. In simple terms, c_srs selects the SRS bandwidth configuration table entry, b_srs selects the actual SRS bandwidth level within that configuration, and b_hop controls whether frequency hopping is applied or not.

The srs_resource_set section connects the SRS resource to the SRS resource set. In this example, srs_resource_id_list includes resource 0, so the resource set uses the SRS resource defined above. The slot_offset is set to 7, which defines the slot offset for periodic SRS transmission. The usage is set to codebook, meaning that this SRS is used for codebook-based operation.

With this manual configuration, you can change c_srs, b_srs, and b_hop as needed and then check the generated RRC message and PHY log to see how the SRS bandwidth and transmission behavior are changed.

NR SA SRS Config 03

Perform the Test

Testing process is simple. You only have to do NR SA attach (See NR SA Attach tutorial if you are not familiar with the process). The important part is to check the log and verify if you get the SRS as configured.

Log Analysis

First, check the RRC log and confirm whether the configuration is generated as intended. In this tutorial, I am checking SIB1 for the channel bandwidth and BWP information, and then checking the RRC Setup message for the SRS configuration.

From SIB1, you can first check the uplink carrier bandwidth information. In the highlighted scs-SpecificCarrierList, subcarrierSpacing is set to kHz30 and carrierBandwidth is set to 51. This means that the uplink carrier is configured with 51 resource blocks using 30 kHz subcarrier spacing.

Next, check initialUplinkBWP. In this example, initialUplinkBWP includes locationAndBandwidth 13750 and subcarrierSpacing kHz30. This confirms that the initial uplink BWP is configured with 30 kHz subcarrier spacing and that the BWP bandwidth/location information is properly included in SIB1.

This step is useful because SRS is an uplink signal, and the SRS resource must be configured within the available uplink carrier and BWP. Before checking the detailed SRS resource parameters, it is good to confirm that the basic uplink bandwidth and BWP configuration are what you expected.

After confirming the uplink bandwidth and BWP information in SIB1, move to the RRC Setup message and check the UE-specific srs-Config. This is where you can verify whether the manually configured SRS parameters, such as resource type, period, slot offset, usage, c-SRS, b-SRS, and b-hop, are reflected correctly in the actual RRC message.

NR SA SRS Log 01

You can confirm the SRS resource configuration and periodicity from the srs-Config IE in the RRC Setup message.

In this example, srs-ResourceSetToAddModList includes srs-ResourceSetId 0, and this resource set refers to srs-ResourceId 0. The resourceType is configured as periodic, and usage is set to codebook. This confirms that the SRS resource set is configured for periodic codebook-based SRS operation.

Then, check srs-ResourceToAddModList. This part shows the detailed SRS resource configuration. In this example, srs-ResourceId 0 is configured with one SRS port. The transmission comb is configured with comb offset and cyclic shift values, and the resource mapping shows the SRS symbol position, number of symbols, and repetition factor.

You can also confirm the frequency-domain configuration from the same IE. The parameters freqDomainPosition, freqDomainShift, c-SRS, b-SRS, and b-hop are shown in the RRC message. These values should match the intended manual configuration. In this example, c-SRS is 13, b-SRS is 3, and b-hop is 0.

The periodicity and slot offset can be checked under resourceType periodic. In this example, periodicityAndOffset is shown as sl80 with offset 7. This means that the SRS is configured with an 80-slot period and slot offset 7. This matches the manual configuration where period is set to 80 and slot_offset is set to 7.

So, from this RRC Setup message, you can verify that the manually configured SRS resource, SRS resource set, usage, bandwidth-related parameters, and periodic timing information are properly reflected in the actual UE-specific RRC configuration.

NR SA SRS Log 02

After the UE is attached, you can check whether the SRS is received by the call box. For easier analysis, it is useful to set the WebGUI filter as shown in the example. Set Layer to PHY and set Info to SRS. Then the log shows only the SRS-related PHY entries received by the gNB.

From this filtered log, you can verify both the SRS periodicity and the SRS bandwidth pattern. The periodicity can be checked from the consecutive SFN/slot values. In this example, SRS entries appear repeatedly with a fixed interval, which confirms that the UE is transmitting SRS according to the configured periodic resource type.

You can also check the SRS bandwidth pattern from the prb field in the PHY log. The prb value is printed in the form of prb=S:N. Here, S means the starting PRB, and N means the number of consecutive PRBs used for the SRS transmission. For example, if the log shows prb=4:4, it means that the SRS starts from PRB 4 and occupies 4 consecutive PRBs.

By checking the prb value over multiple SRS entries, you can see how the SRS resource is allocated in the frequency domain. If frequency hopping or different bandwidth-related parameters are configured, the starting PRB or occupied PRB range may change according to the configured SRS bandwidth pattern.

The PHY log also shows other useful measurement values such as symbol index, SNR, EPRE, timing advance, and uplink CQI. These values confirm not only that SRS is being received, but also give a rough indication of the received signal quality. Therefore, this filtered SRS view is useful for confirming that the configured SRS resource is actually transmitted by the UE and detected by the gNB.

NR SA SRS Log 03

Sub Test 1 : SRS with default configuration

In this test, I set the srs configuration as follows. (NOTE : As of Release 2022-03-10, slot offset in period is not user configurable. It is automatically configured by Callbox software. If you want to know of the slot offset that is used for your test, you need to check Rrc message and check srs configuration there)

The main purpose of this test is to remove c_srs, b_srs, and b_hop from the configuration and let the Callbox apply the default SRS bandwidth configuration. With this test, you can check how the default SRS bandwidth-related parameters are generated when they are not explicitly configured by the user.  Check out this note if you are new to SRS bandwidth configuration details.

In this configuration, the SRS resource is still configured manually, but only the basic parameters are specified. The resource_type is set to periodic, so the UE transmits SRS periodically. The period is set to 80, meaning that the SRS transmission repeats every 80 slots.

The bandwidth-related parameters c_srs, b_srs, and b_hop are not included in this configuration. Therefore, the Callbox automatically selects the default values for these parameters. These generated values should be checked later in the RRC Setup message under the srs-Config IE.

The srs_resource_set section connects the SRS resource to the SRS resource set. In this example, srs_resource_id_list includes resource 0, and usage is set to codebook. The slot_offset is set to 7 in the configuration, but depending on the Amarisoft release and configuration style, the actual periodicity offset should always be confirmed from the RRC message.

By comparing this test with the previous test where c_srs, b_srs, and b_hop were explicitly configured, you can see how the default SRS bandwidth configuration is selected by the Callbox and how it affects the SRS bandwidth pattern observed in the PHY log.

NR SA SRS Test 1 01

Check whether SRS is received with the configured interval and frequency-domain position. For easier analysis, filter the WebGUI log so that only SRS entries are shown. In this example, Layer is set to PHY and Info is set to SRS. Then the log displays only the SRS signals received by the gNB.

From this filtered log, you can check the SRS periodicity from the consecutive SFN/slot values. In this example, the SRS entries appear every 80 slots. This matches the configured period value of 80, so you can confirm that the periodic SRS timing is working as expected.

You can also check the frequency-domain allocation from the prb field. The prb value is printed in the format prb=S:N. Here, S means the starting PRB, and N means the number of consecutive PRBs used by the SRS signal.

For example, prb=41:4 means that the SRS starts from PRB 41 and occupies 4 consecutive PRBs. In the log, the number after the colon is 4, so this indicates that the SRS is transmitted over 4 PRBs. The starting PRB changes over time, but the same bandwidth pattern repeats.

This confirms that the UE is transmitting SRS periodically and that the gNB is receiving it with the expected bandwidth pattern. By comparing the RRC srs-Config and the PHY SRS log together, you can verify both the configured SRS resource and the actual received SRS behavior.

NR SA SRS Test 1 02

Sub Test 2 : SRS with c_srs 13, b_srs 1, b_hop 0

In this test, I changed the SRS bandwidth-related parameters manually and configured c_srs to 13, b_srs to 1, and b_hop to 0. The purpose of this test is to check how the SRS bandwidth and frequency-domain allocation change when these parameters are explicitly configured.

The overall SRS configuration is the same as the previous test. The resource_type is set to periodic, so the UE transmits SRS periodically. The period is set to 80, meaning that the SRS transmission repeats every 80 slots. The SRS resource is included in srs_resource_id_list, and the usage is set to codebook.

The main difference in this test is the highlighted part. Here, c_srs is set to 13, b_srs is set to 1, and b_hop is set to 0. These parameters control the SRS bandwidth configuration. c_srs selects the SRS bandwidth configuration entry, b_srs selects the SRS bandwidth level within that entry, and b_hop controls the frequency hopping behavior.

Since b_hop is set to 0 in this example, frequency hopping is not enabled. Therefore, the SRS transmission should follow the bandwidth and frequency-domain pattern determined by c_srs and b_srs without hopping behavior.

After applying this configuration, you should check the RRC Setup message first and confirm that c-SRS 13, b-SRS 1, and b-hop 0 are reflected correctly in the srs-Config IE. Then check the PHY SRS log in WebGUI. By looking at the prb field, you can confirm the actual starting PRB and the number of consecutive PRBs used by the SRS signal. Comparing this result with the previous default configuration helps you understand how the selected SRS bandwidth parameters affect the actual SRS transmission pattern.

NR SA SRS Test 2 01

Check whether SRS is received with the configured interval and frequency-domain position. As in the previous test, it is easier to analyze the result if you filter the WebGUI log so that only SRS entries are shown. In this example, Layer is set to PHY and Info is set to SRS. Then the log shows only the SRS signals received by the gNB.

From the filtered log, you can check the SRS periodicity from the consecutive SFN/slot values. In this example, the SRS entries appear every 80 slots, so the periodicity matches the configured period value of 80.

You can also check the SRS bandwidth pattern from the prb field. The prb value is printed in the format prb=S:N. Here, S indicates the starting PRB, and N indicates the number of consecutive PRBs used for the SRS signal.

In this test, the log shows values such as prb=25:24 and prb=1:24. This means that the SRS occupies 24 consecutive PRBs. The starting PRB changes between different SRS transmissions, but the bandwidth size remains 24 PRBs. This is different from the previous default configuration example, where the SRS occupied 4 PRBs.

This result shows that changing c_srs to 13 and b_srs to 1 changes the SRS bandwidth allocation. The UE is still transmitting SRS periodically every 80 slots, but the frequency-domain bandwidth used by SRS is now wider. By comparing the RRC srs-Config and the PHY SRS log, you can confirm that the configured SRS bandwidth parameters are reflected in the actual received SRS pattern.

NR SA SRS Test 2 02

Sub Test 3 : SRS with c_srs 13, b_srs 0, b_hop 0

In this test, I changed the SRS bandwidth-related parameters again and configured c_srs to 13, b_srs to 0, and b_hop to 0. The purpose of this test is to check how the SRS bandwidth and frequency-domain allocation change when b_srs is changed from the previous test.

The basic SRS configuration is the same as before. The resource_type is set to periodic, so the UE transmits SRS periodically. The period is set to 80, meaning that the SRS transmission repeats every 80 slots. The SRS resource is included in the SRS resource set, and the usage is set to codebook.

The main change in this test is the value of b_srs. In the previous sub test, c_srs was 13 and b_srs was 1. In this test, c_srs is still 13, but b_srs is changed to 0. Since b_srs controls the SRS bandwidth level within the selected c_srs configuration, changing this value can change the number of PRBs used by the SRS signal.

b_hop is set to 0, so frequency hopping is not enabled. Therefore, the SRS transmission should follow the bandwidth pattern determined mainly by c_srs and b_srs without additional hopping behavior.

After applying this configuration, first check the RRC Setup message and confirm that c-SRS 13, b-SRS 0, and b-hop 0 are shown correctly in the srs-Config IE. Then check the PHY SRS log in WebGUI. From the prb field, you can confirm the actual starting PRB and the number of consecutive PRBs used by the SRS signal.

By comparing this result with Sub Test 2, you can clearly see how changing b_srs from 1 to 0 affects the SRS bandwidth allocation while keeping the same c_srs value.

NR SA SRS Test 3 01

Check whether SRS is received with the configured interval and frequency-domain position. As in the previous tests, filter the WebGUI log with Layer set to PHY and Info set to SRS. This makes it easier to see only the SRS signals received by the gNB.

From the filtered PHY log, you can check the SRS periodicity by looking at the consecutive SFN/slot values. In this example, the SRS entries appear every 80 slots, so the periodicity matches the configured period value of 80.

You can also check the SRS bandwidth pattern from the prb field. The prb value is printed in the format prb=S:N. Here, S indicates the starting PRB, and N indicates the number of consecutive PRBs used by the SRS signal.

In this test, the log shows prb=1:48 repeatedly. This means that the SRS starts from PRB 1 and occupies 48 consecutive PRBs. Compared to Sub Test 2, where the SRS occupied 24 PRBs, this test uses a wider SRS bandwidth.

This result shows that changing b_srs from 1 to 0 while keeping c_srs as 13 increases the SRS bandwidth allocation. The UE still transmits SRS periodically every 80 slots, but the number of PRBs used by each SRS transmission is now 48 PRBs.

By comparing Sub Test 1, Sub Test 2, and Sub Test 3, you can clearly see how the SRS bandwidth changes depending on the c_srs and b_srs values. In the PHY log, this change appears directly in the second value of the prb=S:N field.

NR SA SRS Test 3 02

Test 2 : Aperiodic/Codebook SRS

The purpose of this test is to show how to configure Aperiodic SRS with the usage of codebook and how to verify it from the log. The way how Aperiodic SRS works is that gNB enables SRS request field in DCI 1_1 and UE is supposed to send SRS when it recieves the DCI with SRS Request field is enabled. Exactly when UE is supposed to send SRS (i.e, what is the time gap between DCI and SRS transmission) ?  This timegap (offset) is configured in RRC message.

Configuration

I have used gnb-sa-srs-ap.cfg which is copied and modified from gnb-sa.cfg.

NR SA SRS Ap Config 01

I am using the default mme, ims config as shown below.

NR BWP Test1 Configuration 02

In gnb-sa-srs-ap.cfg, I made a modification as follows (this is because the commercial UE that I have support TDD only. You may use whatever configuration that your UE support). Note that I set USE_SRS to 1 to enable SRS configuration.

In the configuration file, you can select any specific tdd pattern with the parameter NR_TDD_CONFIG.  To apply TDD configuration, you first need to configure the duplex mode (NR_TDD) to 1 (TDD). And then I set NR_TDD_CONFIG to 2 which is one of default sample configuration provided by Amarisoft sample configuration. (NOTE : This is just for this sample test. TDD is not mandatory for SRS operation).

NR SA SRS Config 02

In this tutorial, I will try a couple of tests by modifying the highlighted parameters. The main parameters to change are resource_type, period, and slot_offset. In the default configuration, c_srs, b_srs, and b_hop are not configured. If these parameters are omitted from the configuration file, the Callbox applies the default SRS bandwidth configuration automatically.

In this example, the SRS resource is configured as aperiodic. This means that the UE does not transmit SRS repeatedly by itself. Instead, SRS transmission is triggered by the gNB through DCI signaling. The period value is still shown in the resource configuration, but for aperiodic SRS, the important point is that the actual SRS transmission is controlled by the SRS request from the gNB.

The srs_resource section defines the SRS resource. Here, srs_resource_id is set to 0 and n_ports is set to N_ANTENNA_UL. The resource_type is set to aperiodic. Since c_srs, b_srs, and b_hop are not specified, the SRS bandwidth-related values are selected automatically by the Callbox.

The srs_resource_set section connects this SRS resource to the resource set. In this example, srs_resource_id_list includes resource 0. The slot_offset is set to 4. This offset is important for aperiodic SRS because it defines the timing gap between the DCI that triggers SRS and the actual SRS transmission.

After applying this configuration, you should check the RRC message first. In the srs-Config IE, you can confirm how the aperiodic SRS resource is configured, what default bandwidth-related parameters are selected, and how the slot offset is encoded. Then you can check the PHY log to verify whether the UE transmits SRS after receiving the SRS request from the gNB.

NR SA SRS Ap Config 03

Perform the Test

Testing process is simple. You only have to do NR SA attach (See NR SA Attach tutorial if you are not familiar with the process). The important part is to check the log and verify if you get the SRS as configured.

Log Analysis

Sample Log

First, check the RRC log and confirm whether the configuration is generated as intended. In this tutorial, I am checking SIB1 for the channel bandwidth and BWP information first, and then checking the RRC Setup message for the SRS configuration.

In the WebGUI, set Layer to RRC so that you can focus on RRC signaling messages. In this example, the SIB1 message is selected first. From SIB1, you can check the basic serving cell configuration, including the carrier bandwidth and initial BWP configuration.

In the highlighted part of SIB1, scs-SpecificCarrierList shows subcarrierSpacing kHz30 and carrierBandwidth 51. This means that the carrier is configured with 51 resource blocks using 30 kHz subcarrier spacing.

You can also check initialDownlinkBWP. In this example, genericParameters includes locationAndBandwidth 13750 and subcarrierSpacing kHz30. This confirms that the initial downlink BWP is configured and that it uses the same 30 kHz subcarrier spacing.

This step does not directly verify aperiodic SRS yet. However, it is useful to confirm the basic carrier and BWP configuration before checking the UE-specific SRS configuration. Since the SRS resource configuration is generated based on the cell bandwidth, BWP, and TDD pattern, these values are good reference points for later analysis.

After checking SIB1, move to the RRC Setup message and check the srs-Config IE. In the aperiodic SRS test, you should confirm that the SRS resource is configured as aperiodic and that the resource set includes the proper aperiodic trigger and slot offset information. Then, in the PHY log, you can verify whether SRS is actually transmitted after the gNB sends the SRS request.

NR SA SRS Ap Log 01

You can confirm the SRS resource configuration and the slot offset from the srs-Config IE in the RRC Setup message.

In this example, srs-ResourceSetToAddModList includes srs-ResourceSetId 0 and refers to srs-ResourceId 0. The resourceType is configured as aperiodic. This confirms that the SRS resource is not periodic, but is triggered by the gNB through DCI signaling.

You should also note that slotOffset is set to 4. This value comes from the configuration file. For aperiodic SRS, slotOffset indicates the time gap between the SRS trigger and the actual SRS transmission. In other words, after the UE receives DCI 1_1 with the SRS request field enabled, the UE transmits SRS after the configured offset.

The same srs-Config also shows usage set to codebook. This means that the aperiodic SRS resource is used for codebook-based operation.

Under srs-ResourceToAddModList, you can check the detailed SRS resource parameters. In this example, srs-ResourceId is 0 and nrofSRS-Ports is port1. The transmissionComb, resourceMapping, freqDomainPosition, freqDomainShift, c-SRS, b-SRS, and b-hop values are also shown here. Since c_srs, b_srs, and b_hop were not explicitly configured in the configuration file, these values are selected by the Callbox automatically.

So, from this RRC Setup message, you can verify that the aperiodic SRS resource is configured correctly, that the slot offset is set to 4, and that the generated SRS bandwidth parameters are included in the actual UE-specific RRC configuration. After this, you can move to the PHY log and check whether SRS is transmitted after the DCI trigger with the expected timing.

NR SA SRS Ap Log 02

After the UE is attached, you can check whether the aperiodic SRS is actually received by the Callbox. For easier analysis, set the WebGUI filter as shown in the example. In this case, it is useful to filter the PHY log with Info set to PDCCH, SRS so that you can see both the SRS trigger and the corresponding SRS transmission in the same view.

In the selected PDCCH entry, you can see that DCI 1_1 is used and srs_request is set to 1. This means that the SRS request field in the DCI is enabled, and this DCI acts as the trigger for aperiodic SRS transmission.

After this trigger, check the first SRS entry that appears after the DCI. The important point is the time gap between the DCI 1_1 carrying srs_request=1 and the actual SRS transmission. This time gap should match the slotOffset value configured in the RRC message.

In the previous RRC Setup message, slotOffset was set to 4. Therefore, after the UE receives the DCI with the SRS request enabled, the UE is expected to transmit SRS after 4 slots. In the PHY log, you can confirm this by comparing the SFN/slot value of the PDCCH trigger and the SFN/slot value of the following SRS entry.

You can also see that this trigger-and-SRS behavior repeats. Each time the gNB sends DCI 1_1 with srs_request=1, the UE transmits the corresponding aperiodic SRS after the configured offset. This confirms that the aperiodic SRS trigger mechanism is working properly.

The SRS log line also includes the prb field, such as prb=5:4. As before, this means that the SRS starts from PRB 5 and occupies 4 consecutive PRBs. By checking this field, you can confirm the actual frequency-domain allocation of the received SRS.

NR SA SRS Ap Log 03

Test 3 : Periodic/Non-Codebook SRS

The purpose of this test is to show how to configure non-Codebook based SRS and how to verify it from the test log.

Configuration

I have used gnb-sa-srs-noncodebook.cfg which is copied and modified from gnb-sa.cfg.

NR SA SRS NonCodebook SubTest 01 01

I am using the default mme, ims config as shown below.

NR BWP Test1 Configuration 02

In gnb-sa-srs-noncodebook.cfg I made a modification as follows. Note that I set USE_SRS to 1 to enable SRS configuration.

In the configuration file, you can select any specific tdd pattern with the parameter NR_TDD_CONFIG.  To apply TDD configuration, you first need to configure the duplex mode (NR_TDD) to 1 (TDD). And then I set NR_TDD_CONFIG to 2 which is one of default sample configuration provided by Amarisoft sample configuration. (NOTE : This is just for this sample test. TDD is not mandatory for SRS operation).

NR SA SRS NonCodebook SubTest 01 02

In this test, I am using PUCCH format 0 instead of PUCCH format 1.

In the configuration, the pucch section defines the common PUCCH-related parameters first. For this test, the highlighted part enables pucch0 configuration. The pucch0 block includes initial_cyclic_shift and n_symb. In this example, initial_cyclic_shift is set to 1 and n_symb is set to 1, meaning that PUCCH format 0 is configured with one OFDM symbol.

The pucch1 configuration is still shown in the file, but it is placed under the else branch, so it is not used in this test. This makes the test use PUCCH format 0 instead of PUCCH format 1.

This setting is not directly part of the SRS resource itself, but it is used as part of the overall uplink control configuration for this test. Since SRS is also an uplink signal, it is useful to make sure that the uplink control configuration and the SRS configuration are both generated as intended.

After applying this configuration, you can check the RRC message and confirm that the PUCCH configuration is reflected correctly. Then you can continue with the SRS-related checks, such as verifying the SRS resource configuration in srs-Config and confirming the received SRS entries in the PHY log.

NR SA SRS NonCodebook SubTest 01 03

Applying non-codebook configuration is simple. You only need to use the non_codebook parameter instead of the codebook parameter under resource_auto.

In this example, SRS is still configured with automatic resource configuration. The resource_auto block is used, so you do not need to manually define each SRS resource and SRS resource set. The main difference from the previous codebook example is that the configuration is placed under non_codebook instead of codebook.

Inside the non_codebook block, resource_type is set to periodic. This means that the UE transmits SRS periodically. The period is set to 80, meaning that the SRS transmission repeats every 80 slots.

With this configuration, Amarisoft automatically generates the detailed SRS resource configuration for non-codebook operation. The detailed parameters such as SRS resource ID, SRS resource set ID, number of ports, SRS bandwidth, frequency-domain position, and periodic offset are selected automatically by the Callbox based on the current cell configuration.

After applying this configuration, you should check the RRC message and confirm that usage is configured as nonCodebook in the srs-Config IE. Then you can check the PHY log and verify that the UE transmits SRS periodically and that the Callbox receives the SRS as expected.

NR SA SRS NonCodebook SubTest 01 04

To apply non-codebook SRS, you also need to set the PUSCH tx_config parameter to non_codebook.

This is because non-codebook SRS is related to non-codebook based uplink transmission. The gNB uses the received SRS to estimate the uplink channel and determine the transmission parameters for PUSCH. Therefore, the SRS usage and the PUSCH transmission configuration should be aligned.

In this example, the pusch section includes tx_config: "non_codebook". This tells the Callbox to configure PUSCH transmission for non-codebook based operation. When this is used together with SRS usage = non_codebook, the UE can be configured to transmit SRS for non-codebook uplink operation.

The configuration also includes max_rank: N_ANTENNA_UL when USE_SRS is enabled. This means that the maximum uplink transmission rank is related to the number of configured uplink antennas. In this example, since N_ANTENNA_UL is set to 1, the uplink transmission is limited to rank 1.

After applying this configuration, you should check the RRC message and confirm that the SRS configuration shows usage as nonCodebook. You should also check the PUSCH-related configuration and make sure that the uplink transmission configuration is consistent with non-codebook operation.

Then, after the UE is attached, check the PHY log and verify that SRS is received periodically by the Callbox. This confirms that the UE received the non-codebook SRS configuration and is transmitting SRS as expected.

NR SA SRS NonCodebook SubTest 01 05

Perform the Test

Testing process is simple. You only have to do NR SA attach (See NR SA Attach tutorial if you are not familiar with the process). The important part is to check the log and verify if you get the SRS as configured.

Log Analysis

Sample Log

Since the PUCCH format was changed in the configuration file, it is good to check whether the changed configuration is properly applied in the RRC log. In this test, I first look into the RRC Setup message and check the PUCCH configuration. From the log, you can see that PUCCH format 0 is used as configured.

In the RRC Setup message, check the pucch-Config section. Under resourceToAddModList, multiple PUCCH resources are configured. Each resource shows format format0, which confirms that PUCCH format 0 is applied.

For each PUCCH resource, you can also see parameters such as startingPRB, initialCyclicShift, nrofSymbols, and startingSymbolIndex. In this example, initialCyclicShift is set to 1 and nrofSymbols is set to 1. This matches the configuration where pucch0 was configured with initial_cyclic_shift 1 and n_symb 1.

This check is not directly verifying SRS yet, but it confirms that the uplink control configuration was changed as intended before checking the non-codebook SRS operation. After confirming the PUCCH configuration, you can continue checking the SRS-related part in the same RRC Setup message. In the srs-Config IE, you should verify that the SRS usage is configured as nonCodebook and that the resource type is periodic.

Then, in the PHY log, you can check whether SRS is received by the Callbox. Since this is a periodic non-codebook SRS test, SRS entries should appear repeatedly according to the configured period. From the SRS log, you can check the prb field for the frequency-domain allocation and the consecutive SFN/slot values for the periodicity.

NR SA SRS NonCodebook SubTest 01 Log 01

Now check srs-Config in the RRC Reconfiguration message. In this message, you should see that the SRS usage is set to nonCodebook in the SRS resource set.

In the highlighted srs-Config section, srs-ResourceSetToAddModList includes srs-ResourceSetId 0 and refers to srs-ResourceId 0. The resourceType is configured as periodic, so this SRS resource is transmitted repeatedly according to the configured periodicity and offset.

The important point in this test is the usage field. In this example, usage is set to nonCodebook. This confirms that the non_codebook setting in the configuration file has been properly reflected in the RRC Reconfiguration message.

You can also check the detailed SRS resource configuration under srs-ResourceToAddModList. In this example, srs-ResourceId 0 is configured with one SRS port. The transmission comb, cyclic shift, resource mapping, frequency-domain position, frequency-domain shift, c-SRS, b-SRS, and b-hop values are also shown in the RRC message. Since this test uses auto SRS resource configuration, these detailed values are automatically generated by the Callbox.

The periodic timing information is also shown in the resourceType periodic field. In this example, periodicityAndOffset is shown as sl80 with offset 7. This means that the UE is configured to transmit SRS every 80 slots with offset 7.

So, from this RRC Reconfiguration message, you can confirm that the SRS resource is configured as periodic, the usage is set to nonCodebook, and the generated SRS resource parameters are properly delivered to the UE. After this, you can check the PHY log and verify whether the Callbox actually receives periodic SRS from the UE.

NR SA SRS NonCodebook SubTest 01 Log 03

Once the configuration in RRC is properly set and the connection is established, you should be able to see SRS reception in the PHY log.

For easier analysis, filter the log by setting the Info field to SRS, CSI. In this example, both SRS and CSI entries are shown together. This is useful because you can see how the uplink SRS reception and downlink CSI report appear around the same timing area.

In the SRS log entries, you can confirm that the Callbox is receiving SRS from the UE. Each SRS entry shows information such as prb, symb, snr, epre, ta, ul_cqi, rank, and sri_bmp. The prb field shows the frequency-domain allocation of the received SRS. For example, prb=25:4 means that the SRS starts from PRB 25 and occupies 4 consecutive PRBs.

You can also confirm the SRS periodicity by checking the consecutive SFN/slot values. In this example, the SRS reception repeats every 80 slots, which matches the configured SRS period. This confirms that the periodic non-codebook SRS is transmitted and received according to the expected timing.

The log also shows rank and sri_bmp information in the SRS entry. This is useful for non-codebook operation because the received SRS can be used by the gNB to evaluate the uplink channel and select the suitable SRS resource indicator or transmission configuration for PUSCH.

So, after confirming usage nonCodebook in the RRC Reconfiguration message, this PHY log confirms the actual SRS reception. By checking both the RRC configuration and the received SRS entries, you can verify that periodic non-codebook SRS is configured and working properly.

NR SA SRS NonCodebook SubTest 01 Log 04

RRC / NAS Signaling

RrcSetup (SA)

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

  message c1: rrcSetup: {

    rrc-TransactionIdentifier 0,

    criticalExtensions rrcSetup: {

      radioBearerConfig {

       ...

      },

      masterCellGroup {

        ...

        },

        mac-CellGroupConfig {

          ...

        },

        physicalCellGroupConfig {

          pdsch-HARQ-ACK-Codebook dynamic

        },

        spCellConfig {

          spCellConfigDedicated {

            initialDownlinkBWP {

              pdcch-Config setup: {

                ...

              },

              pdsch-Config setup: {

                ...

            },

            firstActiveDownlinkBWP-Id 0,

            uplinkConfig {

              initialUplinkBWP {

                pucch-Config setup: {

                  ...

                },

                pusch-Config setup: {

                  ...

                },

                srs-Config setup: {

                  srs-ResourceSetToAddModList {

                    {

                      srs-ResourceSetId 0,

                      srs-ResourceIdList {

                        0

                      },

                      resourceType aperiodic: {

                        aperiodicSRS-ResourceTrigger 1,

                        slotOffset 4

                      },

                      usage codebook,

                      p0 -84,

                      pathlossReferenceRS ssb-Index: 0

                    }

                  },

                  srs-ResourceToAddModList {

                    {

                      srs-ResourceId 0,

                      nrofSRS-Ports port1,

                      transmissionComb n2: {

                        combOffset-n2 0,

                        cyclicShift-n2 7

                      },

                      resourceMapping {

                        startPosition 1,

                        nrofSymbols n1,

                        repetitionFactor n1

                      },

                      freqDomainPosition 0,

                      freqDomainShift 5,

                      freqHopping {

                        c-SRS 11,

                        b-SRS 3,

                        b-hop 0

                      },

                      groupOrSequenceHopping neither,

                      resourceType aperiodic: {

                      },

                      sequenceId 500

                    }

                  }

                }

              },

              firstActiveUplinkBWP-Id 0,

              pusch-ServingCellConfig setup: {

              }

            },

            pdcch-ServingCellConfig setup: {

            },

            pdsch-ServingCellConfig setup: {

              nrofHARQ-ProcessesForPDSCH n16,

              maxMIMO-Layers 2

            },

            csi-MeasConfig setup: {

             ...

            },

            tag-Id 0

          }

Tips

Interpretation of srs_symbols array

The srs_symbols array is used to define which slot in the TDD pattern can carry SRS and how many symbols at the end of that slot are reserved for SRS transmission.

The number of elements in the srs_symbols array is related to the number of slots in one TDD pattern period. For example, if the TDD pattern period is 5 ms and the subcarrier spacing is 30 kHz, there are 10 slots within 5 ms. In this case, the srs_symbols array has 10 elements, and each element corresponds to one slot in the TDD pattern period.

The index of the non-zero value in the array indicates the slot where SRS can be transmitted. In this example, the non-zero value is located at index 7. Since the index starts from 0, index 7 means the 8th slot within the TDD pattern period. This indicates that the 8th slot is used for SRS transmission.

The non-zero value itself indicates the number of symbols reserved for SRS at the end of that slot. For example, if the value is 2, it means that the last 2 OFDM symbols of that slot are reserved for SRS. If the value is 4, it means that the last 4 OFDM symbols of that slot are reserved for SRS.

So, for the array [0, 0, 0, 0, 0, 0, 0, 2, 0, 0], the interpretation is that the 8th slot in the TDD pattern period carries SRS, and the last 2 symbols of that slot are reserved for SRS.

This configuration is needed because SRS should be placed in a valid uplink or flexible symbol location in the TDD pattern. The srs_symbols array tells the Callbox where SRS transmission is allowed within the TDD pattern. Therefore, the value should be selected carefully according to the configured NR_TDD_CONFIG.

NR SA SRS Tips srs symbols 01

© 2025 All rights reserved | Legal notice |