GitLab

Joanne reports that for N79 and DL NR ARFCN 720000 dl2ssb returns that
same 720000 and a phone cannot connect to the base station. In contrast
Amarisoft lteenb chooses SSB NR ARFCN = 720288 for the above setup and
the phone connects ok.

The problem turns out to be that in b8065120 (nrarfcn: New package to do
computations with NR bands, frequencies and NR-ARFCN numbers.) I missed
that the table for Applicable SS raster entries besides GSCN range for
each band also specifies conditions for which particular GSCNs are
allowed to be used inside that range. For example for N79 it is only
GSCNs that are multiple of 16:

https://github.com/blevic/nrarfcn/blob/7ece6a11/nrarfcn/tables/applicable_ss_raster_fr1.py#L60

Besides missing the "multiple of" condition, I also missed exceptional
note conditions where instead of providing a range TS 38.104 specifies
particular set of allowed GSCNs. For example for N39 and SCS=15 kHz only
the following set of GSCNs is allowed to be used for SSB:

    {4707, 4715, 4718, 4729, 4732, 4743, 4747, 4754, 4761, 4768, 4772, 4782, 4786, 4793}

https://github.com/blevic/nrarfcn/blob/7ece6a11/nrarfcn/tables/applicable_ss_raster_fr1.py#L39
https://github.com/blevic/nrarfcn/blob/7ece6a11/nrarfcn/tables/applicable_ss_raster_fr1.py#L13

-> Fix SSB calculation logic to take all that into account. This fixes
N79 case and also highlights previous problems in our tests for
above-mentioned n39 and for "multiple of" and "exceptional" cases in FR2.

Also add explicit test for N77 because we use that band in the ORS.

/reported-and-confirmed-by @jhuge
/reported-on nexedi/slapos!1729 (comment 227244)
/reviewed-on !11, nexedi/slapos!1729 (comment 227281)

Contrary to earfcn, where band can be automatically deduced from earfcn
number because 4G bands never overlap, most functions in nrarfcn accept
as input parameters both nr_arfcn and band, because 5G bands can and do
overlap. As the result it is possible to invoke e.g. dl2ul with
dl_nr_arfcn being outside of downlink spectrum of specified band.

However in b8065120 I've made a thinko and handled such situation with
simple assert which does not lead to useful error feedback from a user
perspective, for example:

    In [2]: xnrarfcn.dl2ul(10000, 1)
    ---------------------------------------------------------------------------
    AssertionError                            Traceback (most recent call last)
    Cell In[2], line 1
    ----> 1 n.dl2ul(10000, 1)

    File ~/src/wendelin/xlte/nrarfcn.py:85, in dl2ul(dl_nr_arfcn, band)
         83 if dl_lo == 'N/A':
         84     raise AssertionError('band%r does not have downlink spectrum' % band)
    ---> 85 assert dl_lo <= dl_nr_arfcn <= dl_hi
         86 ul_lo, ul_hi = nr.get_nrarfcn_range(band, 'ul')
         87 if ul_lo == 'N/A':

    AssertionError:

The issue here is that asserts can be used to only verify internal
invariants, and that reported error does not provide details about which
nrarfcn and band were used in the query.

-> Fix this by providing details in the error reported to incorrect
module usage, and by consistently raising ValueError for "invalid
parameters" cases.

The reported error for above example now becomes

    ValueError: band1: NR-ARFCN=10000 is outside of downlink spectrum

Do a package for converting DL/UL NR-ARFCN in between each other and to
convert DL NR-ARFCN to SSB NR-ARFCN. The API mimics xlte.earfcn added in 6cb9d37f.

xlte.nrarfcn complements pypi.org/project/nrarfcn, which we use here under the hood.

See package documentation for API details.