software/ors-amarisoft: enb: Take frequencies control into our hands
Currently when setting up cells we allow users to input
- dl_earfcn for LTE, and
- dl_nr_arfcn and nr_band for NR
and from that lteenb automatically computes
- ul_earfcn for LTE, and
- ul_nr_arfcn and ssb_nr_arfcn for NR
everything kind of works out of the box for eNB case when there is simple SDR Radio Unit.
Then there are also the following cases:
1. we also need to set UL frequency when configuring Lopcomm RU, or any other ORAN-based Radio Unit.
2. we also need to specify DL/UL frequencies in MHz when configuring Lopcomm RU.
3. when configuring NR peercell it is required to set ssb_nr_arfcn. It is also
required to set both dl_nr_arfcn and ul_nr_arfcn, and so far we were setting
only DL one and using it for both assuming TDD band.
4. when configuring UEsim we need to specify both dl_nr_arfcn and ssb_nr_arfcn for NR cells.
So the problem is that even though lteenb automatically computes UL and SSB
frequencies, there is no way for us to reuse results of that computation for
scenarios outside of "simple enb" case.
As the result we kind of workaround that currently with exposing additional
parameters and asking users to look into enb, probably its `cell phy` output,
with the following:
---- 8< ---- (from UEsim)
"ssb_nr_arfcn": {
"title": "SSB NR ARFCN",
"description": "SSB NR ARFCN, you can retrieve from ENB/GNB side",
or use additional parameters just for ul_earfcn and frequency-in-MHz:
---- 8< ---- (from ru/lopcomm)
"txa0cc00_center_frequency": {
"title": "Lopcomm ORAN DL Center Frequency in MHz (TXA0CC00)",
"description": "Lopcomm ORAN Center Frequency in MHz (TXA0CC00)",
"type": "number",
"default": 2140
},
"rxa0cc00_center_frequency_earfcn": {
"title": "Lopcomm ORAN UL Center Frequency EARFCN (RXA0CC00)",
"description": "Lopcomm ORAN Center Frequency EARFCN (RXA0CC00)",
"type": "number",
"default": 18300
},
"rxa0cc00_center_frequency": {
"title": "Lopcomm ORAN UL Center Frequency in MHz (RXA0CC00)",
"description": "Lopcomm ORAN Center Frequency in MHz (RXA0CC00)",
"type": "number",
"default": 1950
},
which prevents automation, opens the door for inconsistencies and puts the load
to resolve all that on users.
The root cause of the problem is that there is no way to access at
instantiation time what lteenb would compute internally. But DL<->UL conversion
and DL->SSB conversion is not a difficult task and we can do that on our own.
-> Do that here and solve all the problems listed above in one go.
For frequency computations we use my xlte.earfcn and xlte.nrarfcn modules and
upstream nrarfcn egg. For this xlte is updated(*) to primarily pick up
kirr/xlte@6cb9d37f
kirr/xlte@b8065120
and the rest of the conversion is in slaplte to use corresponding dl2ul and
dl2ssb routines.
For consistency ul_earfcn and ul_nr_arfcn now become input parameters for LTE
and NR cells, but optional. If they are absent - they are computed with
defaults, but a user can now control them explicitly. The same applies for
ssb_nr_arfcn.
This patch does not convert UEsim yet, because UEsim does not use rulib yet and
will be handled all in one go in a follow-up step.
The computation routines are thoroughly tested. First they have unit tests
inside XLTE itself, then we also update our tests in generic test/test.py here
with explicitly checking that correct numbers are emitted for UL and SSB
frequencies, and third I've also verified SSB computation results with respect
to https://tech-academy.amarisoft.com/OutOfBox_UEsim_SA.html#Tips_SSB_Frequency .
All this creates a base to be sure that the computations are correct and we are
indeed safe to switch our frequencies computation modules.
(*) full upgrade brings kirr/xlte@e716ab51...8e606c64 ;
nrarfcn egg: https://pypi.org/project/nrarfcn/
Showing
Please register or sign in to comment