An error occurred fetching the project authors.
  1. 29 Nov, 2023 4 commits
  2. 28 Nov, 2023 3 commits
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Activate for-RU DHCP server automatically · 07f8694b
      Kirill Smelkov authored
      instead of requiring users to explicitly activate it via additional `dnsmasq` parameter.
      
      The reason here is simple: CPRI-based radio units, for example Lopcomm ORAN RU,
      need to be configured to go to radio, and for that configuration to work we
      need to be able to talk via TCP/IP to the RU.
      
      /cc @jhuge, @xavier_thompson, @Daetalus
      /reviewed-by @lu.xu
      /reviewed-on !1479
      07f8694b
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Push code, that organizes DHCP server for Radio Units, into ru/ · 17ea91a8
      Kirill Smelkov authored
      We already pushed dnsmasq part, that serves radio units into enb in 9f2b9db5.
      However we need to push those bits further to ru/ for the following reasons:
      
      - DHCP server is used to provide Radio Units with IP address only.
      - without IP address assigned those RUs cannot be initialized and do not go to radio at all.
      - 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 @jhuge, @xavier_thompson, @Daetalus
      /reviewed-by @lu.xu
      /reviewed-on nexedi/slapos!1479
      17ea91a8
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Enable check-rx-saturated promise for Lopcomm Radio Unit as well · f5a8747d
      Kirill Smelkov authored
      The code had check-rx-saturated under `if not ru == "lopcomm"`, but checking RX
      signal for saturation is implemented on eNB side, not by RU itself, and is
      RU-independent because eNB only receives raw samples from RU and decides on its
      own whether those samples are higher than saturation margin or not.
      
      As an extra proof that checking for RX saturation is meaningful for Lopcomm too here is how samples.rx data can look like in the case of 2 Lopcomm Radio Units:
      
          root@callbox-005:/srv/slapgrid/slappart16/var/log# cat amarisoft-stats.json.log |jq .data.samples.rx
          [
            {
              "rms": -382.3080749511719,
              "max": -382.3080749511719,
              "sat": 0,
              "count": 1221181440,
              "rms_dbm": -382.3080749511719
            },
            {
              "rms": -382.3080749511719,
              "max": -382.3080749511719,
              "sat": 0,
              "count": 1221179392,
              "rms_dbm": -382.3080749511719
            }
          ]
          ...
      
      i.e. all the data, that check-rx-saturated promise works on, is there.
      
      /cc @jhuge, @xavier_thompson, @Daetalus
      /reviewed-by @lu.xu
      /reviewed-on !1478
      f5a8747d
  3. 23 Nov, 2023 3 commits
  4. 21 Nov, 2023 2 commits
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Fix enb.cfg build in standalone mode (cell_list) · 32f9e132
      Kirill Smelkov authored
      In b0c37a4a (software/ors-amarisoft: Start to generalize existing
      lopcomm/multicell into multiRU slowly) I deduplicated cell_list initialization
      and moved it into single place, but overlooked that enb.cfg build became broken
      in standalone mode:
      
          .../software/ors-amarisoft$ ./pythonwitheggs slapos-render-config.py
          Traceback (most recent call last):
            File "/srv/slapgrid/slappart35/srv/project/slapos/software/ors-amarisoft/./pythonwitheggs", line 47, in <module>
              exec(compile(__file__f.read(), __file__, "exec"))
            File "slapos-render-config.py", line 88, in <module>
              do('enb', {"tdd_ul_dl_config": "[Configuration 6] 5ms 5UL 3DL (maximum uplink)"})
            File "slapos-render-config.py", line 86, in do
              j2render(cfg, json_params % locals())
            File "slapos-render-config.py", line 34, in j2render
              f.write(r._render().decode())
            File ".../eggs/slapos.recipe.template-5.1-py3.9.egg/slapos/recipe/template/jinja2_template.py", line 215, in _render
              return template_object.render(**self.context).encode(self.encoding)
            File ".../eggs/Jinja2-2.11.3-py3.9.egg/jinja2/environment.py", line 1090, in render
              self.environment.handle_exception()
            File ".../eggs/Jinja2-2.11.3-py3.9.egg/jinja2/environment.py", line 832, in handle_exception
              reraise(*rewrite_traceback_stack(source=source))
            File ".../eggs/Jinja2-2.11.3-py3.9.egg/jinja2/_compat.py", line 28, in reraise
              raise value.with_traceback(tb)
            File "config/enb.jinja2.cfg", line 1, in top-level template code
              {%- set cell_count = cell_list|length %}
          jinja2.exceptions.UndefinedError: 'cell_list' is undefined
      
      -> Fix it by teaching enb.jinja2.cfg to also load cell list in standalone by itself.
      
      Not touching gnb.jinja2.cfg as currently gnb does not support multicell at all,
      and in the future it will be sole enb.cfg to handle both LTE and NR
      simultaneously.
      
      /cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus
      32f9e132
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Start to put common code to load cells and radio units... · 23581dc2
      Kirill Smelkov authored
      software/ors-amarisoft: Start to put common code to load cells and radio units and handle them into slaplte package
      
      We will soon need to use that shared code not only from radio library under ru/ ,
      but also from enb.jinja2.cfg and to fix slapos-render-config.
      
      /cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus
      23581dc2
  5. 17 Nov, 2023 7 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: enb: Remove DNS options from for-RU DHCP configuration · 30b4cec5
      Kirill Smelkov authored
      Those options are not needed, because we need to only provide IPv6 address to
      RU, and also they are not very meaningful: in the current form we tell RU that
      DNS addresses sit at RU.addr+1 and RU.addr+2, i.e. in the IP range we give to
      RU and also at the addresses where no DNS server is actually running.
      
      It was probably a thinko to add those options initially.
      
      /cc @jhuge, @xavier_thompson, @Daetalus
      /reviewed-by @lu.xu
      /reviewed-on nexedi/slapos!1472
      30b4cec5
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Split dnsmasq.cfg into for-core and for-enb · 9f2b9db5
      Kirill Smelkov authored
      Core Network and ENB use dnsmasq for completely different purposes:
      
      - core network uses it to provide DNS server, while
      - enb uses dnsmasq to provide DHCP server for Radio Units to be able to access
        Control & Management channel on the CPRI link.
      
      -> Even though both those services are handled via same dnsmasq program, it
         makes sense to split dnsmasq config for clarity and as preparation for
         further adjustments of enb part.
      
         We also push config rendering down to -core and -enb instances also for
         clarity, and because in enb case rendering will need to know set of
         configured Radio Units - information that will become loaded only at
         instance-enb.
      
      /cc @jhuge, @xavier_thompson, @Daetalus
      /reviewed-by @lu.xu
      /reviewed-on nexedi/slapos!1472
      9f2b9db5
    • 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
    • Kirill Smelkov's avatar
      software/ors-amarisoft: gnb: Move DRB configuration to standalone file · 695518f2
      Kirill Smelkov authored
      A preparatory step for multiRU for the same reason as for LTE and also to be
      able to support Carrier Aggregation in between NR and LTE cells in the future
      (called Dual Connectivity by 3GPP).
      
      /cc @xavier_thompson, @Daetalus
      /reviewed-by @jhuge, @lu.xu
      /reviewed-on nexedi/slapos!1473
      695518f2
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Don't use #define inside DRB template · accc2c86
      Kirill Smelkov authored
      When there will be multiple cells and so multiple DRB files referenced from enb.cfg,
      eNB will complain with an error that "there are multiple #define" for T_REORDERING.
      
      -> Use jinja2 templating instead to handle FDD/TDD conditions.
      
      /cc @xavier_thompson, @Daetalus
      /reviewed-by @jhuge, @lu.xu
      /reviewed-on nexedi/slapos!1473
      accc2c86
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Move DRB configuration to standalone file · 8c841ce6
      Kirill Smelkov authored
      This is preparatory step for multiRU: when there will be several LTE cells,
      each possibly having different RF mode, we'll need to configure DRB per-cell.
      
      -> Move DRB configuration to separate jinja2 template to prepare to handle that.
      
      This is 99% movement only, without changing the code for DRB profile. We'll
      adjust the DRB profile a bit as another preparatory step in the next patch.
      
      /cc @xavier_thompson, @Daetalus
      /reviewed-by @jhuge, @lu.xu
      /reviewed-on nexedi/slapos!1473
      8c841ce6
  6. 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
  7. 13 Nov, 2023 1 commit
  8. 07 Nov, 2023 1 commit
  9. 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 !1466
      4097a1bb
  10. 02 Nov, 2023 3 commits
  11. 31 Oct, 2023 2 commits
  12. 20 Oct, 2023 3 commits
  13. 16 Oct, 2023 2 commits
  14. 13 Oct, 2023 1 commit
  15. 12 Oct, 2023 1 commit
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Switch *.json.log to emit `data` field via JSON · f32db64f
      Kirill Smelkov authored
      ORS software-release emits many *.json.log files with information about current
      state of eNB and radio units. Those files are used by code in slapos.toolbox to
      implement corresponding promises. The files, it seems, try to match JSON Lines
      format(*) with every line containing a JSON object describing timestamp, log
      level and log payload of corresponding log entry.
      
      So far all is good. One peculiarity, however, is that, contrary to everything
      else, the content of the `data` field in the logs is not emitted via
      JSON-encoding. Initially, starting from 4968d55c (ors-amarisoft: get eNB stats
      and add promises), that `data` payload was being emitted via %s py formatting,
      which is similar to what JSON-encoding would produce, but is not it exactly.
      For example if log payload is {'abc': 123} then %s and JSON would quote `abc`
      differently:
      
          {'abc': 123}  # %s
          {"abc": 123}  # JSON
      
      That would not be a big deal if what %s produces would be still valid JSON
      accepted by JSON-decoder, but unfortunately it is not so: JSONDecodeError is
      raised when {'abc': 123} is tried to be decoded.
      
      The code in slapos.toolbox, so far, is handling this situation by feeding to
      JSON-decoder original input with ' characters replaced by "
      
          json.loads(line.decode().replace("'", '"'))     (+)
      
      which more or less works in basic cases, but breaks when log payload contains '
      character itself. For example for {"a'bc": 123} replacing gives {"a"bc": 123},
      which, being invalid JSON, raises
      
          JSONDecodeError: Expecting ':' delimiter: line 1 column 5 (char 4)
      
      when fed to json.loads() .
      
      I've actually hit this problem for real with amarisoft-rf-info.json.log where
      the data part contains output of `rf_info` looking e.g. as
      
          TX underflows=0 RX overflows=0
          TRX SDR driver 2023-09-07, API v15/18
          PCIe CPRI /dev/sdr0@0:
            Hardware ID: 0x4b12
            DNA: [0x0048248a334a7054]
            Serial: ''
            FPGA revision: 2023-06-23  10:05:24
            FPGA vccint: 0.98 V
            FPGA vccaux: 1.76 V
            FPGA vccbram: 0.98 V
            FPGA temperature: 71.9 °C
            Clock tune: 0.0 ppm
            NUMA: 0
            CPRI_option: '5' (x8) lock=no
            DMA0: TX fifo: 66.67us  Usage=16/32768 (0%)
            DMA0: RX fifo: 66.67us  Usage=16/32768 (0%)
            DMA0 Underflows: 0
            DMA0 Overflows: 0
          PCIe CPRI /dev/sdr0@1:
            Hardware ID: 0x4b12
            DNA: [0x0048248a334a7054]
            Serial: ''
            FPGA revision: 2023-06-23  10:05:24
            FPGA vccint: 0.98 V
            FPGA vccaux: 1.77 V
            FPGA vccbram: 0.98 V
            FPGA temperature: 71.7 °C
            Clock tune: 0.0 ppm
            NUMA: 0
            CPRI_option: '5' (x8) lock=HW+SW rx/tx=46.606us
              Port #0: T14=46.606us
            DMA0: TX fifo: 66.67us  Usage=16/32768 (0%)
            DMA0: RX fifo: 66.67us  Usage=16/32768 (0%)
            DMA0 Underflows: 0
            DMA0 Overflows: 0
      
      which lead to breakage when trying to load that log due to ' symbols.
      
      The fix is simple: change the code, that emits *.json.log to emit data payload
      via json.dumps instead of %s. We can do that without breaking anything because,
      contrary to enb.xlog, those *.json.log are not uploaded to any separate system
      and currently are only used to implement promises without preserving log files
      in any storage for any non-small amount of time. In other words, currently
      those *.json.log are temporary files whose format can be adjusted without
      strongly caring about backward compatibility.
      
      b32b4a8e (software/ors-amarisoft: general improvement for RU (logs/promises/input parameters))
      already changed %s to json.dumps for amarisoft-stats.json.log , but left all other logs at %s.
      
      -> Fix this for everything by replacing %s to json.dumps in all generated logs.
      -> Corresponding slapos.toolbox adjustments are in nexedi/slapos.toolbox!120.
      
      /reviewed-on nexedi/slapos!1447
      /reviewed-by @jhuge, @jerome, @tomo
      /cc @lu.xu, @xavier_thompson, @Daetalus
      
      (*) https://jsonlines.org/
      (+) see e.g. https://lab.nexedi.com/nexedi/slapos.toolbox/blob/453dce5f/slapos/promise/plugin/util.py#L50
      f32db64f
  16. 27 Sep, 2023 1 commit
  17. 22 Sep, 2023 3 commits
  18. 04 Sep, 2023 1 commit