July 2025 – Daniel Estévez

n78 band 5G NR recordings

In my last post about 5G NR, which was part of a series in which I analyzed the signals in a short recording of an idle srsRAN gNB, I mentioned that I had already decoded all the signals that appear in the recording, and that to move on with my 5G series I would need to make and use some more complex real world recordings next.

A 5G band I’m particularly interested in is n78 (3.3 – 3.8 GHz TDD). This is being used to deploy 5G in many European countries, including Spain, as showed by this list in Wikipedia. Due to the large bandwidth available, it is common to see cells with 100 MHz bandwidth in this band.

Galileo OSNMA chain renewal

Galileo OSNMA (open service navigation message authentication) is a cryptographic system that is used to authenticate the navigation message (satellite ephemeris and clocks, etc.) in the Galileo GNSS. I have spoken before about OSNMA in this blog, since I implemented an OSNMA library in Rust a few years back. A good introduction to OSNMA for readers unfamiliar with how it works can be found in Bert Hubert‘s short series of OSNMA posts. The OSNMA system is currently in the public observation test phase.

On July 4, an OSNMA live test notification went out with the following message:

EVENT DESCRIPTION: USERS ARE ADVISED THAT, AS PART OF THE PUBLIC OBSERVATION TEST PHASE ACTIVITIES, A TESLA CHAIN RENEWAL IS PLANNED ON 2025-07-07 10:00 UTC AND THE TRANSITION WILL OCCUR ON 2025-07-08 10:00 UTC. THE TESLA CHAIN RENEWAL PROCESS IS DESCRIBED IN THE OSNMA SIS ICD (LINK).

NOTE THAT USER RECEIVERS SHALL PREVENT THE USE OF ANY CHAIN THAT HAS BEEN SUBJECT TO A RENEWAL PROCESS.

I have used the utilities from the Galmon project to record the Galileo INAV data received by a uBlox GNSS receiver that I have at home. This dataset can be used to test OSNMA implementations and to study how the chain renewal was done. The dataset is publised in Zenodo as “Galileo INAV data for OSNMA chain renewal test in July 2025“. In this post I study the chain renewal using my galileo-osnma Rust implementation.

About FLLs with band-edge filters

Using band-edge filters for carrier frequency recovery with an FLL is an interesting technique that has been studied by fred harris and others. Usually this technique is presented for root-raised cosine waveforms, and in this post I will limit myself to this case. The intuitive idea of a band-edge FLL is to use two filters to measure the power in the band edges of the signal (the portion of the spectrum where the RRC frequency response rolls off). If there is zero frequency error, the powers will be equal. If there is some frequency error, the signal will have more “mass” in one of the two filters, so the power difference can be used as an error discriminant to drive an FLL.

The band-edge FLL is presented briefly in Section 13.4.2 of fred harris’ Multirate Signal Processing for Communication Systems book. Additionally, fred also gave a talk at GRCon 2017 that was mainly focused on how band-edge filters can also be used for symbol timing recovery, but the talk also goes through the basics of using them for carrier frequency recovery. Some papers that are referenced in this talk are fred harris, Elettra Venosa, Xiaofei Chen, Chris Dick, Band Edge Filters Perform Non Data-Aided Carrier and Timing Synchronization of Software Defined Radio QAM Receivers and fred harris, Band Edge Filters: Characteristics and Performance in Carrier and Symbol Synchronization.

Recently I was looking into band-edge FLLs and noticed some problems with the implementation of the FLL Band-Edge block in GNU Radio. In this post I go through a self-contained analysis of some of the relevant math. The post is in part intended as background information for a pull request to get these problems fixed, but it can also be useful as a guideline for implementing a band-edge FLL outside of GNU Radio.