An error occurred fetching the project authors.
  1. 29 Nov, 2024 1 commit
  2. 26 Nov, 2024 1 commit
  3. 09 Oct, 2024 1 commit
  4. 06 Sep, 2024 1 commit
  5. 13 Feb, 2024 17 commits
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Cosmetics · acd01805
      Kirill Smelkov authored
      Typos, whitespace changes, etc...
      acd01805
    • Kirill Smelkov's avatar
      software/ors-amarisoft: ue: Generalize UEsim · 30179be5
      Kirill Smelkov authored
      Rework UEsim to be able to work with multiple cells, multiple radio units(*),
      multiple UE all at the same time. RU, CELLs and UEs are now configured,
      simiularly to eNB, via shared instances. Add tests.
      
      Contrary to ORS don't care about backward compatibility here because currently
      we have just a few UEsim deployments and migrating them should be easy.
      
      Please see added schemas, tests and updates slapos-render-config on how to use
      the new system.
      
      (*) contrary to eNB UEsim does not allow to use one RU for two cells,
      30179be5
    • 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
      
      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/
      37b1b28d
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Introduce txrx_active generic RU parameter · 45378fec
      Kirill Smelkov authored
      Radio Units like Lopcomm ORAN require explicit activation for the radio.
      Generalize this and introduce a generic parameter for explicit activation of
      the radio on any RU. Default it to _INACTIVE_ so that radio happens only when
      it is explicitly asked to be on for real. But preserve backward compatibility
      for ORS which used to do "radio on" by default. disable_sdr becomes
      ORS-specific parameter.
      
      Lopcomm-specific txa0cc00_active and rxa0cc00_active go away and are replaced
      by txrx_active usage.
      45378fec
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Make tx_gain/rx_gain to be generic RU parameters · a6772923
      Kirill Smelkov authored
      I.e. apply not only to SDR but to all Radio Units and expecting that they apply
      to them with the same uniform semantic of controlling Tx/Rx amplifiers on on
      the RU.
      
      - For SDR nothing is changed.
      - For Lopcomm txa0cc00_gain goes away and is replaced by tx_gain. For rx_gain
        there is a question as I could not find offhand how to control aplifier on RX
        circuit there.
      - For Sunwave tx_gain/rx_gain, as with lots of more(*) is TODO.
      a6772923
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Interlink RU/CELLs by publishing info who uses who · 4eb6a873
      Kirill Smelkov authored
      For example by publishing on RU the list of CELLs that are using it.
      
      While at it and as we are introducing per-RU publication, fix a long-standing
      TODO in ru/lopcomm to publish RU-specific information in per-RU way instead of
      global.
      4eb6a873
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Publish information about a cell on the cell shared instance · e35d1d40
      Kirill Smelkov authored
      Instead of publishing it on enb with prefixing by cell reference. It is more
      logical to have cell input parameters on the cell instance and also have output
      parameters about that cell published on that same instance.
      
      For now it is all only what was input. But in the next patches we'll extend set
      of published information with also computed things, so it won't remain trivial.
      e35d1d40
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Allow SDR RU to consist of multiple SDR boards · 97ecce86
      Kirill Smelkov authored
      For example if we need to do 4T4R but have SDR boards with only 2T2R ports, we
      need to combine two such boards into single RF port. Allow to do that via
      changing SDR schema from taking sdr_dev into accepting sdr_dev_list and
      adjusting the code everywhere correspondingly.
      
      For ORS full backward compatibility is preserved via adjusting "ORS mode" proxy
      correspondingly.
      
      One example in slapos-render-config.py is changed from 2T2R to be 4T2R on such
      RF port combined from two SDR boards. For that example the diff for rendered
      enb.cfg is as follows:
      
          --- a/config/old/enb/iRU1_SDR_tLTE2_tNR/enb.cfg
          +++ b/config/out/enb/iRU1_SDR_tLTE2_tNR/enb.cfg
          @@ -8,7 +8,7 @@
             rf_driver: {
                 // __CELL__a__ru 4T2R  (sdr)
                 name: "sdr",
          -      args: "dev0=/dev/sdr0",
          +      args: "dev0=/dev/sdr0,dev1=/dev/sdr1",
             },
             tx_gain: [51, 51, 51, 51],
             rx_gain: [52, 52],
      
      All other cases, including ORS, remain without any change.
      97ecce86
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Protect from buildout code injection · c83fa3cb
      Kirill Smelkov authored
      We currently have at least the following problem:
      
      1. a malfored shared instance reference leads to instantiation failure and
         potential buildout code injection. For example if reference of shared
         instance contains space then buildout fails with something like
      
             zc.buildout.configparser.ParsingError: File contains parsing errors: .../instance-enb.cfg
                 [line 45]: '[promise-testing partition 0.RU-sdr-busy]\n'
      
         since, when requesting, it is possible to use arbitrary characters for
         references, including newline, it also opens the door for code injection attacks.
      
      2. we currently use `json` directive of slapos.recipe.template e.g. as
      
           extra-context =
               json iru_dict   {{ rulib.iru_dict   | tojson }}
      
         this also potentially leads to instantiation failure if JSON(rulib.iru_dict)
         contains buildout control characters.
      
      Solve this problems.
      
      For 1 we develop "buildout encoding" that encodes arbitrary string into form
      that is safe to be used as a name of buildout section. This encoding never fails
      and does not loose information, which means it is safe to be applied
      unconditionanly and there is no chance for two string inputs to result in the
      same encoded form. The encoding also has practical property that it leaves most
      of the strings, that we use in our buildot profiles, intact. Which means that
      the result of the encoding is readable and the encoding can be applied almost
      unconditionally to all strings without hurting instantiation. Then this
      encoding is applied wherever reference of a shared instance is used to form
      e.g. name of buildout section or inside other codes. We apply this encoding
      universally - in config files too to avoid breakage there - e.g. in enb.cfg to
      protect from e.g. \n being inserted in the middle of comment resulting in YAML
      breakage. See documentation of added xbuildout.py for details.
      
      For 2 we switch from `json` to using `dumps` on an object and referring that
      dumps result via `key` directive.
      
      See the following links for preliminary discussions with Jérome and Vincent on
      this topic:
      
      kirr/slapos@d5d4f7c8
      bf6b2ef3
      c83fa3cb
    • Kirill Smelkov's avatar
      software/ors-amarisoft: ru: amarisoft-stats.jinja2.py: Don't hardcode... · 34126027
      Kirill Smelkov authored
      software/ors-amarisoft: ru: amarisoft-stats.jinja2.py: Don't hardcode n_antenna_ul=2 on testing=True
      
      This usually matches ORS expectations, but for testing generic enb it is
      inappropriate and work work good, because in those tests there are more uplink
      channels.
      
      -> Fix the code to detect how many uplink channels are there automatically.
      34126027
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Switch configuration of RU, cell, peer... · 80017f8c
      Kirill Smelkov authored
      software/ors-amarisoft: enb/generic: Switch configuration of RU, cell, peer and peercell to shared instances
      
      Previously we had cell_list, ncell_list and peers parameters and we now remove
      them and rework the software release to accept configuration for said objects
      via shared instances. In other words now it is possible to add Radio Units,
      cells, peers and peer cells on on top of main eNB service.
      
      Schema for parameters of those shared instances is based on what we just recently
      generalized and established in ru/ cell/ peer/ and peer/cell/ input schemas. We
      only add cell_kind=enb|enb_peer addition field to be able to distinguish a cell
      from peercell object, and we add a way for cell to reference RU one way or another.
      
      RU-CELL relation is no longer 1-1: one RU can be generally serving multiple
      cells. For example transmission bandwidth of SDR100 board is ~ 100MHz while
      bandwidth of one LTE cell is max 20MHz. This way it is possible to put several
      cells whose frequencies are nearby each other to be run on the same SDR
      board(*). And in general one Radio Unit can be serving transmission/reception in
      multiple frequency ranges, thus providing ability for multiple cells to be
      served by RU. This way RU is split off from CELL object and each CELL needs to
      say which RU object it wants to use.
      
      There are 3 ways to configure CELL->RU links:
      
      1. CELL references a RU object. This is the most general.
      2. CELL embeds definition of RU object. This variant is provided for simplicity
         of management for users that do not want to split CELL/RU relations.
      3. CELL2 references another cell object and says to use the same RU as CELL1.
         Again, this variant is provided for simplicity of management when users want to
         add a cell on top of same RU when they already started with "2".
      
      Full backward compatibility is provided for ORS. For this instance-ors-enb.jinja2.cfg
      is adjusted to inject synthetic RU/CELL/PEER/PEERCELL shared instances instead
      of translating to slapparameter_dict. As the result for ORS users it works
      without visible change as parameters with original ORS schema are handled as expected.
      
      Rendered files for ORS also stay practically the same as before this patch.
      
      The main change is in slaplte.jinja2 - in the loading routines. The other
      changes are mostly straightforward adaptation because details of how ru_dict,
      cell_dict, peer_dict and peercell_dict are loaded were already localized to
      slaplte and the rest of the code independent from that.
      
      Now, once we switched to shared instances, we will be finally able to add tests
      for updated enb. Please see a soon follow-up patch for that.
      
      And for existing test_ors.py we also temporary workaround breakage of tests,
      because currently generic code does not handle well special characters in
      partition references. For example it currently breaks on spaces with buildout
      complaining that sections with spaces in their name are invalid. We will fix
      that in another soon-followup patch as well, but apply a workaround for now.
      
      (*) see https://tech-academy.amarisoft.com/SDR_MultiCell_OneSdr.html for details.
      
      --------
      
      Appendix. Diff for rendered ORS enb.cfg and gnb.cfg before and after this patch:
      
      ```
      $ ./pythonwitheggs slapos-render-config.py && xdiff config/{old,out}
      ```
      
      ```diff
      diff --git a/config/old/ors/enb/enb.cfg b/config/out/ors/enb/enb.cfg
      index 15f3b68e9..6046d366e 100644
      --- a/config/old/ors/enb/enb.cfg
      +++ b/config/out/ors/enb/enb.cfg
      @@ -6,7 +6,7 @@
      
         // Radio Units
         rf_driver: {
      -      // CELL-RU 2T2R  (sdr)
      +      // RU 2T2R  (sdr)
             name: "sdr",
             args: "dev0=/dev/sdr0",
             rx_antenna:"tx_rx",
      @@ -28,7 +28,7 @@
         // LTE cells
         cell_list: [
      
      -    // CELL  (CELL-RU)
      +    // CELL  (RU)
           {
             rf_port:      0,
             n_antenna_dl: 2,
      @@ -46,7 +46,7 @@
               // Inter-ENB HO
               {
                 rat:          "eutra",
      -          cell_id:      0x12345,  // -> 1
      +          cell_id:      0x12345,  // -> PEERCELL1
                 n_id_cell:    35,
                 dl_earfcn:    700,
                 tac:          123,
      diff --git a/config/old/ors/gnb/enb.cfg b/config/out/ors/gnb/enb.cfg
      index ac564db6c..9473f3207 100644
      --- a/config/old/ors/gnb/enb.cfg
      +++ b/config/out/ors/gnb/enb.cfg
      @@ -6,7 +6,7 @@
      
         // Radio Units
         rf_driver: {
      -      // CELL-RU 2T2R  (sdr)
      +      // RU 2T2R  (sdr)
             name: "sdr",
             args: "dev0=/dev/sdr0",
             rx_antenna:"tx_rx",
      @@ -35,7 +35,7 @@
         // NR cells
         nr_cell_list: [
      
      -      // CELL  (CELL-RU)
      +      // CELL  (RU)
             {
               rf_port:      0,
               n_antenna_dl: 2,
      @@ -58,7 +58,7 @@
               // Inter-ENB HO
               {
                 rat:          "nr",
      -          nr_cell_id:   0x77712, // -> 1
      +          nr_cell_id:   0x77712, // -> PEERCELL2
                 gnb_id_bits:  22,
                 n_id_cell:    75,
                 dl_nr_arfcn:  520000,
      ```
      80017f8c
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Start to generalize the code to handle multiple cells · d015c20c
      Kirill Smelkov authored
      As with Radio Units organize a registry of cells and start to handle that
      registry generally everywhere. Make parameters that configure cells, for
      example tdd_ul_dl_config, dl_earfcn, bandwidth, pci, etc to be per-cell.
      
      Cell registry is still populated from cell_list and slapparameter_dict.
      
      Tests will be added later as full tests for generic MultiRU.
      
      Rendered enb.cfg and gnb.cfg stay practically the same.
      
      Backward compatibility: no change for ORS; For everything else cell parameters
      stop to be global and are moved to cell_list.
      
      --------
      
      Appendix. Diff for rendered enb.cfg and gnb.cfg before and after this patch:
      
      ```
      $ ./pythonwitheggs slapos-render-config.py && xdiff -w config/{old,out}
      ```
      
      ```diff
      diff --git a/config/old/enb.cfg b/config/out/enb.cfg
      index 5c6743c21..1b39f7044 100644
      --- a/config/old/enb.cfg
      +++ b/config/out/enb.cfg
      @@ -1,6 +1,3 @@
      -
      -
      -
       {
         log_options: "all.level=error,all.max_size=0,nas.level=debug,nas.max_size=1,s1ap.level=debug,s1ap.max_size=1,x2ap.level=debug,x2ap.max_size=1,rrc.level=debug,rrc.max_size=1,ngap.level=debug,ngap.max_size=1,xnap.level=debug,xnap.max_size=1,phy.level=info,file.rotate=1G,file.path=/dev/null",
         log_filename: "log/enb.log",
      @@ -93,11 +90,11 @@
             srs_hopping_bandwidth: 0,
           },
      
      -    drb_config: "drb",
      +    drb_config: "default-drb.cfg",
      
           sib_sched_list: [
             {
      -        filename: "sib",
      +        filename: "default-sib23.asn",
               si_periodicity: 16,
             },
           ],
      diff --git a/config/old/gnb.cfg b/config/out/gnb.cfg
      index 6b04559c6..1fa637925 100644
      --- a/config/old/gnb.cfg
      +++ b/config/out/gnb.cfg
      @@ -1,6 +1,3 @@
      -
      -
      -
       {
         log_options: "all.level=error,all.max_size=0,nas.level=debug,nas.max_size=1,s1ap.level=debug,s1ap.max_size=1,x2ap.level=debug,x2ap.max_size=1,rrc.level=debug,rrc.max_size=1,ngap.level=debug,ngap.max_size=1,xnap.level=debug,xnap.max_size=1,phy.level=info,file.rotate=1G,file.path=/dev/null",
         log_filename: "log/enb.log",
      @@ -77,7 +74,6 @@
           manual_ref_signal_power: true,
           ss_pbch_block_power: 8,
      
      -
           tdd_ul_dl_config: {
             pattern1: {
                period: 5, /* in ms */
      @@ -148,7 +144,7 @@
             ],
           },
      
      -    drb_config: "drb",
      +    drb_config: "default-drb.cfg",
         },
         ],
         nr_cell_default: {
      ```
      d015c20c
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Start to generalize the code to handle multiple Radio Units · 0a285a34
      Kirill Smelkov authored
      Add code to organize a registry of Radio Units and handle that registry generally everywhere.
      
      RU registry is still populated from cell_list and in practice there still can
      be radio units only of the same type, but besides slaplte.load_ru_and_cell
      which is aware of that, the rest of the code tries to do everything as if
      RUs of different type could be present simultaneously.
      
      Now it is not only lopcomm who can do multiCELL, but also sunwave and SDR as well.
      
      gNB also starts to gain support for cell_list, because cell_list loading is
      uniformly applied to both eNB and gNB. However, since enb.cfg is not yet
      prepared to handle multiple NR cells yet, there is an assert that in case of NR
      there is only one RU/cell present there. We will remove this limitation in a
      follow-up patch.
      
      Later we will also change the loading to load RU descriptions from shared instances
      and they won't be constrained to be Radio Units of the same type. But we need
      to prepare a lot to be able to do that.
      
      One more step forward towards MultiRU.
      
      Tests will be added later as full tests for generic MultiRU.
      
      Backward compatibility: no change for ORS and practically no breaking change for everything else.
      
      --------
      
      Appendix. Diff for rendered enb.cfg and gnb.cfg before and after this patch:
      
      ```
      $ ./pythonwitheggs slapos-render-config.py && git diff -w --no-index config/{old,out}
      ```
      
      ```diff
      diff --git a/config/old/enb.cfg b/config/out/enb.cfg
      index 884483b0a..cafdf42be 100644
      --- a/config/old/enb.cfg
      +++ b/config/out/enb.cfg
      @@ -1,24 +1,22 @@
      
      -
       {
         log_options: "all.level=error,all.max_size=0,nas.level=debug,nas.max_size=1,s1ap.level=debug,s1ap.max_size=1,x2ap.level=debug,x2ap.max_size=1,rrc.level=debug,rrc.max_size=1,ngap.level=debug,ngap.max_size=1,xnap.level=debug,xnap.max_size=1,phy.level=info,file.rotate=1G,file.path=/dev/null",
         log_filename: "log/enb.log",
      
      -
      +  // Radio Units
         rf_driver: {
      +      // default-RU 2T2R  (ors)
             name: "sdr",
             args: "dev0=/dev/sdr0",
      -
             rx_antenna:"tx_rx",
             tdd_tx_mod: 1,
         },
      -  tx_gain: 62,
      -  rx_gain: 43,
      -
      +  tx_gain: [62, 62],
      +  rx_gain: [43, 43],
         com_addr: "127.0.1.2:9001",
         // LTE core network
         mme_list: [
      @@ -36,6 +34,8 @@
      
         // LTE cells
         cell_list: [
      +
      +    // default  (default-RU)
           {
             rf_port:      0,
             n_antenna_dl: 2,
      diff --git a/config/old/gnb.cfg b/config/out/gnb.cfg
      index fd57ca3dc..7818b4ea8 100644
      --- a/config/old/gnb.cfg
      +++ b/config/out/gnb.cfg
      @@ -1,24 +1,22 @@
      
      -
       {
         log_options: "all.level=error,all.max_size=0,nas.level=debug,nas.max_size=1,s1ap.level=debug,s1ap.max_size=1,x2ap.level=debug,x2ap.max_size=1,rrc.level=debug,rrc.max_size=1,ngap.level=debug,ngap.max_size=1,xnap.level=debug,xnap.max_size=1,phy.level=info,file.rotate=1G,file.path=/dev/null",
         log_filename: "log/enb.log",
      
      -
      +  // Radio Units
         rf_driver: {
      +      // default-RU 2T2R  (ors)
             name: "sdr",
             args: "dev0=/dev/sdr0",
      -
             rx_antenna:"tx_rx",
             tdd_tx_mod: 1,
         },
      -  tx_gain: 62,
      -  rx_gain: 43,
      -
      +  tx_gain: [62, 62],
      +  rx_gain: [43, 43],
         com_addr: "127.0.1.2:9001",
         // NR core network
         amf_list: [
      ```
      0a285a34
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb+ue: Query slapparameter_dict from master only once · 2149bc2d
      Kirill Smelkov authored
      We are currently querying it in instance.cfg and later, once again, in e.g. instance-enb.jinja2.cfg .
      
      However ORS mode will need to adjust slapparameter_dict with ORS defaults
      and pass it further to generic enb. So it won't work if we use
      slapparameter_dict obtained the second time because the second query will
      return unadjusted original slapparameter_dict.
      
      In this patch we are only doing preparatory step - redo the code not query the
      master from instance-{enb,ue}.jinja2.cfg and work with slapparameter_dict and
      slap_configuration already queried by instance.cfg
      
      For UE the change is trivial.
      
      For eNB instance-enb.jinja2.cfg used to set the defaults for com, mme, amf and
      gtp in the same section used for the second query. We rework those defaults to
      be applied to slapparameter_dict via jinja2 - via the same way we are going to
      later use in ORS mode.
      
      Handling defaults for everything besides gtp_addr is straightforward. For
      gtp_addr it has the semantic difference when explicitly given, and given only
      implicitly. In the latter case the intent of original code is to autodetect
      whether to use an address on loopback, or externally-visible address.
      
      Original code used the check for emptiness of mme_list/amf_list as the
      condition for "use loopback". Since now those lists, after applying their
      defaults, are never empty we rework the code to see if core address is on the
      loopback or not, and use auto-GTP-on-loopback only if core is also on loopback.
      This should, hopefully, be more convenient as it also works ok out of the box
      if core is on loopback, but its address was explicitly specified. Previously
      for such cases gtp_addr was also needed to be specified, and now it should work
      without that.
      
      No change to rendered enb.cfg and gnb.cfg besides whitespace.
      
      Adjust ipv6-random usage in core-network for consistency with enb as well.
      2149bc2d
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: dnsmasq-service :port and :ip are unused and misleading · 86e9a774
      Kirill Smelkov authored
      For example it is the port that is setup in ru/dnsmasq.jinja2.cfg that is used,
      not :port and there it is 5354, i.e. different. :ip is also not used anywhere.
      
      -> Remove them to avoid confusion.
      86e9a774
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Rename cell_list -> cell_dict internally · 0f8ee720
      Kirill Smelkov authored
      That data structure is really a dict, not list. It is more clear to name it appropriately.
      
      -> Do the renaming but keep cell_list intact as described in JSON schemas so
         that external interface remains unchanged.
      
      Rendered enb.cfg and gnb.cfg remain the same.
      0f8ee720
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb+ue: Make ru_type and do_lte/do_nr to be accessible at instance level · fbb0d0c1
      Kirill Smelkov authored
      Not only inside rendered enb.jinja2.cfg and ue.jinja2.cfg because we will need
      that information in slaplte and slaplte is imported by instance-enb and
      instance-ue.
      fbb0d0c1
  6. 23 Jan, 2024 2 commits
  7. 19 Jan, 2024 2 commits
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Push amarisoft-stats.jinja2.py and amarisoft-rf-info.jinja2.py into ru/ · 7502f5a1
      Kirill Smelkov authored
      Because
      
      1) those services are needed and used only by ru/ promises like check_cpri_lock
         and check_rx_saturated.
      2) in general we will need to initialize and setup radio units not only in eNB -
         for example UEsim will use the same code library to initialize radio units.
         Thus the proper place to keep everything required for RU to be operational have to
         be located inside ru/ and activated by that radio-units library.
      
      Push corresponding code from instance-enb to ru/ and do only minor adjustments
      to instance-gnb trying not to break it, since gnb does not currently use rulib,
      and because in the future gnb will be replaced by enb which will be serving
      both lte and nr cells in the same service.
      
      /cc @lu.xu, @tomo, @xavier_thompson, @Daetalus
      /reviewed-by @jhuge
      /reviewed-on !1511
      7502f5a1
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Push SSH server code into ru/lopcomm/ · d29ece87
      Kirill Smelkov authored
      Because:
      
      - ssh server is needed for and used by ru/lopcomm/ only
      - in general we will need to initialize and setup radio units not only in eNB -
        for example UEsim will use the same code library to initialize radio units.
        Thus the proper place to keep everything required for RU to be operational have to
        be located inside ru/ and activated by that radio-units library.
      
      /cc @lu.xu, @tomo, @xavier_thompson, @Daetalus
      /reviewed-by @jhuge
      /reviewed-on nexedi/slapos!1510
      d29ece87
  8. 29 Nov, 2023 4 commits
  9. 28 Nov, 2023 2 commits
  10. 21 Nov, 2023 1 commit
  11. 17 Nov, 2023 2 commits
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Adjust DHCP server to provide dedicated IPv6 to each Radio Unit · cbc3929c
      Kirill Smelkov authored
      By reusing recently added "split TAP" infrastructure we can adjust dnsmasq
      configuration to provide unique IPv6 to each RU.
      
      - ru_mac_addr becomes per-RU setting and without default. We talked with Lu, and
        since now all Lopcomm units are shipped from the factory with unique MAC, it
        both does not make sense to provide the default, and we can rely on all units
        to have different MACs and configure DHCP replies based on that.
      
      - No need to provide /64 network to every RU. We cannot actually do that anyway
        because normally SlapOS provides /71 address range for its slaptap. In the
        new configuration everything works with smaller networks just ok.
      
      /cc @jhuge, @xavier_thompson, @Daetalus
      /reviewed-by @lu.xu
      /reviewed-on nexedi/slapos!1472
      cbc3929c
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Provide dedicated TAP interface for each Radio Unit · 49ce8ef5
      Kirill Smelkov authored
      SlapOS provides to each partition dedicated TAP interface, so that an instance
      could organize internal networking. In practice this is used by KVM software
      release and here in ors-amarisoft, where we feed to eNB such TAP interface for
      CPRI-based radio unit so that eNB, in turn, could provide access to CPRI
      Control and Management channel via provided TAP.
      
      However there is a problem: SlapOS provides only one TAP interface per
      instance, while we need to have one TAP for each Radio Unit.
      
      -> Solve this problem by creating TAP "subinterfaces" per each RU ourselves.
      
      The interfaces we create are full TAP interfaces, just we name them with prefix
      based on main interface, and we allocate only part of address space of sole
      SlapOS TAP to each subtap. For example if SlapOS provided us slaptap16 with
      2401:5180:0:66:a200::/71 IPv6 range and we want to split it for 2 radio units,
      we'll be splitting it into 3 regions as follows:
      
          slaptap16: split 2401:5180:0:66:a200::/71 by 2
          preserve         2401:5180:0:66:a200::/73
          -> slaptap16-1   2401:5180:0:66:a280::/73
          -> slaptap16-2   2401:5180:0:66:a300::/73
      
      Here we preserve 2401:5180:0:66:a200::/73 for usage on original slaptap16, and
      we create slaptap16-1 and slaptap16-2 with correspondingly allocated address
      range subparts for the RUs.
      
      The splitting is done easily but depends on having networking administration
      capability to be able to work. We solve this with employing
      /opt/amarisoft/setcap, which we already use for dnsmasq, and with compiled
      trampoline program because setcap does not really work directly on scripts.
      
      To avoid hard dependency on having network capability rights, we fallback to
      using regular SlapOS slaptap in case there is only one RU.
      
      ru/lopcomm/* and enb.cfg are adapted straightforwardly, but dnsmasq adaptation
      is left to a later step not to mix everything into one pile.
      
      NOTE that relying on setcap is not a good in the long term and should be
           reworked once SlapOS is improved to provide ability for instances to
           request several TAP interfaces. Please see discussion at
           nexedi/slapos!1471 (comment 194356)
           for details.
      
      /cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus
      /reviewed-on nexedi/slapos!1471
      49ce8ef5
  12. 16 Nov, 2023 1 commit
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Start to generalize existing lopcomm/multicell into multiRU slowly · b0c37a4a
      Kirill Smelkov authored
      Lopcomm part of the SR already has some partial support for cell_list: if
      multiple cells are defined there enb.cfg will have multiple CPRI radio units
      and multiple cells configured. But so far all promises, except cpri-link, were
      done only for one RU.
      
      -> Fix that by starting to generalize RUlib code to handle multiple radio
      units, invoking model-specific RU driver for each RU, and adjusting ru/lopcomm
      instance code to correctly generate and activate different promises for
      different radio units.
      
      After the patch multiRU support is still very incomplete, but it is a step forward.
      
      /cc @xavier_thompson, @Daetalus
      /reviewed-by @lu.xu
      /partly-reviewed-by @jhuge
      /reviewed-at nexedi/slapos!1467
      b0c37a4a
  13. 06 Nov, 2023 1 commit
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Start to organize Radio Unit related bits under ru/ · 4097a1bb
      Kirill Smelkov authored
      Bring more structure to RU-specific code as a preparatory step for multiRU support:
      
      - move RU-specific files under ru/<RU-type>/ . This mostly moves Lopcomm programs and configuration files there.
      - move RU-specific instance code there as well. This also mostly moves Lopcomm specific services and promises there.
      - bring more structure in naming. As buildout has global namespace use ru_<RU-type>_ prefix to avoid collision in names.
      
      This should be a preparatory patch with practically no semantic change, but
      preparing ground for further multiRU landing.
      
      /cc @xavier_thompson, @Daetalus
      /reviewed-by @jhuge, @lu.xu
      /reviewed-on nexedi/slapos!1466
      4097a1bb