NR SA SRS : Antenna Switch
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. For SRS with usage = codebook, 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) is a fundamental uplink signal in 5G New Radio (NR) Standalone (SA) systems, playing a critical role in enabling efficient and accurate uplink channel quality estimation. Unlike conventional reference signals embedded within scheduled uplink transmissions such as PUSCH DMRS (Demodulation Reference Signal), SRS is uniquely designed to be transmitted independently of uplink data scheduling, providing the gNB (Next Generation NodeB) with a flexible and comprehensive mechanism for assessing uplink channel conditions across the entire system bandwidth. This independence allows for more granular and frequent channel state information, which is particularly advantageous in Time Division Duplex (TDD) deployments where channel reciprocity can be leveraged—meaning the channel characteristics estimated from the uplink can also assist in optimizing downlink transmissions. Architecturally, SRS is configured at the gNB and dynamically scheduled to the User Equipment (UE), with parameters such as frequency, bandwidth, periodicity, and usage type tailored to meet specific deployment and optimization requirements. Its significance is amplified in NR due to the prevalence of TDD, higher frequency bands, and the need for advanced beamforming and massive MIMO operations, where precise uplink channel knowledge directly influences overall system throughput and reliability. Effective configuration and testing of SRS, especially using commercial solutions like the Amari Callbox, are essential for validating NR SA deployments, optimizing radio performance, and ensuring robust support for demanding applications in the 5G ecosystem.
-
Context of the Technology
- 5G NR introduces advanced reference signal structures to optimize both uplink and downlink channel estimation, with SRS providing a dedicated mechanism for uplink channel sounding.
- SRS operates independently from user data and control channel transmissions, enabling the network to capture accurate and wideband channel state information across multiple frequency resources.
- Its flexible configuration allows adaptation to diverse deployment scenarios, including dense urban cells, high-mobility users, and massive MIMO arrays.
-
Relevance and Importance of the Tutorial Topic
- Testing and validating SRS functionality is vital for network performance tuning, especially in NR SA environments where uplink reliability and efficiency are paramount.
- Understanding SRS configuration and analysis in commercial test equipment such as the Amari Callbox empowers engineers to ensure compliance with 3GPP specifications and optimize real-world deployments.
- Accurate SRS operation enhances link adaptation, beam management, and overall spectral efficiency in the 5G network.
-
Learning Outcomes
- Gain practical experience in configuring SRS parameters within a controlled NR SA test environment.
- Acquire skills to interpret SRS-related logs and measurement results in the WebGUI interface of the Amari Callbox.
- Develop the ability to analyze uplink channel quality and make informed decisions on network optimization and troubleshooting.
-
Prerequisite Knowledge and Skills
- Familiarity with basic 5G NR concepts, including the NR air interface, reference signal types, and TDD operation.
- Experience with Amari Callbox basic operations, including device setup, session configuration, and log analysis.
- Understanding of uplink and downlink signal processing fundamentals and general RF measurement principles.
Summary of the Tutorial
This tutorial provides detailed methodologies and procedures for testing SRS (Sounding Reference Signal) configuration and antenna switching in a 5G NR Standalone (SA) environment using Amarisoft gNB and UEsim. The tests focus on both manual and automatic SRS resource configuration, analysis of received SRS signals, and verification of configuration via log analysis. The procedures are structured as follows:
- Test Setup:
- Low layer testing setup with Amarisoft gNB and UE, using the provided SIM card.
- For configuration changes, refer to the Configuration Guide.
- Key Configuration Parameters:
- SRS configuration parameters include srs_symbols, srs_resource (with several sub-parameters), and srs_resource_set (with sub-parameters like srs_resource_set_id, usage, and p0).
- Parameters are set in the gNB configuration file, with options for manual and auto SRS resource allocation.
- Reference Configuration: Auto SRS Configuration
- Starting from release 2022-09-16, Amarisoft’s gnb-sa.cfg includes auto SRS configuration by default.
- Auto SRS configuration simplifies the process: only resource_auto, codebook, resource_type, and period are needed.
- For antenna switching, at least one codebook configuration must be present. antenna_switching resources are also automatically handled.
- With auto configuration, SRS symbols are set automatically based on the TDD pattern.
- Log analysis involves verifying that SRS for both codebook and antenna switching are configured and received as intended (e.g., two SRS in consecutive slots, both received at an 80 slot interval).
- Test 1: 1 SRS Resource (Manual Configuration)
- Configuration is performed in gnb-sa-srs-antenna-switch.cfg with USE_SRS set to 1.
- TDD is enabled (NR_TDD=1) and NR_TDD_CONFIG=2 is selected.
- One SRS resource is defined and referenced by two SRS resource sets: one for codebook usage and one for antenna_switching.
- Slot offset for SRS periodicity is auto-configured by the callbox and is not user adjustable.
- Test Execution: Perform NR SA attach; then analyze logs to confirm the SRS is being received as configured by checking SIB1, RRC Setup, and SRS logs for periodicity and resource allocation.
- Visual verification: Use filters in the log viewer to isolate SRS and check SNR/EPRE plots for the SRS resource.
- Test 2: 2 SRS Resources on Different Slots (Manual Configuration)
- Configuration is performed in gnb-sa-srs-antenna-switch-2rs.cfg with USE_SRS set to 1.
- TDD and NR_TDD_CONFIG=2 are set as in Test 1.
- Four SRS resources are defined, all with the same periodicity. Slot offsets are automatically assigned by the gNB.
- Two SRS resource sets are defined: one mapping to two SRS resources for codebook usage, and another mapping to the other two for antenna_switching.
- Test Execution: Perform NR SA attach; analyze logs to verify that SRS resources are transmitted on different slots within the same radio frame and that configurations match expectations.
- Visual verification: Confirm via log and graphical tools that SRS are received at the correct slots, and check SNR/EPRE plots.
- Test 3: 2 SRS Resources on the Same Slot (Auto Configuration)
- Configuration is performed in gnb-sa-srs-antenna-switch-auto-2rs.cfg with USE_SRS set to 1 and resource_auto parameter enabled.
- Parameter allow_xTyR is introduced to allow the gNB to determine the number of TX and RX SRS ports based on antenna configuration and UE capability.
- Test Execution: NR SA attach is performed. The gNB checks UE capability (supportedSRS-RxPortSwitch) before applying antenna switching SRS.
- Log analysis confirms that two SRS resources are transmitted in the same slot at different OFDM symbol positions, as determined by the auto configuration.
- Visual verification: Use log and graphical tools to confirm SRS reception, symbol positioning, and SNR/EPRE plots.
- Additional Tips:
- To enable antenna switching on UEsim, channel simulation must be enabled in the UE configuration.
- For recent releases, the SRS antenna port number for antenna switching SRS can be checked from the gNB log.
General Methodology Across Tests:
- Configure the gNB and (optionally) UE as per the test scenario, adjusting SRS and antenna switching parameters as required.
- Initiate NR SA attach procedure with the UE.
- After attachment, use log analysis (text and graphical) to verify that SRS resources are configured, transmitted, and received as specified in each test case.
- Check for correct periodicity, slot allocation, symbol position, and SNR/EPRE for SRS.
- For auto SRS configuration, rely on the gNB to select optimal parameter values based on the current network and UE capabilities.
This structured approach ensures that SRS and antenna switching features are correctly implemented and verifiable in both manual and automated configurations, with clear steps for log-based analysis and troubleshooting.
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.
- 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 Guide would help
Key Configuration Parameters
Followings are important configuration parameters for this tutorial. You may click on the items for the descriptions from Amarisoft documents.
- srs : In this link, you can get the descriptions for all the parameters listed below
- srs_symbols
- srs_resource
- srs_resource_id
- n_ports
- transmission_comb
- cyclic_shift
- n_symb
- repetition_factor
- c_srs
- freq_domain_shift
- b_srs
- b_hop
- group_or_sequence_hopping
- n_id
- resource_type
- period
- srs_resource_set
- srs_resource_set_id
- srs_resource_id_list
- aperiodic_srs_trigger
- slot_offset
- usage
- p0
- alpha
Reference Configuration : Auto SRS Configuration
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-antenna-switch-auto.cfg just because I changed one parameter "#define USE_SRS". (
In this example, the SRS configuration is enabled from the main gnb-sa.cfg parameter section. The first important setting is NR_TDD, which is set to 1. This means the cell is configured as NR TDD. After that, NR_TDD_CONFIG is set to 2, which selects one of the predefined TDD patterns provided in the Amarisoft sample configuration.
The important point here is that TDD itself is not mandatory for SRS operation. This example uses TDD only because this tutorial is based on a sample TDD configuration. Once a valid TDD pattern is selected, the gNB can automatically place the SRS resources in proper uplink opportunities.
The highlighted line shows NR_TDD_CONFIG 2. This is the selected TDD pattern for this test. The comment indicates that any valid TDD configuration supported by the gNB can be used, and the SRS resources will be generated automatically according to that TDD structure.
The next important part is the antenna configuration. In this example, N_ANTENNA_DL and N_ANTENNA_UL are both set to 2. This means the gNB is configured with two downlink antenna ports and two uplink antenna ports. This is important for SRS antenna switching because the SRS configuration depends heavily on the uplink antenna capability.
Finally, USE_SRS is set to 1. This is the main switch to enable periodic SRS configuration. Once this is enabled, Amarisoft automatically creates the SRS-related RRC configuration based on the selected bandwidth, TDD pattern, and uplink antenna configuration. So this example provides the starting point for observing how the gNB configures SRS without manually defining all SRS parameters.
You can configure srs with automatic resource configuration by using the parameter resource_auto within srs object.
In this example, the SRS object is configured with automatic resource allocation. This is done by using resource_auto inside the srs configuration block. With this method, you do not need to manually define all low-level SRS resource parameters. Instead, you provide only the high-level purpose of the SRS resource, and Amarisoft generates the detailed SRS resource configuration automatically.
The first block is codebook. Even if the main purpose of this test is antenna switching, at least one codebook SRS configuration is still required. In this example, the codebook SRS is configured as periodic, and the period is set to 80 slots. This provides the basic SRS resource configuration required by the gNB.
The second block is antenna_switching. This is the additional SRS configuration used for the antenna switching test. It is also configured as periodic, with the same period value of 80 slots. This means the UE will transmit SRS periodically for antenna switching operation.
The important point is that antenna switching is not configured alone. The gNB still needs the baseline codebook SRS configuration. So the configuration has two parts: one mandatory codebook SRS resource and one additional antenna switching SRS resource. This allows the gNB to generate the proper RRC SRS configuration while keeping the user configuration simple.
Since this test uses multiple SRS resources, the PUCCH resource allocation is adjusted to leave enough uplink space for SRS transmission. This is important because SRS and PUCCH both use uplink resources, and too much PUCCH occupation may reduce the available space for multiple SRS resources.
In this example, the PUCCH configuration is modified under the pucch block. The basic PUCCH group hopping is set to neither, and hopping_id is set to -1, which means it follows the cell ID. The nominal P0 value is set to -90.
The highlighted part is in the pucch1 configuration. The value n_cs is set to 3, and n_occ is set to 2. These values are adjusted together with the reduced number of PUCCH symbols. The most important change is n_symb, which is reduced to 10. This reduces the number of symbols occupied by PUCCH1 and reserves more room for multiple SRS resources.
There is also a conditional setting for the case where USE_SRS is enabled and NR_TDD is disabled. In that case, n_symb is set to 12. This shows that the PUCCH resource size may need to be adjusted depending on whether the test is TDD or FDD and whether SRS is enabled.
The main purpose of this change is not to optimize PUCCH itself. It is to avoid resource conflict and make sure that enough uplink resource is available for the automatically generated SRS resources used in this antenna switching test.
Following table shows an example of srs configuration.
This table compares the old manual SRS configuration and the new AutoSRS configuration. The main purpose is to show how much simpler the configuration becomes when AutoSRS is used.
In the configuration without AutoSRS, the user had to define many details manually. For example, srs_symbols had to be selected differently depending on NR_TDD_CONFIG. If NR_TDD_CONFIG was 1 or 2, one symbol pattern was used. If NR_TDD_CONFIG was 3, another pattern was used. If NR_TDD_CONFIG was 4 or 10, different patterns were used again. This means the user had to understand the TDD pattern and manually choose proper SRS symbol positions.
In addition to srs_symbols, the old configuration also required explicit srs_resource and srs_resource_set definitions. The resource had to define items such as srs_resource_id, n_ports, resource_type, and period. Then the resource set had to connect the resource to a usage type such as codebook or antenna_switching. So the configuration was longer and more error-prone.
With AutoSRS, this detailed configuration is replaced by resource_auto. The user only defines the purpose of the SRS resource. In this example, one resource is configured for codebook and another resource is configured for antenna_switching. Both are periodic, and both use a period of 80 slots.
One important difference is that srs_symbols is no longer shown in the AutoSRS configuration. This is because the gNB automatically selects the proper SRS symbol positions based on the selected TDD configuration. So the user does not need to manually adjust srs_symbols whenever the TDD pattern changes.
This makes the configuration much easier to maintain. The user only needs to describe what kind of SRS resource is needed, such as codebook or antenna switching, and Amarisoft generates the detailed SRS resource configuration automatically according to the cell bandwidth, uplink antenna configuration, and TDD pattern.
|
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 */ } ], srs_resource_set: [ { srs_resource_set_id: 0, srs_resource_id_list: [ 0 ], usage: "codebook", }, { srs_resource_set_id: 1, srs_resource_id_list: [ 0 ], usage: "antenna_switching", }, ], }, #endif |
#if USE_SRS srs: { resource_auto: { codebook: { resource_type: "periodic", period: 80, /* in slots */ }, antenna_switching: { resource_type: "periodic", period: 80, /* in slots */ } } }, #endif |
Log Analysis
This is just for showing the association between the configuration shown above and IE (Information Elements) in RRC.
This example shows how the SRS configuration generated from the configuration file appears in the RRC message. The purpose here is to confirm the association between the simple AutoSRS configuration and the actual RRC information elements sent to the UE.
In the log, the selected message is RRC reconfiguration. This is the message where the gNB sends the detailed radio configuration to the UE. On the right side, the decoded RRC message shows the srs-Config section. Even though the configuration file used only a simple resource_auto setting, the gNB expands it into full RRC-level SRS information.
The highlighted part shows srs-ResourceSetToAddModList. In this list, two SRS resource sets are configured. The first one is srs-ResourceSetId 0. It is associated with srs-ResourceIdList 0, uses periodic resource type, and its usage is codebook. This corresponds to the mandatory codebook SRS configuration in the configuration file.
The second one is srs-ResourceSetId 1. It is also periodic, but its usage is antennaSwitching. This corresponds to the antenna_switching block in the configuration file. It is mapped to srs-ResourceIdList 1.
So this RRC message confirms that the two high-level AutoSRS entries in the configuration file are converted into two separate SRS resource sets in the RRC configuration. One resource set is used for codebook operation, and the other resource set is used for antenna switching.
The detailed resource parameters shown below this section are automatically generated by the gNB. They depend on the BWP bandwidth, TDD pattern, antenna configuration, and other cell parameters. This is why the user does not need to manually configure all SRS symbols and resource details when AutoSRS is used.
Now we look into the physical SRS resource configuration in more detail. In the RRC reconfiguration message, the gNB configures two SRS resources under srs-ResourceToAddModList. These two resources are identified by srs-ResourceId 0 and srs-ResourceId 1.
When you compare the two resources, most of the detailed parameters are the same. Both resources use two SRS ports, shown as nrofSRS-Ports port2. Both use the same transmission comb structure, same resource mapping, same frequency domain position, same frequency domain shift, same frequency hopping configuration, and same sequence ID. This means the basic SRS signal structure is identical for both resources.
The main difference is in periodicityAndOffset. The first resource has periodicityAndOffset set to sl80 : 7, and the second resource has periodicityAndOffset set to sl80 : 8. This means both SRS resources use the same 80-slot periodicity, but they are transmitted in different slots. One SRS resource is transmitted at slot offset 7, and the other is transmitted at slot offset 8.
So the two SRS resources are not different in terms of waveform structure. They are mainly separated in time. The same type of SRS is placed at the same OFDM symbol position, but in two different slots. This kind of allocation is useful for antenna switching because the UE can transmit SRS from different antenna paths at different time occasions.
This is also another example of AutoSRS behavior. The user did not manually configure these detailed physical resource parameters. The gNB automatically generated them based on the BWP bandwidth, TDD pattern, and antenna-related configuration. The result is that the RRC message contains a complete and valid SRS resource configuration, while the configuration file remains simple.
Once the RRC configuration is applied, you can verify the actual SRS reception from the log viewer. In this example, the log is filtered with SRS, so only the SRS-related PHY logs are shown.
After the RRC reconfiguration complete message, the gNB starts receiving SRS from the UE. The SRS logs appear repeatedly, which confirms that the UE is transmitting SRS according to the configuration delivered by RRC.
The important point is the slot position. In the RRC configuration, two SRS resources were configured with periodicityAndOffset sl80 : 7 and sl80 : 8. In the log viewer, you can see that SRS is received in consecutive slots, slot 7 and slot 8. This matches the RRC configuration.
You can also see that this pair of SRS transmissions repeats at the configured interval. Since the period was set to 80 slots, the same SRS reception pattern appears again every 80 slots. So the log confirms both parts of the configuration: two consecutive SRS resources and 80-slot periodic repetition.
This step is useful because it connects the configuration file, the RRC message, and the actual PHY behavior. The configuration file defines the high-level AutoSRS setting. The RRC message shows the generated SRS resource configuration. Finally, the PHY log confirms that the SRS signal is really received at the expected slot timing.
Test 1 : 1 SRS Resource
This test is show you how to configure srs manually. In this test configuration, one srs resource set is using only one srs resources.
Configuration
I have used gnb-sa-srs-antenna-switch.cfg
I am using the default mme, ims config as shown below.
In gnb-sa-srs-antenna-switch.cfg, it is configured as follows. (
In this test, the SRS configuration is done manually in gnb-sa-srs-antenna-switch.cfg. This is different from the AutoSRS example because the user has to define the SRS resource and resource set explicitly in the configuration file.
First, NR_TDD is set to 1. This means the cell is configured as NR TDD. After that, NR_TDD_CONFIG is set to 2, which selects one of the predefined TDD patterns in the Amarisoft sample configuration. This TDD setting is used only for this sample test. SRS itself does not require TDD, but when TDD is used, the SRS resource should be placed in a valid uplink region.
The antenna configuration is also shown in this part. N_ANTENNA_DL is set to 2, and N_ANTENNA_UL is set to 1. This means the gNB uses two downlink antenna ports and one uplink antenna port in this test. Since this section is for a simple one-resource SRS test, the uplink side is kept simple.
The most important setting is USE_SRS. It is set to 1, which enables the SRS configuration. Once this parameter is enabled, the SRS configuration block in the later part of the configuration file becomes active.
So this part prepares the basic cell condition for the manual SRS test. It selects TDD mode, chooses TDD configuration 2, sets the antenna configuration, and enables SRS. After this, the detailed SRS resource configuration can be added manually.
In this release, the SRS resource periodicity slot offset is assigned automatically by the Callbox. It is not directly configured by the user in the configuration file. If you want to check the actual slot offset used for each SRS resource, you need to look at the generated RRC message.
In this part of the configuration, the user manually defines srs_symbols. This parameter controls which OFDM symbols are reserved for SRS within the slot. The array position indicates the symbol location, and the non-zero value indicates that SRS is allocated at that symbol position.
The value itself indicates how many consecutive OFDM symbols are reserved for SRS. For example, if the non-zero value is 2, it means two consecutive symbols are used for SRS starting from that symbol position. If the value is 4, it means four consecutive symbols are reserved.
Since SRS is an uplink signal, these symbols must be located only in uplink symbols. Therefore, when you change the TDD UL/DL pattern, you also need to adjust the non-zero position in srs_symbols so that the SRS is placed in a valid uplink region.
In this example, different srs_symbols arrays are prepared for different NR_TDD_CONFIG values. For NR_TDD_CONFIG 1 or 2, one symbol position is used. For NR_TDD_CONFIG 3, another symbol position is used. For NR_TDD_CONFIG 4 and 10, different patterns are used again. This is necessary because each TDD pattern has a different uplink and downlink symbol structure.
So even though the slot offset is automatically selected by the Callbox, the symbol-level location inside the slot still needs to be defined properly in the manual configuration. This is one of the main differences between manual SRS configuration and AutoSRS configuration. In AutoSRS, this symbol placement is handled automatically, but in manual configuration, the user must make sure that the SRS symbol position matches the selected TDD pattern.
In this configuration, only one SRS resource is defined in the srs_resource array. This resource has srs_resource_id 0, uses N_ANTENNA_UL as the number of SRS ports, and is configured as periodic with a period of 80 slots.
The important point is that this single SRS resource is shared by two different SRS resource sets. The first resource set has srs_resource_set_id 0 and uses srs_resource_id_list 0. Its usage is codebook. This means the same SRS resource is used for codebook-based operation.
The second resource set has srs_resource_set_id 1 and also uses the same srs_resource_id_list 0. Its usage is antenna_switching. This means the same physical SRS resource is also associated with antenna switching operation.
So even though there are two SRS resource sets, there is only one actual SRS resource in this test. The two resource sets do not point to different SRS transmissions. They both point to the same resource ID 0, but they assign different purposes to it: one for codebook and one for antenna switching.
This is why this test is called one SRS resource. It is useful for checking the simplest manual configuration where a single SRS resource is reused by multiple SRS usages.
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 RRC log and see if the configuration is done as you intended. In this tutorial, I am checking SIB1 for the channel bandwidth and BWP and RrcSetup for SRS configuration.
In this example, the selected RRC message is SIB1. On the right side, you can check the common frequency configuration and the initial downlink BWP configuration. The scs-SpecificCarrierList shows subcarrierSpacing kHz30 and carrierBandwidth 51. This indicates that the cell is using 30 kHz subcarrier spacing and 51 RB carrier bandwidth.
You can also check initialDownlinkBWP. In this example, locationAndBandwidth is set to 13750 and subcarrierSpacing is also kHz30. This confirms that the initial BWP is configured with the same subcarrier spacing.
This step is not mandatory for verifying SRS itself, because SRS is configured later in the dedicated RRC reconfiguration message. However, it is a useful sanity check. SRS resource generation depends on the available BWP and uplink resource structure, so checking the carrier bandwidth and BWP first helps confirm that the cell has enough resource space for the SRS configuration.
After this basic bandwidth and BWP check, the next step is to inspect rrcSetup or RRC reconfiguration and confirm how the SRS resource and SRS resource set are actually delivered to the UE.
You can confirm the generated SRS configuration in the RRC setup message. In this example, the decoded RRC message shows srs-Config setup, which contains both srs-ResourceSetToAddModList and srs-ResourceToAddModList.
In srs-ResourceSetToAddModList, two SRS resource sets are configured. The first resource set has srs-ResourceSetId 0 and its usage is codebook. The second resource set has srs-ResourceSetId 1 and its usage is antennaSwitching.
Even though there are two resource sets, both of them refer to the same SRS resource. In both cases, srs-ResourceIdList points to resource 0. This matches the manual configuration, where only one SRS resource was defined in the srs_resource array, and that same resource was reused by both resource sets.
In srs-ResourceToAddModList, only one actual SRS resource is configured. It has srs-ResourceId 0. This confirms that the test is really using only one physical SRS resource. The same resource is simply associated with two different usages: codebook and antenna switching.
This is the key point of this test. The configuration does not create separate SRS transmissions for codebook and antenna switching. Instead, one SRS resource is shared by two SRS resource sets. So the RRC message directly reflects the structure of the configuration file: one SRS resource, two SRS resource sets, and two different usages.
After the UE is attached, you can verify whether the Callbox is actually receiving the SRS from the UE. For easier analysis, the log viewer is filtered with SRS in the Info field. This removes unrelated RRC, MAC, and PHY messages and allows you to focus only on the SRS reception logs.
In this example, SRS messages are shown repeatedly in the PHY layer log. Each SRS log line shows the received SRS timing and measurement information. The SFN.slot value is especially useful because it lets you check whether the SRS is received at the expected period and slot offset.
By checking several consecutive SRS entries, you can confirm that the SRS is received periodically according to the configured period. In this test, the SRS resource was configured with a period of 80 slots, so the same SRS reception pattern should repeat every 80 slots.
You can also check the prb and symb fields in the SRS log. The prb value indicates the frequency-domain position of the received SRS resource. The symb value indicates the OFDM symbol position used by the SRS within the slot. These values are useful for confirming that the physical SRS resource is placed as expected.
So this log gives the final confirmation of the manual one-resource SRS configuration. The configuration file defines one SRS resource, the RRC message shows how that resource is delivered to the UE, and the PHY log confirms that the SRS is actually received by the Callbox with the expected timing and resource position.
You can also check the SNR and EPRE trend for the received SRS using the statistics plot. This is useful when you want to verify not only that SRS is received, but also whether the received SRS quality is stable over time.
To open this view, click the Analytics button and select the SNR tab. In this example, the plot shows several measurement traces, including SRS snr and UL SRS EPRE. The SRS SNR trace shows the signal quality of the received SRS, while the UL SRS EPRE trace shows the received energy level of the SRS resource.
This kind of plot is useful for checking the stability of the SRS reception. If the UE is transmitting SRS correctly and the radio condition is stable, the SRS SNR and EPRE values should remain relatively stable. Sudden drops or large fluctuations may indicate radio fading, weak uplink power, antenna issue, or temporary decoding/measurement instability.
In this example, the SRS-related traces are displayed together with other uplink measurements, so you can compare SRS quality with other uplink channels such as PUCCH and PUSCH. This helps you understand whether the issue is specific to SRS or common to the overall uplink radio condition.
So this plot provides a higher-level visual confirmation of the SRS reception quality. The log viewer confirms the SRS timing and resource position, while the SNR plot confirms the received SRS quality and stability over time.
Test 2 : 2 SRS Resource on different slots
This test is to show you how to configure multiple resources in one srs_resourceset for the usage of antennaSwitch, but the two resources in the resource set are allocated in two separate slots when you configure it manually as in this test.
Configuration
I have used gnb-sa-srs-antenna-switch-2rs.cfg which is copied and modified from gnb-sa-srs-antenna-switch.cfg
I am using the default mme, ims config as shown below.
In gnb-sa-srs-antenna-switch-2rs.cfg , it is configured as follows. (
The basic cell configuration is almost the same as the previous test, but this test is prepared for using two SRS resources.
First, NR_TDD is set to 1, so the cell operates in NR TDD mode. Then NR_TDD_CONFIG is set to 2. This selects one of the predefined TDD patterns in the Amarisoft sample configuration. This is only the selected pattern for this sample test. SRS itself is not limited to TDD operation, but when TDD is used, the SRS resource must be placed in a valid uplink part of the TDD pattern.
The antenna configuration is also shown here. N_ANTENNA_DL is set to 2, and N_ANTENNA_UL is set to 1. This means the gNB is configured with two downlink antenna ports and one uplink antenna port. Even though this test uses two SRS resources, the uplink antenna port configuration is still kept as one in this example.
The most important parameter is USE_SRS. It is set to 1, which enables the SRS configuration block. Without this setting, the SRS configuration defined later in the file would not be applied.
So this part only prepares the common radio condition for the test. It enables TDD mode, selects TDD configuration 2, sets the antenna configuration, and enables SRS. The actual difference from the previous test appears in the later SRS resource configuration, where two SRS resources are defined and used for antenna switching.
Here you see 4 srs resources are configuration in srs_resource array. (
This part defines the individual SRS resources used in this test. Each SRS resource has its own resource ID, but all of them use the same periodic transmission type and the same 80-slot period. The exact slot offset is not configured here. It is automatically assigned by the gNB and should be checked later in the RRC message.
srs_resource_id 0 means this is the first SRS resource.
srs_resource_id 1 means this is the second SRS resource.
srs_resource_id 2 means this is the third SRS resource.
srs_resource_id 3 means this is the fourth SRS resource.
resource_type periodic means the SRS resource is transmitted repeatedly at a regular interval.
period 80 means the SRS resource is repeated every 80 slots.
The important point is that the same period value does not mean all SRS resources are transmitted in the same slot. In this configuration, only the repetition period is given. The slot offset is not given by the user.
In this Amarisoft gNB release, the slot offset is automatically selected by the Callbox based on the overall cell configuration. So even though all four resources have period 80, the actual periodicityAndOffset may be different for each resource.
Therefore, this configuration defines how many SRS resources are available and how often they repeat. The exact slot position of each SRS resource should be confirmed later in the generated RRC message.
Here you can see that two SRS resource sets are configured in the srs_resource_set array. Each resource set groups a different pair of SRS resources and assigns a different usage.
srs_resource_id_list: [ 0, 1 ] means SRS resource 0 and SRS resource 1 are included in this SRS resource set. These two resources were already defined in the srs_resource array. So this line does not create new SRS resources. It only tells the gNB which existing SRS resources belong to this resource set.
usage: "codebook" means this SRS resource set is used for codebook-based SRS operation. In this case, SRS resource 0 and SRS resource 1 are used for normal SRS operation related to UL channel measurement and codebook-based UL transmission control.
srs_resource_id_list: [ 2, 3 ] means SRS resource 2 and SRS resource 3 are included in another SRS resource set. These are separate resources from the first set. So resource 0 and 1 belong to the codebook set, while resource 2 and 3 belong to this second set.
usage: "antenna_switching" means this SRS resource set is used for SRS antenna switching operation. In this case, SRS resource 2 and SRS resource 3 are used to make the UE transmit SRS with antenna switching behavior. In TDD, the gNB can receive these SRS signals and use them as a reference to observe the channel condition from different UE antenna paths.
So the mapping is simple.
SRS resource 0 and 1 are grouped together and used for codebook.
SRS resource 2 and 3 are grouped together and used for antenna switching.
The resource set defines the purpose. The resource id list defines which SRS resources are used for that purpose.
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
This log analysis starts from the RRC log. Before checking the dedicated SRS configuration, it is useful to confirm the basic cell bandwidth and BWP configuration first.
In this example, SIB1 is selected in the RRC log. This is not mandatory for SRS verification, but it gives a good sanity check before looking into the SRS configuration. Since SRS resource allocation depends on the available uplink bandwidth and BWP structure, it is helpful to confirm that the cell has enough bandwidth for the SRS resources.
In scs-SpecificCarrierList, subcarrierSpacing is set to kHz30 and carrierBandwidth is set to 51. This means the carrier is configured with 30 kHz subcarrier spacing and 51 RB bandwidth.
In initialDownlinkBWP, locationAndBandwidth is set to 13750 and subcarrierSpacing is also set to kHz30. This confirms that the initial BWP is configured with the same 30 kHz subcarrier spacing.
At this point, we are not checking the SRS resource itself yet. We are only confirming the basic bandwidth and BWP information from SIB1. After this, the next step is to check the RRC setup message and confirm whether the SRS configuration is generated as intended.
You can confirm the SRS configuration in the RRC Setup message. This is where the gNB sends the detailed SRS resource configuration to the UE.
In this example, four SRS resources are configured in srs-ResourceToAddModList. They are shown as srs-ResourceId 0, 1, 2, and 3. This matches the four SRS resources that were defined in the configuration file.
The important field to check is periodicityAndOffset. All four SRS resources use the same periodicity, sl80, which means the SRS repeats every 80 slots. However, the offset value is different for each resource. In this example, the resources are configured with different slot offsets such as 7, 17, 27, and 37.
This means that the four SRS resources are transmitted in the same radio-frame cycle, but they are placed in different slots. They are not transmitted at the same time.
Another important point is the symbol position. For all four SRS resources, resourceMapping shows startPosition 1 and nrofSymbols n1. This means all four resources use the same OFDM symbol position within their slot, and each resource occupies one SRS symbol.
So the difference between the four SRS resources is mainly the slot offset, not the symbol position. They use the same symbol location inside the slot, but they appear in different slots within the 80-slot period.
This confirms what was mentioned in the configuration section. The period was configured by the user, but the slot offset was automatically assigned by the gNB. The actual slot offsets should therefore be checked in the RRC message using periodicityAndOffset.
TTwo SRS resource sets are configured in srs-ResourceSetToAddModList. This confirms that the two resource sets defined in the configuration file are delivered to the UE through the RRC Setup message.
The first resource set is srs-ResourceSetId 0. Its srs-ResourceIdList includes resource 0 and resource 1. This means SRS resource 0 and SRS resource 1 are grouped into this resource set. The usage is set to codebook, so these two SRS resources are used for codebook-related SRS operation.
The second resource set is srs-ResourceSetId 1. Its srs-ResourceIdList includes resource 2 and resource 3. This means SRS resource 2 and SRS resource 3 are grouped into another resource set. The usage is set to antennaSwitching, so these two SRS resources are used for the antenna switching test.
So the RRC message shows the same mapping as the configuration file. Resource 0 and resource 1 are used for codebook. Resource 2 and resource 3 are used for antenna switching.
This is different from the previous one-resource test. In the previous test, both codebook and antenna switching pointed to the same SRS resource. In this test, each usage has its own pair of SRS resources. This makes it easier to check the behavior of multiple SRS resources and to confirm how the gNB assigns them to different slot offsets.
After the UE is attached, you can check whether the Callbox is receiving the SRS as expected. For easier analysis, set the Info filter to SRS. This makes the log viewer show only SRS-related PHY messages, so you can focus on the SRS timing and resource position.
In this example, SRS messages are received repeatedly from the UE. The SFN.slot field is useful for checking the time-domain behavior. Since the SRS resources were configured with period 80, you should see the same SRS pattern repeated every 80 slots.
You can also check whether the slot offsets match the values shown in the RRC message. In the previous RRC Setup example, the four SRS resources were configured with different periodicityAndOffset values. In the PHY log, these should appear as SRS receptions in the corresponding slots.
The prb field shows the frequency-domain position of the received SRS. For example, prb indicates where the SRS resource is placed in the uplink bandwidth.
The symb field shows the time-domain symbol position of the SRS within the slot. In this example, the SRS is shown with symb 12:1. This means the SRS starts at symbol 12 and occupies 1 symbol.
So this log confirms the actual PHY behavior after the RRC configuration is applied. The RRC message tells you how the SRS resources are configured, and the PHY SRS log confirms that the UE is really transmitting SRS at the expected period, slot offset, PRB position, and OFDM symbol position.
You can also check the SNR and EPRE of the received SRS from the statistics plot. This gives you a more visual way to confirm the SRS reception quality after the UE starts transmitting SRS.
To open this plot, click the Analytics button and select the SNR tab. In this tab, you can see several uplink-related traces, including SRS snr and UL SRS EPRE.
SRS snr shows the signal-to-noise ratio of the received SRS. This is useful to check whether the SRS is being received with stable quality.
UL SRS EPRE shows the received energy level of the SRS resource. This is useful to check whether the received SRS power level is stable over time.
In this example, the SRS-related traces are shown together with other uplink measurements such as PUCCH snr, PUSCH snr, UL data EPRE, and UL ctrl EPRE. This allows you to compare the SRS quality with other uplink channels.
If the SRS snr and UL SRS EPRE remain relatively stable, it means the UE is transmitting SRS normally and the Callbox is receiving it consistently. If you see sudden drops or large fluctuations, it may indicate weak uplink power, fading, antenna path issue, or temporary measurement instability.
So the SRS log confirms when and where the SRS is received, while this plot helps confirm how good and stable the received SRS signal is.
Test 3 : 2 SRS Resource on same slot
This test is to show you how to configure multiple resources in one srs_resourceset for the usage of antennaSwitch, but the two resources in the resource set are allocated in same slots in this test. This capability is used by autoconfiguration only as shown in this test.
Configuration
I have used gnb-sa-srs-antenna-switch-auto-2rs.cfg which is copied and modified from gnb-sa.cfg
I am using the default mme, ims config as shown below.
In gnb-sa-srs-antenna-switch-auto-2rs.cfg, it is configured as follows. (
This part shows the common configuration used for Test 3. In this test, the configuration file is gnb-sa-srs-antenna-switch-auto-2rs.cfg. The main purpose of this configuration is to enable SRS and let the gNB generate the detailed SRS resource placement automatically.
NR_TDD is set to 1. This means the cell is configured as NR TDD.
NR_TDD_CONFIG is set to 2. This selects TDD configuration 2 from the Amarisoft sample configuration. This is only the TDD pattern used for this test. SRS itself is not limited to TDD, but antenna switching is mainly meaningful in TDD because the gNB can use the received uplink SRS as a reference for downlink channel condition.
N_ANTENNA_DL is set to 2. This means the gNB is configured with two downlink antenna ports.
N_ANTENNA_UL is set to 2. This means the gNB is configured with two uplink antenna ports. This is important in this test because the SRS antenna switching behavior depends on the uplink antenna capability.
USE_SRS is set to 1. This enables SRS configuration. Without this setting, the SRS configuration block would not be applied.
So this part prepares the basic radio configuration for the auto SRS antenna switching test. The main difference from the previous manual test is that this test uses the auto configuration method. The user enables SRS and defines the high-level condition, while the gNB automatically generates the detailed SRS resource configuration, including the slot placement.
This test uses the AutoSRS method. Instead of manually defining each physical SRS resource, the configuration uses resource_auto and lets the gNB generate the detailed SRS resource configuration automatically.
The codebook part defines the basic SRS resource set for codebook operation. It is configured as periodic, and the period is set to 80 slots. This is the baseline SRS configuration required by the gNB.
The antenna_switching part defines the SRS resource set for antenna switching. It is also configured as periodic with period 80. In this test, allow_XTyR is set to true.
allow_XTyR means that the gNB is allowed to configure the Tx/Rx SRS port combination automatically. It does not directly specify the exact number of Tx and Rx SRS ports in the configuration file. Instead, it only enables this capability.
The actual number of physical SRS resources, the port combination, and the slot distribution are decided by the gNB software. The gNB decides them based on the antenna configuration, UE capability information, BWP bandwidth, and TDD pattern.
So in this test, the user configures the SRS resource only once at a high level. Then the gNB automatically creates the detailed SRS resources needed for antenna switching. This is why this test can generate multiple SRS resources in the same slot, even though the configuration itself does not manually define each resource one by one.
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
When allow_XTyR is enabled, the gNB does not apply the antenna switching SRS blindly. It first checks the UE capability information and verifies what kind of SRS port switching the UE supports.
In this example, the UE capability information message is selected in the RRC log. On the right side, the capability details show the SRS-related capability field. The important IE is supportedSRS-TxPortSwitch. This field tells the gNB what Tx/Rx port switching combination the UE can support for SRS antenna switching.
If the UE reports a proper value in supportedSRS-TxPortSwitch, the gNB can generate the corresponding antenna switching SRS configuration. If the UE does not report a suitable capability, the gNB may not configure the expected antenna switching SRS resources.
So when you run this test with your own DUT, this is one of the first things to check. Make sure the DUT reports the required supportedSRS-TxPortSwitch capability in the UE capability information message. Otherwise, the SRS configuration generated by the gNB may be different from what you expect, or antenna switching SRS may not be configured properly.
In short, allow_XTyR enables the gNB to use UE capability-based SRS antenna switching configuration. The exact SRS port switching mode is not fixed only by the configuration file. It is determined from the antenna configuration and the UE capability reported by the DUT.
Two SRS resource sets are configured in srs-ResourceSetToAddModList. This confirms that the AutoSRS configuration generated two logical SRS resource groups and delivered them to the UE in the RRC reconfiguration message.
The first resource set is srs-ResourceSetId 0.
srs-ResourceIdList 0 and 1 means this resource set uses SRS resource 0 and SRS resource 1.
usage codebook means these two SRS resources are used for codebook-related SRS operation.
The second resource set is srs-ResourceSetId 1.
srs-ResourceIdList 2 means this resource set uses SRS resource 2.
usage antennaSwitching means this resource set is used for SRS antenna switching operation.
So the RRC message shows two different SRS usages. Resource 0 and resource 1 are grouped for codebook. Resource 2 is grouped for antenna switching.
This is slightly different from the previous manual example. In the manual example, the user explicitly configured which SRS resource IDs belong to each resource set. In this AutoSRS example, the user only configured high-level resource_auto settings, and the gNB automatically created the actual SRS resources and resource-set mapping.
This also shows why checking the RRC message is important. The configuration file only shows the intended usage, but the RRC message shows the final resource IDs and how they are actually assigned to codebook and antennaSwitching.
Three SRS resources are configured in srs-ResourceToAddModList. This means the gNB generated three actual physical SRS resources and delivered them to the UE in the RRC reconfiguration message.
srs-ResourceId 0 means the first SRS resource.
srs-ResourceId 1 means the second SRS resource.
srs-ResourceId 2 means the third SRS resource.
These resources are then referenced by the two SRS resource sets configured in srs-ResourceSetToAddModList.
The first resource set is used for codebook. Its srs-ResourceIdList includes resource 0 and resource 1. This means SRS resource 0 and SRS resource 1 are grouped together for codebook-related SRS operation.
The second resource set is used for antennaSwitching. Its srs-ResourceIdList includes resource 2. This means SRS resource 2 is used for the antenna switching operation.
So the mapping is as follows.
SRS resource 0 and SRS resource 1 are used for codebook.
SRS resource 2 is used for antenna switching.
This confirms that the AutoSRS configuration does not simply copy the configuration file one-to-one. The user only configured the high-level resource_auto setting, and the gNB generated the actual number of SRS resources and assigned them to the proper resource sets based on antenna configuration and UE capability.
In this RRC reconfiguration message, you can see that the SRS resources are configured with the same slot timing but different OFDM symbol positions.
The important field is periodicityAndOffset. Both SRS resources use the same value, sl80 : 8. This means both resources are transmitted with the same 80-slot period and the same slot offset. So they are allocated in the same radio frame and the same slot.
The difference is in resourceMapping.
For the first SRS resource, startPosition is set to 2. This means this SRS resource is transmitted at OFDM symbol position 2 within the slot.
For the second SRS resource, startPosition is set to 8. This means this SRS resource is transmitted at OFDM symbol position 8 within the same slot.
Both resources use nrofSymbols n1, so each SRS resource occupies one OFDM symbol.
So the key point is that the two SRS resources are not separated by slot. They are separated by OFDM symbol position inside the same slot. One SRS is transmitted at symbol 2, and the other SRS is transmitted at symbol 8.
This is different from the previous test, where different SRS resources were placed in different slots. In this test, AutoSRS allows the gNB to place multiple SRS resources in the same slot while keeping them separated in the time domain by different OFDM symbols.
For SRS reception and resource-position verification, you can use the SRS log as shown in the previous test, or you can check it graphically from the RB allocation view. This view is useful because it shows where the SRS is placed in time and frequency.
You can open this plot by clicking the RB button. In the RB allocation window, the SRS region is shown on the time-frequency grid. This allows you to visually confirm whether the SRS resources are transmitted in the expected slot and symbol position.
In this example, the SRS resources are shown in the same slot area but at different OFDM symbol positions. One SRS is used for codebook SRS with one resource, and the other SRS is used for antenna switching with two resources. This matches the RRC configuration where the SRS resources were allocated in the same slot but separated by symbol position.
The second view gives a wider time-domain view. You can see the SRS allocations repeated over time. This helps you confirm the periodic behavior and also makes it easier to see whether the SRS appears at the expected timing interval.
So there are two ways to verify this test. The SRS log gives detailed text information such as SFN.slot, PRB, symbol, SNR, and EPRE. The RB allocation plot gives a visual confirmation of the same behavior, showing where the SRS resources are placed in the radio frame.
You can also check the SNR and EPRE of the received SRS from the statistics plot. This gives you a graphical way to confirm the SRS reception quality.
To open this plot, click the Analytics button and select the SNR tab.
SRS snr shows the signal-to-noise ratio of the received SRS. This indicates how clearly the Callbox receives the SRS signal from the UE.
UL SRS EPRE shows the received energy level of the SRS resource. This indicates the received power level of the SRS.
In this example, you can see SRS snr and UL SRS EPRE together with other uplink measurements such as PUCCH snr, PUSCH snr, UL data EPRE, and UL ctrl EPRE. This makes it easier to compare the SRS quality with the overall uplink condition.
If SRS snr and UL SRS EPRE stay relatively stable, it means the UE is transmitting SRS normally and the Callbox is receiving it consistently. If you see a sudden drop or large fluctuation, it may indicate weak uplink power, fading, antenna path issue, or temporary measurement instability.
So the SRS log is useful to check the exact timing and resource position, while this statistics plot is useful to check the quality and stability of the received SRS signal over time.
RRC / NAS Signaling
RrcSetup (SA)
: This is the RrcSetup message sent by gNB to configure NR SA. (
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,
1
},
resourceType periodic: {
},
usage codebook,
p0 -84,
pathlossReferenceRS ssb-Index: 0
},
{
srs-ResourceSetId 1,
srs-ResourceIdList {
2,
3
},
resourceType periodic: {
},
usage antennaSwitching,
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 periodic: {
periodicityAndOffset-p sl80: 7
},
sequenceId 500
},
{
srs-ResourceId 1,
nrofSRS-Ports port1,
transmissionComb n2: {
combOffset-n2 0,
cyclicShift-n2 0
},
resourceMapping {
startPosition 1,
nrofSymbols n1,
repetitionFactor n1
},
freqDomainPosition 0,
freqDomainShift 5,
freqHopping {
c-SRS 11,
b-SRS 3,
b-hop 0
},
groupOrSequenceHopping neither,
resourceType periodic: {
periodicityAndOffset-p sl80: 17
},
sequenceId 500
},
{
srs-ResourceId 2,
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 periodic: {
periodicityAndOffset-p sl80: 27
},
sequenceId 500
},
{
srs-ResourceId 3,
nrofSRS-Ports port1,
transmissionComb n2: {
combOffset-n2 0,
cyclicShift-n2 5
},
resourceMapping {
startPosition 1,
nrofSymbols n1,
repetitionFactor n1
},
freqDomainPosition 0,
freqDomainShift 5,
freqHopping {
c-SRS 11,
b-SRS 3,
b-hop 0
},
groupOrSequenceHopping neither,
resourceType periodic: {
periodicityAndOffset-p sl80: 37
},
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
Enabling Antenna Switching on UEsim
If you are using Amarisoft UEsim as a DUT, you would see srs-antenna switching not suppored in UE capability information message. In order to let UEsim support antenna switching and notify the capability on UEsim, you need to enable channel sim in ue configuration.
Here goes an example configuration : ue-nr-sa-srs-ant-switch-1t2r and folllowing screenshot shows the UE capability Information from UEsim. After the configuration is applied, you can check the UE capability information message in the RRC log.
The important field is supportedSRS-TxPortSwitch. In this example, UEsim reports t1r2. This means the UE supports the SRS Tx port switching capability corresponding to one transmit port and two receive ports.
This capability information is important because the gNB checks the UE capability before configuring antenna switching SRS. If the UE does not report the proper supportedSRS-TxPortSwitch value, the gNB may not generate the antenna switching SRS configuration as expected.
So when you test SRS antenna switching with UEsim, first make sure the UEsim configuration enables the required capability. Then confirm in the UE capability information message that supportedSRS-TxPortSwitch is reported with the expected value.
Here goes an example configuration : ue-nr-sa-srs-ant-switch-1t4r and folllowing screenshot shows the UE capability Information from UEsim. The following example shows the UE capability information reported by UEsim.
In this example, the selected RRC message is UE capability information. On the right side, you can check the SRS antenna switching capability reported by the UE.
The important field is supportedSRS-TxPortSwitch. In this case, the value is t1r4.
supportedSRS-TxPortSwitch t1r4 means the UE reports that it supports SRS transmit port switching for one transmit port and four receive ports. This capability is required when the gNB tries to configure the corresponding antenna switching SRS operation.
So if you want to test the 1T4R antenna switching case with UEsim, you should first make sure that the UEsim configuration enables this capability. Then confirm from the UE capability information message that supportedSRS-TxPortSwitch is reported as t1r4.
This is important because the gNB checks UE capability before applying the antenna switching SRS configuration. If the UE does not report the expected capability, the generated SRS configuration may be different, or the antenna switching SRS may not be configured as intended.
Verifying SRS antenna port number
If you use a later release (e.g, 2024-01-17 or later), you can check the SRS antenna port number from gNB log. (
In the SRS log, antenna switching SRS prints the antenna port number using the ant field. For example, ant=0, ant=1, or ant=2 indicates which antenna port is used for that SRS transmission.
This value is useful when you want to confirm that antenna switching is really happening. If the UE transmits SRS through different antenna ports, the SRS log should show different ant values for the antenna switching SRS entries.
One important point is that the antenna port number is printed only for antenna switching SRS. For normal SRS, such as codebook SRS, the antenna port number is not printed in the log. This is because the antenna port for non-antenna-switching SRS is already determined by the RRC configuration and does not change dynamically.
So when you check the log, you may see some SRS entries with ant information and some SRS entries without it. The entries with ant information correspond to antenna switching SRS. The entries without ant information are normal SRS entries, such as codebook SRS.
