Troubleshooting 5G FDD Signal Decoding With Sni5Gect

by Alex Johnson 53 views

h1. Troubleshooting 5G FDD Signal Decoding with sni5Gect

h2. Understanding the Challenge: Decoding FDD Signals

So, you're diving deep into the world of 5G NR and trying to decode signals, specifically in Frequency Division Duplex (FDD) mode, using the powerful sni5Gect tool. It's a common hurdle many enthusiasts and researchers face: while Time Division Duplex (TDD) might have been cooperative, FDD seems to be giving you a bit of a headache. You've noticed that the decoding logs are filled with errors like "PBCH CRC error" and messages indicating "Not in sync," preventing the successful decoding of essential system information blocks (SIBs) and data channels like PDSCH and PUSCH. This is a frustrating, yet often solvable, problem. The good news is that you're not alone, and with a systematic approach, we can work towards getting your FDD decoding up and running. Your situation, where TDD mode works flawlessly with the same hardware setup, is a crucial piece of information. It suggests that the fundamental components – your USRP devices, the capture software, and the general environment – are likely functioning correctly. The issue is probably specific to the nuances of FDD signal processing within sni5Gect or the configuration of your experiment for FDD.

Why is FDD different from TDD for decoding?

At its core, the difference lies in how uplink and downlink communication are separated. In FDD, dedicated frequency bands are allocated for uplink and downlink, meaning they happen simultaneously on different frequencies. In contrast, TDD uses the same frequency band but divides time slots for uplink and downlink transmissions. This fundamental difference impacts how synchronization, channel estimation, and decoding algorithms are implemented. For a tool like sni5Gect, which analyzes captured radio signals, this means that the signal characteristics it needs to look for, especially during the initial synchronization and broadcast channel decoding phases, will differ significantly between TDD and FDD. The synchronization process, for instance, relies on specific preambles and signals that are configured differently based on the duplexing mode. In FDD, the receiver needs to be acutely aware of the separate downlink and uplink frequencies and how they relate to each other, even though they are captured independently in your setup. The fact that your GNU Radio spectrum scan shows a strong signal at the expected frequency and that there's no apparent external interference is also a positive sign. It means the signal is present and strong enough to be detected, but the interpretation of that signal by the decoder is where the problem lies. We need to ensure that sni5Gect is configured to understand the specific FDD parameters of the network you are trying to decode.

Initial Diagnosis: Configuration and Parameters

Your approach of basing your configuration file on a known working example (configs/srsran-n3-20MHz-yaml) is a sensible starting point. However, FDD configurations often require meticulous attention to parameters that might be less critical or differently handled in TDD. Key areas to scrutinize include:

  • Frequency Settings: Ensure that the center frequencies for both your uplink capture and downlink capture are correctly set and that sni5Gect understands the relationship between them. In FDD, the difference between the downlink and uplink carrier frequencies is a fundamental network parameter.
  • Bandwidth: Double-check that the bandwidth specified in your sni5Gect configuration matches the actual signal bandwidth being captured (e.g., 10 MHz, 20 MHz).
  • Cell Parameters: Parameters like physcellid, tac, and mnc/mcc need to be accurately reflected in your configuration. While these are important for both modes, their interaction with FDD-specific timing and frequency offsets can be critical.
  • DL/UL Configuration: Look for any specific FDD-related configurations within sni5Gect or the underlying srsRAN library that might need adjustment. This could involve parameters related to the frequency offset between the downlink and uplink carriers, or how the system assumes the relationship between the two.

Given that you have the GNU Radio waterfall plot showing a strong signal, it confirms that the RF front-end and capture process are likely doing their job. The problem then pivots to the software's ability to correctly interpret this captured data in the context of FDD. We need to bridge the gap between the raw signal samples and the logical decoding process that sni5Gect performs. Your detailed description of the capture environment and method is invaluable. It allows us to rule out many common hardware and setup issues. The focus now sharpens on the software configuration and the specific algorithms sni5Gect uses to synchronize and decode FDD signals.

Diving Deeper into FDD Specifics with sni5Gect

To effectively decode FDD signals with sni5Gect, we need to go beyond the general configuration and pinpoint parameters that are particularly sensitive in an FDD context. You've correctly identified that your current configuration, while based on a TDD example, might not be perfectly tailored for FDD. The errors you're seeing, like the "PBCH CRC error" and failure to synchronize, strongly suggest that the initial signal acquisition and decoding of the Physical Broadcast Channel (PBCH) are not succeeding. The PBCH carries essential system information that the UE (your 5G smartphone) and the decoder need to establish a connection and understand the cell's basic parameters. If this initial step fails, nothing else can proceed.

Focusing on Synchronization and PBCH Decoding in FDD

The synchronization process in 5G NR is crucial. It involves finding the start of a Transmission Time Interval (TTI) and acquiring the cell identity. This is often achieved by detecting synchronization signals like the PSS (Primary Synchronization Signal) and SSS (Secondary Synchronization Signal), followed by decoding the PBCH. In FDD, the downlink synchronization process is paramount because it establishes the timing reference for all subsequent downlink reception. The logs indicate that tti=3128 is being processed, but the synchronization fails, evidenced by Not in sync tti: 3128. The PBCH CRC error is a direct consequence of poor synchronization or incorrect channel estimation. If the received signal is not correctly aligned in time and frequency, or if the channel model used for demodulation is inaccurate, the Cyclic Redundancy Check (CRC) on the PBCH data will inevitably fail.

Key FDD Configuration Parameters to Re-evaluate:

When working with FDD, the relationship between the uplink and downlink carrier frequencies is a defining characteristic. Your srsran-n1-10MHz-myself.yaml configuration file is where we need to make the most critical adjustments. Let's break down some potential areas:

  • carrier_frequency vs. uplink_carrier_frequency and downlink_carrier_frequency: Some configurations might expect a single carrier_frequency which implicitly defines both, or they might require explicit uplink_carrier_frequency and downlink_carrier_frequency settings. Given you are capturing uplink and downlink separately, you need to ensure that sni5Gect is correctly informed about both frequencies and how they relate. For instance, if your gNB is configured to transmit on 2156.5 MHz (downlink) and the UE is transmitting on 1966.5 MHz (uplink), these exact values and their difference are critical. Ensure these are set correctly in your sni5Gect configuration.
  • N_RB_DL and N_RB_UL: The number of Resource Blocks for downlink (N_RB_DL) and uplink (N_RB_UL) must match the network configuration. While the bandwidth (e.g., 10 MHz) usually dictates this, ensure they are explicitly set and consistent with the captured signal's characteristics.
  • tdd_config parameter: If your configuration file has a tdd_config section, it must be either removed or set to indicate FDD mode. Often, tools default to TDD if this isn't explicitly set or if a parameter implies TDD. For FDD, this section is generally not applicable or should be configured to reflect FDD operation.
  • frequency_offset: Sometimes, a parameter for frequency_offset between the expected signal and the actual received signal might be necessary. While your CFO (Carrier Frequency Offset) estimate (cfo_hz=1792.96) is logged, an initial offset in the configuration might help the synchronization algorithms lock on more reliably. This is less common but worth considering if other steps fail.
  • sfn_subframe_offset: While primarily for TDD, ensure this isn't causing issues. In FDD, the system frame number (SFN) advances independently for uplink and downlink in some implementations, but typically, the downlink SFN is the reference.

Hardware and Capture Considerations for FDD

Your setup uses separate USRPs for uplink and downlink capture, which is a standard approach. However, for FDD, it's paramount that the timing between these two capture devices is as synchronized as possible, even though they are capturing on different frequencies. While sni5Gect processes them as separate files, any gross temporal misalignment could confuse the higher-level decoding logic, especially if it tries to correlate events. Fortunately, your usrp_capture logs don't show obvious issues here. The fact that you used the srsRANRF library for capture, which is designed to work with srsRAN components (the basis for sni5Gect), is a strong point.

  • Clock Synchronization: Ensure your USRPs, especially if they are not linked via a shared clock or GPSDO, are reasonably synchronized. While software handles the fine synchronization, gross clock drift could be problematic.
  • Sampling Rate: You've set a sampling rate of 23.04 MSps. This is quite specific and often derived from the master clock rate. Ensure this is consistent and sufficient for the 10 MHz bandwidth you are targeting. A common rule of thumb is to have a sampling rate at least 1.2 to 1.5 times the channel bandwidth, but 23.04 MSps is quite high for 10 MHz, which is good – it gives you room for filtering and potential frequency offsets.
  • Gain Settings: The gain of 40 (-g 40) is applied to all devices. While this seems consistent, ensure it's not causing saturation on one device and too little signal on another. Visual inspection of the raw IQ samples or intermediate plots (if possible) could reveal this.

The logs you provided, particularly shadower_runtime.log, show repeated PBCH CRC error and Not in sync. This strongly points towards an issue in the initial synchronization phase. The cfo_hz=1792.96 and delay=-12.57us are estimates made after an attempt to synchronize. If synchronization fails, these values might not be accurate or relevant. The SNR=-23.01 is quite low, which could indicate a weaker signal than expected or an issue with channel estimation. However, your GNU Radio observation of a strong signal suggests the former might be less likely, putting more focus on the latter.

Refining the sni5Gect Configuration for FDD Success

We've established that the core of the problem likely lies in how sni5Gect interprets the captured FDD signals, specifically during the critical initial synchronization and PBCH decoding stages. You've meticulously detailed your capture environment and methods, which helps us eliminate many common hardware and setup pitfalls. Now, let's refine the sni5Gect configuration (srsran-n1-10MHz-myself.yaml) to better suit FDD operation. The goal is to provide the decoder with the precise parameters it needs to lock onto the downlink signal, extract the necessary control information, and proceed with decoding.

Key Configuration Adjustments for FDD:

When dealing with FDD, the separation of uplink and downlink frequencies is the defining characteristic. Your configuration must reflect this accurately. Based on typical srsRAN configurations and the common parameters for FDD, here are the specific elements within your srsran-n1-10MHz-myself.yaml file that warrant the most attention:

  1. Explicitly Define Downlink and Uplink Frequencies:

    • The most critical adjustment for FDD is ensuring that the software understands the distinct carrier frequencies for downlink and uplink. Your current setup captures them separately. In your sni5Gect configuration, you'll likely need parameters that specify both the downlink carrier frequency (which is what the UE receives and what sni5Gect needs to decode from your dl.fc32 file) and, possibly, the uplink carrier frequency (which sni5Gect might use for context or specific FDD-related calculations, though primarily it decodes the downlink channel).
    • Look for parameters like downlink_carrier_frequency and uplink_carrier_frequency. If only a single carrier_frequency is present, ensure it's set to the downlink frequency, as this is what the UE synchronizes to first for reception. Then, check if there's a separate parameter to define the uplink frequency or the frequency offset between them. For example, if your dl.fc32 corresponds to a downlink frequency of 2156.5 MHz and ul.fc32 to an uplink frequency of 1966.5 MHz, these values must be correctly represented.

  2. Ensure tdd_config is Absent or Set for FDD:

    • Many configuration examples default to TDD or have a tdd_config section. For FDD, this section is irrelevant and can cause misinterpretations. Remove any tdd_config block entirely from your srsran-n1-10MHz-myself.yaml. If there isn't an explicit tdd_config parameter, that's fine, but ensure no other parameter implicitly sets the mode to TDD.

  3. Verify Bandwidth and Resource Allocation:

    • N_RB_DL: Number of Resource Blocks for Downlink. This should correspond to the 10 MHz bandwidth. For 10 MHz, this is typically 50 RBs. Ensure this is set correctly.
    • bandwidth_hz: While N_RB_DL often implies bandwidth, explicitly setting bandwidth_hz to 10e6 can sometimes help.

  4. duplex_mode Parameter:

    • Some srsRAN configurations allow for an explicit duplex_mode parameter. If present in your sni5Gect configuration schema, set it to FDD.

  5. System Information Block (SIB) Configurations:

    • While sni5Gect's primary job is to capture and decode, ensuring that the configuration aligns with what the gNB is actually broadcasting is key. The failure to decode SIBs suggests that even if synchronization occurs momentarily, the subsequent decoding of SIB1 (which contains crucial information like cell barring status, scheduling of other SIBs, and system frame number) is failing. This could be due to incorrect parameters related to SIB scheduling or content.

  6. Frame Synchronization and Timing:

    • Although FDD uses separate frequencies, the timing of frames (System Frame Numbers - SFNs) and subframes is still critical. Ensure that the parameters related to frame timing, if any are exposed in your sni5Gect config, are sensible. However, issues here are usually secondary to initial frequency and time synchronization.

Practical Steps for Your srsran-n1-10MHz-myself.yaml:

Let's assume your configuration file looks something like this (simplified example):

# ... other global settings ...
phy:
  type: "nr"
  # Ensure this reflects the actual downlink carrier frequency from your capture
  carrier_frequency: 2156500000 # Example: Adjust to your actual DL frequency
  # If there's a separate parameter for uplink, define it here:
  # uplink_carrier_frequency: 1966500000 # Example: Adjust to your actual UL frequency
  # Or a frequency offset parameter:
  # frequency_offset_hz: 190000000 # Example: DL freq - UL freq
  N_RB_DL: 50
  N_RB_UL: 50 # Might be less relevant for decoding DL, but good to match
  bandwidth_hz: 10000000
  # Remove or ensure this is not present/set for TDD:
  # tdd_config:
  #   ... TDD specific parameters ...
  # If available, explicitly set duplex mode:
  # duplex_mode: "FDD"
# ... other srsRAN or sni5Gect specific settings ...

Reviewing Your Capture Logs and Environment:

  • shadower_runtime.log Analysis: The repeated PBCH CRC error and Not in sync are the key indicators. This means the demodulation of the PBCH data is failing. The SNR=-23.01 is concerningly low, which could suggest:

    • Weak Signal: Despite your GNU Radio observation, the signal might be attenuated or noisy by the time it reaches the decoder's processing chain.
    • Incorrect Channel Estimation: The synchronization process (PSS/SSS detection) might be succeeding at a basic level, but the subsequent channel estimation for PBCH demodulation is inaccurate. This is often tied to incorrect timing or frequency offsets, or mismatched parameters in the phy configuration.
    • Hardware Issues: While TDD worked, FDD might expose subtle differences. Ensure the antenna configuration and cabling for the downlink capture are optimal.

  • Hardware Setup: Your setup with two PCs and multiple USRPs is robust. The key is the consistent configuration of these components. Make sure the sampling_rate and master_clock_rate in your usrp_capture commands precisely match what sni5Gect expects or is configured for. The 192.168.40.2 address for the X300 implies a network connection, ensure this is stable.

By systematically adjusting the FDD-specific parameters in your sni5Gect configuration and re-evaluating the captured signal quality, you should be able to overcome these decoding challenges. The journey to successful FDD signal decoding often involves meticulous parameter tuning.

For further exploration into 5G NR standards and the intricacies of FDD operation, I recommend consulting the official 3GPP specifications. You can find detailed information on the physical layer procedures and channel structures in documents like 3GPP TS 38.211 (Physical channels and modulation) and 3GPP TS 38.213 (Physical layer procedures), which are foundational for understanding these signals.