Be Mindful of 5G ARFCN Values

[rcbarke]

EDIT: Please see the bottom of this thread. In my initial post was correct that the ARFCN expressed in the sample config files (368500) is not consistent with a 1805MHz downlink frequency, however, I was incorrect as to why the calculations were off. The root cause was due desynchronized configuration files in a complex software architecture.

Hello all,

I am copying an email thread sent to my team below for reference. We have found that ARFCN values within the sample srsRAN configuration files are incorrect in some cases. My postulation based on prior experience is below. Note that ARFCN does not seem to impact the simulation within the srsRAN framework itself, and seems to function as a simple text descriptor. However, it is crucial for channel modeling or channel estimation when using srsRAN with GNU Radio. Note that 4G EARFCN and 5G ARFCN are not on the same scale as explained below. Be mindful when re-using the values from the configuration files in advanced calculations.

Re: Final PHY Layer Configurations
​​
I believe the reason WHY the ARFCN descriptor in srsRAN is incorrect is because they renamed the 4G EARFCN values to 5G ARFCNs in R15 when 5G launched.

I believe this to be the case because n3's EARFCN is three orders of magnitude (60dB offset) from its ARFCN. Thus, the incorrect formula in the original note provides an f_dl = 1.8 kHz instead of 1.8GHz.

I've seen this mistake in industry before, it's easy to make, however 4G EARFCN and 5G ARFCN are on two completely different scales.

Best,
Ryan

From: Ryan Barker [email protected]
Sent: Thursday, January 2, 2025 12:39 PM
To: Tolunay Seyfi [email protected]
Cc: alireze [email protected]; Fatemeh Afghah [email protected]
Subject: Fw: Final PHY Layer Configurations

Hi Team,

I propose, as aligned with our call today:

1. We leverage the path_loss_correct formula given below during model training to correct the 120dB offset we are currently experiencing.
2. We do not modify the channel modeling presented below.

Path Loss
srsRAN contains the following cell_cfg parameters: dl_arfcn, band, channel_bandwidth_MHz, common_scs, plmn, tac.

However, the ARFCN value is wrong and a plain text descriptor. It does not impact RF propegation. That is, srsRAN is still broadcasting 1805MHz (1.8 GHz) during simulation.

When we designed the path loss formula for the agent, we used the ARFCN value:
f_dl = ARFCN_DL – ARFCN_REF # Should be 1805 MHz for our settings
path_loss = 20log10(d_km) + 20log10(f_dl_mhz) + 20log10(4*pi/c)

Also, the distance values in the RL Agent are expressed in meters, not km. This conversion is a 60 dB shift in the distance term. This was not considered in our initial path loss formula; I found this discrepancy in the source code after the model was trained. We will correct and retrain.

We reduced the final 2 terms and put the formula in the RL agent, with both the f_dl_wrong_ARFCN, we get:
path_loss_trained = 20 * math.log10(d_m) - 82.25

The f_dl_actual =1805 (MHz), thus the correct formula is:
path_loss_correct = 20log10(d_m) + 37.58

Thus, the formula we used during model training is incorrect by a 120dB offset (60dB due to distance, 60dB due to f_dl).

Channel Modeling
Attached you will find the current gnuradio configuration. The email below summarizes the channel modeling configuration.

To calculate the frequency offset for the doppler shift, see the below formulas:
Version 1 (configurable carrier frequency and sampling rate):
def f(v, f_carrier=1.805e9, f_sampling=11.52e6, c=3e8):
"""
Calculate the GNU Radio frequency offset for a given velocity.

Parameters:
- v (float): Velocity in meters per second (m/s).
- f_carrier (float): Carrier frequency in Hz. (Default = 1.805e9 for n3 DL FDD)
- f_sampling (float): Sampling rate in Hz. (Default = 11.52e6)
- c (float): Speed of light in m/s. (Default = 3e8)

Returns:
- float: Frequency offset relative to the sampling rate.
"""
return (v / c) * f_carrier / f_sampling

Example usage:

velocity = 96 # m/s, e.g., ~345 km/h
frequency_offset = f(velocity)
print(f"Frequency Offset for {velocity} m/s: {frequency_offset:.6g}")

Version 2 (Simplified for our settings - n3 1805 DL, 11.52e6 MSCS):
def freq_offset(v):
"""
Returns the GNURadio frequency offset (dimensionless) for a velocity v (m/s)
given:
- f_carrier = 1.805 GHz
- f_sampling = 11.52 MHz
- c = 3e8 m/s
"""
K = 5.22e-7 # Derived constant for n3 band (1805 MHz) & 11.52 MHz sampling
return K * v

Example usage:

velocity = 96 # m/s
offset = freq_offset(velocity)
print(f"Frequency offset for {velocity} m/s is approximately {offset:.5g}")
Example: For v=96m/s (∼345km/h) [This is the upper limit of srsRAN with constant velocity]
foffset​=5.22×10−7×96≈5.0×10−5

srsRAN PHY Upper Bound Limitations
Taps: [0.85+0.25j, 0.4-0.1j, 0.2+0.1j] (reduced in our config to improve QoS)
Noise Voltage: 0.01 (used in our config)
Frequency Offset: 0.00005 (96 m/s, assumes constant velocity through the entire simulation, reduced to 0.00000584 (40 kmph / 25mph) in our config)
Epsilon: 1.0

Best,

Ryan Barker

Graduate Researcher
IS-WiN Laboratory
M.S. Computer Engineering, Intelligent Systems, Class of 2026
B.S. Computer Engineering, Communication Systems & Networks, Class of 2016

[pgawlowicz]

Hi Ryan,
Thank you for the report.
Thank you for the report. I’m not sure if I fully understand the issue you’re referring to with the 5G ARFCN. Could you please clarify or provide more details about the specific problem?
Best Regards,
Piotr

[carlo-gal]

Hi Ryan, I am afraid I didn't understand what the problem is. Before moving to the explanation of "why" this is wrong, could you explain "what" is wrong. For example, what do you expect to see and what do you see, instead?
That's the part I am missing. Once I get this, we can move to the next step.

Kind regards,
Carlo

[rcbarke]

Hi Ryan, I am afraid I didn't understand what the problem is. Before moving to the explanation of "why" this is wrong, could you explain "what" is wrong. For example, what do you expect to see and what do you see, instead? That's the part I am missing. Once I get this, we can move to the next step.

Kind regards, Carlo

No problem Carlo, my apologies for getting ahead of myself. I recently performed a free space path loss derivation on my gnuradio and srsRAN emulated n3 10MHz channel to integrate channel modeling into my signal via gnuradio. When I accounted for frequency attenuation, I used the ARFCN value in the gNB config file, 368500, to calculate the downlink FDD frequency.

The point of confusion stems from the frequency value I am observing. As shown by the math in my previous reply, I would anticipate a center channel frequency value of 1842.5MHz for an ARFCN value of 368500. However, when srsgNB is started within an actual deployment, the CLI output shows a downlink FDD frequency of 1805MHz. If this is the case, I would anticipate an ARFCN value of 361000, and not 368500.

The core question is: When srsGNB is started, how are the CLI output frequencies being displayed? Are they calculated from the ARFCNs within the gNB configuration file, using other config parameters, static, etc.?

I was already able to derive a FSPL formula that now returns values within the expected range, using 1805MHz for the frequency term. Presently I'm simply attempting to determine why my config file implies we are broadcasting mid-band n3 whereas the CLI output states low-band n3.

I also already realize that FSPL is not the most granular or effective detection mechanism for this, since it is logarithmic scale. However, for more fine grained linear formulas, precision is crucial.

The other items I've mentioned above were paths I walked down during my attempts at diagnosing this, and those hypotheses have all have been disproven since the initial post was created. Sorry if this was difficult to follow.

[pgawlowicz]

Hi Ryan, I have just started a gnb with the following config:

cell_cfg:
  dl_arfcn: 368500                  # ARFCN of the downlink carrier (center frequency).
  band: 3                           # The NR band.
  channel_bandwidth_MHz: 10         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 15                    # Subcarrier spacing in kHz used for data.
  ...

and this is the output:

--== srsRAN gNB (commit 1475c97df7) ==--

Lower PHY in executor blocking mode.
Available radio types: zmq.
Cell pci=1, bw=10 MHz, 1T1R, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

[rcbarke]

Hi Ryan, I have just started a gnb with the following config:

cell_cfg:
  dl_arfcn: 368500                  # ARFCN of the downlink carrier (center frequency).
  band: 3                           # The NR band.
  channel_bandwidth_MHz: 10         # Bandwith in MHz. Number of PRBs will be automatically derived.
  common_scs: 15                    # Subcarrier spacing in kHz used for data.
  ...

and this is the output:

--== srsRAN gNB (commit 1475c97df7) ==--

Lower PHY in executor blocking mode.
Available radio types: zmq.
Cell pci=1, bw=10 MHz, 1T1R, dl_arfcn=368500 (n3), dl_freq=1842.5 MHz, dl_ssb_arfcn=368410, ul_freq=1747.5 MHz

Thank you very much for this, Piotr: Due to your screenshot, I just determined what happened, and it is unrelated to the math or srsRAN. My apologies for the red herring.

Due to the complexity of our end-to-end ORAN software architecture (Open5GS 5GC, OSC RIC, srsgNB, srsUE, etc.) and the need to align several parameters across applications, I have built an automated deployment pipeline around it. This contains build and deploy scripts, as well as a configs directory. When the build script is executed, config files within the configs directory are staged into their appropriate locations within the software architecture. Then, the deploy script executes commands to actually start each piece of software in appropriate sequence.

I have been referencing our gNB's config from the top level configs directory, however, your example caused me to realize that what we have in the top level configs directory is not aligned with what's in srsgNB's build folder. I just pulled the history on the latter file, and it looks like someone else in my lab has been manually editing build files instead of leveraging the build scripts.

After synchronizing the files, I am now seeing the same thing you are. I'll address this with my team and appreciate your help trailing it down. I have been emphasizing that working with complex, highly modular software requires a structured approach with my team, and this is a great example of why. Several other active projects are much more contained, singular architectures, so several members of my team are still adjusting to working in larger, more complex environments.

Thanks again for your help!

[carlo-gal]

You are welcome!