• Kirill Smelkov's avatar
    software/ors-amarisoft: enb: Take frequencies control into our hands · 37b1b28d
    Kirill Smelkov authored
    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
    
    xlte@6cb9d37f
    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 xlte@e716ab51...8e606c64 ;
        nrarfcn egg: https://pypi.org/project/nrarfcn/
    37b1b28d
libinstance.jinja2.cfg 10.4 KB