1. 21 Feb, 2024 1 commit
  2. 20 Feb, 2024 1 commit
  3. 19 Feb, 2024 1 commit
  4. 18 Feb, 2024 2 commits
    • Kirill Smelkov's avatar
      software/ors-amarisoft: MultiRU · ed138c6e
      Kirill Smelkov authored
      Hello up there. This merge-request brings in major update to ors-amarisoft
      software release: first eNB is significantly restructured to prepare base for
      further changes, and then we add support for working with multiple radio units
      and multiple cells with all LTE/NR and FDD/TDD simultaneously. All kinds of
      Carrier Aggregation - LTE+LTE, NR+NR and LTE+NR are now supported. All kinds of
      Handover - Intra-ENB, Inter-ENB with LTE→NR and NR→LTE are now supported as
      well. UE simulator is also updated to support multiple radio units, cells and
      UEs. In the new system configuration of RU, CELL, PEERCELL, PEER and UE objects
      are done via shared instances attached to the main eNB or UEsim instance.
      
      Most of the parameters become runtime settings instead of being static choice
      of particular software template. There is no longer multiple rendered
      softwares - all that remain is
      
      1. `software.cfg` for generic software, and
      2. `software-ors.cfg` for ORS.
      
      Switching to configuring things at runtime became possible because SlapOS Master
      recently switched to new JSON-editor with support for `oneOf`, arrays and
      conditionals - bits that make it possible to configure settings in the WEB UI
      with multiple choices for e.g. RF mode, cell or radio unit type.
      
      For ORS full backward compatibility is preserved via special proxy which
      translates ORS input schema to configuration objects of the new generic eNB.
      Since most our current ORS deployments are TDD, `software-tdd-ors.cfg` link to
      `software-ors.cfg` is also provided to preserve backward compatibility at
      software-release URL level for those instances.
      
      eNB and gNB are merged along the way. Unittests are improved. JSON schemas
      become primary source for defaults(*). Unnecessary parameters are removed and
      are now computed automatically. For example it is no longer needed to
      explicitly specify SSB NR-ARFCN for peer NR cell, or `txa0cc00_center_frequency`
      for Lopcomm RU. `tx_gain` and `rx_gain` become generic parameters that
      semantically apply uniformly to all Radio Units.
      
      A protection against buildout code injection via specially-crafted references
      of shared instances is installed. The problem was noticed because instantiation
      was failing with spaces in the references - a condition that is present by
      default on the testnodes. Solving the problem generally via custom "buildout
      encoding" was not hard and probably the solution might be useful not only for
      ors-amarisoft software release. Please see the patch `"Protect from buildout
      code injection"` for details.
      
      There are more minor enhancements and bug fixes in there.
      
      Please see individual patches for details.
      
      Kirill
      
      /cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus
      /approved-by @tomo
      /reviewed-on nexedi/slapos!1533
      
      (*) this goes in line with similar design choice to make JSON schemas primary
          source of defaults in Rapid-CDN: nexedi/slapos!1380 .
      ed138c6e
    • Kirill Smelkov's avatar
      software/ors-amarisoft: Do not recreate slaptapX-* on every idempotent `slapos node instance` run · 7989e6ce
      Kirill Smelkov authored
      To run tapsplit we use plone.recipe.command with both command and
      update-command set to `tapsplit ...`. But tapsplit, when run, currently fully
      recreates and reinitializes subtap interfaces, which leads to interfering with
      running enb because subtap interfaces, that enb started to use, are removed.
      This is not desirable behaviour.
      
      What we need:
      
      1) create subtap interfaces only once and keep them stable
      2) until configuration changes which should lead to
         * subtaps recreated, and
         * enb restarted
      3) if subtap interfaces disappear for any reason, recreate it
      
      -> Rework tapsplit to keep its promise, that it "brings tap interface into state
         with several children interfaces each covering part of original interface
         address space", without recreating those children on every run and instead
         doing any action only if their state is not what is desired.
      
      In other words those interfaces now are only created when they do not exist
      before. Addresses and routes are added only if they are not there before
      tapsplit is run, etc.
      
      After the patch the first run of tapsplit to split by 2 looks like
      
          # ./pythonwitheggs ru/tapsplit slaptap16 2
          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
           # ip tuntap add dev slaptap16-1 mode tap user slapuser16
           # ip link set slaptap16-1 up
           # ip addr add 2401:5180:0:66:a280::/73 dev slaptap16-1 noprefixroute
           # ip route add 2401:5180:0:66:a280::1 dev slaptap16-1
           # ip route add 2401:5180:0:66:a280::/73 dev slaptap16-1 via 2401:5180:0:66:a280::1
          -> slaptap16-2   2401:5180:0:66:a300::/73
           # ip tuntap add dev slaptap16-2 mode tap user slapuser16
           # ip link set slaptap16-2 up
           # ip addr add 2401:5180:0:66:a300::/73 dev slaptap16-2 noprefixroute
           # ip route add 2401:5180:0:66:a300::1 dev slaptap16-2
           # ip route add 2401:5180:0:66:a300::/73 dev slaptap16-2 via 2401:5180:0:66:a300::1
      
      The second run with the same arguments looks as
      
          # ./pythonwitheggs ru/tapsplit slaptap16 2
          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-1: already exists
           # slaptap16-1: already up
           # slaptap16-1: already has 2401:5180:0:66:a280::/73 addr
           # slaptap16-1: already has 2401:5180:0:66:a280::1 route
           # slaptap16-1: already has 2401:5180:0:66:a280::/73 route
          -> slaptap16-2   2401:5180:0:66:a300::/73
           # slaptap16-2: already exists
           # slaptap16-2: already up
           # slaptap16-2: already has 2401:5180:0:66:a300::/73 addr
           # slaptap16-2: already has 2401:5180:0:66:a300::1 route
           # slaptap16-2: already has 2401:5180:0:66:a300::/73 route
      
      where it could be seen that no actions had been taken.
      
      And if, for example, the user manipulates slaptap16-2 and manually sets it
      down, the third run restores it to desired 'UP' state and readds the address
      and routes because the kernel removed them when link went down:
      
          # ip -6 addr show dev slaptap16-2
          157: slaptap16-2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
              inet6 2401:5180:0:66:a300::/73 scope global tentative noprefixroute
                 valid_lft forever preferred_lft forever
          # ip -6 route show dev slaptap16-2
          2401:5180:0:66:a300::1 metric 1024 linkdown pref medium
          2401:5180:0:66:a300::/73 via 2401:5180:0:66:a300::1 metric 1024 linkdown pref medium
          # ip link set slaptap16-2 down
          # ip -6 addr show dev slaptap16-2
          # ip -6 route show dev slaptap16-2
          # ./pythonwitheggs ru/tapsplit slaptap16 2
          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-1: already exists
           # slaptap16-1: already up
           # slaptap16-1: already has 2401:5180:0:66:a280::/73 addr
           # slaptap16-1: already has 2401:5180:0:66:a280::1 route
           # slaptap16-1: already has 2401:5180:0:66:a280::/73 route
          -> slaptap16-2   2401:5180:0:66:a300::/73
           # slaptap16-2: already exists
           # ip link set slaptap16-2 up
           # ip addr add 2401:5180:0:66:a300::/73 dev slaptap16-2 noprefixroute
           # ip route add 2401:5180:0:66:a300::1 dev slaptap16-2
           # ip route add 2401:5180:0:66:a300::/73 dev slaptap16-2 via 2401:5180:0:66:a300::1
      
      The first version of this patch tried to solve the problem by setting
      update-command to be noop instead of reworking tapsplit itself. But as Thomas
      noted this does not satisfy requirement "3".
      
      Amends 49ce8ef5 (software/ors-amarisoft: Provide dedicated TAP interface for each Radio Unit)
      
      /helped-by @tomo
      /cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus
      /reviewed-on nexedi/slapos!1508
      7989e6ce
  5. 16 Feb, 2024 11 commits
    • Jérome Perrin's avatar
      ERP5: Move frontend virtualhost logic on backend · 7ff43824
      Jérome Perrin authored
       - use caucase for balancer certificate
       - move virtual host logic on the backend
       - change "frontend" parameter to request "" type (and no longer "zope")
      
      See merge request nexedi/slapos!1504
      7ff43824
    • Jérome Perrin's avatar
      stack/erp5: implement Zope's rewrite rules in ERP5 balancer partition · 6e735808
      Jérome Perrin authored
      The strategy for compatibility is that:
       - haproxy still listen on the same port as before, without rewrite rule.
         This is called "legacy" port.
       - for each frontend from request parameters, we introduce an haproxy
         frontend with a rewrite for the corresponding `internal-path`
         parameter.
       - the shared frontend instance is updated to use this new frontend
         entry from haproxy. This will cause a small downtime until the shared
         frontend is updated to the new URL on ERP5, but since this feature
         was not used, it's OK.
      
      Technical details are that we:
       - split haproxy config to have frontends and backends.
       - introduce one frontend in haproxy for each frontend from request
         parameters.
       - routing-rule-list argument is still honored the same way, globally
         and after path from frontend.
       - change the shared frontend requests to use "" type, no longer "zope"
         type.
       - we don't do automatic detection of /VirtualHostRoot in URL but always
         add it, because it could be used to trick zope into thinking it
         serves requests for an arbitrary host and do open redirects
       - before using the request's host header in virtualhost path, we check
         that it does not contain /, to prevent injection of virutalhost path
         elements through the host header.
       - we don't use the "path" parameter from shared frontend, because we
         want the frontend to be simple, so we don't want it to rewrite the
         request path (which is also the reason why we deprecated "zope" type)
       - the tests have changed a lot, because they were using what's now the
         "legacy" URL types, so we updated it to use the new URL types with
         all the /VirtualHostRoot/../ in path and also because they use IPv6
         URL, no longer IPv4
      6e735808
    • Jérome Perrin's avatar
      5b3fc1f2
    • Jérome Perrin's avatar
      stack/erp5: use slapos.recipe.build to manage haproxy parameters · 2fc522bf
      Jérome Perrin authored
      and save the already allocated ports in a state file, so that requesting
      new families does not change already allocated ports.
      2fc522bf
    • Jérome Perrin's avatar
      stack/erp5: use caucase managed certificate for balancer · d49914a6
      Jérome Perrin authored
      This reverts commit 620c9332 (stack/erp5: stop using caucase managed
      certificate for balancer, 2020-11-10) with an updated design. We add a
      caucase service for balancer in the balancer partition. The caucase
      service from the root partition (that was not used) is removed.
      
      The underlying idea is that the default configuration should use multiple
      caucases with limited scope, here we have one caucase to manage the
      certificate used by haproxy server in the balancer partition, so we put
      one caucase to manage this certificate and the caucase is configured to
      auto-accept one certificate only. The plan is that when we will add a
      certificate for mariadb server, we'll add another caucase inside this
      mariadb server.
      
      For more advanced usage and also to support the cases where a new
      certificate needs to be re-emitted for some reason, users can request
      with an existing caucase URL. In that case, they will have to accept
      the certificate requests.
      
      Notable changes:
      
      balancer/ssl/caucase-url is no longer documented in parameters, this is
      an internal parameter, users can pass one global caucase service to
      manage all partition
      
      CAUCASE environment variable is no longer set when running zope. There
      was no identified use case and with this new approach of multiple
      caucases, the term "caucase" alone became ambiguous.
      d49914a6
    • Jérome Perrin's avatar
      stack/erp5: remove not used "backend-path" · 16c9df39
      Jérome Perrin authored
      This is not documented in schema and has no effect in erp5 (but this is
      still used for slapos-master)
      16c9df39
    • Jérome Perrin's avatar
    • Jérome Perrin's avatar
      ERP5: rework frontend instance parameter · cb78214e
      Jérome Perrin authored
      This change the format or the (mostly) unused frontend parameter to
      support requesting more than one frontend and also enable the request of
      a frontend by default, so that requesting a frontend separately is no
      longer needed.
      
      The `frontend` parameter now also supports requesting frontends for
      specific paths on the ERP5 backend, the example below requests a
      frontend serving directly a web site, with the necessary rewrite rules:
      
      ```js
      {
        "frontend": {
          "default": {
            "internal-path": "/erp5/web_site_module/renderjs_runner/"
          }
        }
      }
      ```
      
      The example below requests a default frontend to the erp5 root, to
      access the ZMI or erp5_xhtml_style interface and two web sites:
      
      ```js
      {
        "frontend": {
          "default": {},
          "erp5js": {
            "internal-path": "/erp5/web_site_module/renderjs_runner/"
          },
          "crm": {
            "internal-path": "/erp5/web_site_module/erp5_officejs_support_request_ui/"
          }
        }
      }
      ```
      
      The example below has an explicit definition of the zope families using
      `zope-partition-dict` parameter, because there is more than one zope
      family, no frontend is requested by default:
      
      ```js
      {
        "zope-partition-dict": {
          "backoffice": {
            "family": "backoffice"
          },
          "web": {
            "family": "web"
          },
          "activities": {
            "family": "activities"
          }
        }
      }
      ```
      
      Continuing this example, to have frontends for backoffice and web
      families, the frontend request can specify the families, like it is
      demonstrated in the example below. In this example, we don't specify an
      entry for "activities" family, so no frontend will be requested for
      this family.
      
      ```js
      {
        "frontend": {
          "backoffice": {
            "zope-family": "backoffice"
          },
          "web": {
            "zope-family": "web",
            "internal-path": "/erp5/web_site_module/web_site/"
          }
        }
        "zope-partition-dict": {
          "backoffice": {
            "family": "backoffice"
          },
          "web": {
            "family": "web"
          },
          "activities": {
            "family": "activities"
          }
        }
      }
      ```
      cb78214e
    • Jérome Perrin's avatar
      33d36fdb
    • Kirill Smelkov's avatar
      stack/slapos: v↑ slapos.toolbox to 0.142 · 73f44633
      Kirill Smelkov authored
      Going 0.140 -> 0.142 introduces the following changes:
      
          slapos.toolbox@0.140...0.142
      
      Test results: https://erp5js.nexedi.net/#/test_result_module/20240215-D4F3CE96 (all ok)
      73f44633
    • Jérome Perrin's avatar
      software/metabase: version up v0.48.6 · 2a0ddd26
      Jérome Perrin authored
      2a0ddd26
  6. 15 Feb, 2024 1 commit
  7. 14 Feb, 2024 1 commit
  8. 13 Feb, 2024 22 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: enb/ors: Fix ssb_pos_bitmap default in schema · 9979fa63
      Kirill Smelkov authored
      Noticed accidentaly: ssb_pos_bitmap is string, not integer - the default should be of the same type.
      9979fa63
    • 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: Try to support NR/FDD a bit · 4abb4101
      Kirill Smelkov authored
      It should be already generally supported, but many parameters needs in NR case
      are currently hardcoded to their TDD values. I've adjusted only a few of them
      and stopped, becuase there is currently no practical case at hand for me to
      test it. Still I think it makes sense to save this first step.
      
      For ORS, who uses TDD, rendered config stays practically the same:
      
      ```
      $ ./pythonwitheggs slapos-render-config.py && xdiff -C -C config/{old,out}/ors/
      ```
      
      ```diff
      diff --git a/config/old/ors/gnb/enb.cfg b/config/out/ors/gnb/enb.cfg
      index ead7f0160..9a260d73f 100644
      --- a/config/old/ors/gnb/enb.cfg
      +++ b/config/out/ors/gnb/enb.cfg
      @@ -97,6 +97,7 @@
      
               prach: {
      +          ra_response_window: 20,
               },
      
               pdcch: {
      @@ -180,7 +181,6 @@
             preamble_received_target_power: -110,
             preamble_trans_max: 7,
             power_ramping_step: 4,
      -      ra_response_window: 20,
             restricted_set_config: "unrestricted_set",
             ra_contention_resolution_timer: 64,
             ssb_per_prach_occasion: 1,
      ```
      4abb4101
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Intra-ENB handover · 5c300a7d
      Kirill Smelkov authored
      If a base station has multiple cells, it should be possible for UE to be handed
      over from one cell into another, for example when UE crosses border of sectors.
      
      So far we had only Inter-ENB HO and now we are also adding configuration for
      HO in between all own cells.
      
      Add tests for everything.
      
      NOTE: we use allowed_meas_bandwidth, antenna_port_1 in dst=LTE case because
      otherwise, e.g. for NR->LTE HO if they are not present, lteenb complains:
      
          enb.cfg:260: expecting 'allowed_meas_bandwidth' field
          enb.cfg:260: expecting 'antenna_port_1' field
      
      for both Intra-ENB and Inter-ENB handovers.
      
      For Intra-ENB case we can compute those numbers from cell definition. For
      Inter-ENB case, when we don't know target context, we use conservative values.
      5c300a7d
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb: Full Carrier Aggregation · 881b5104
      Kirill Smelkov authored
      We already had CA for LTE+LTE case. Let's also setup it for NR+NR and LTE+NR
      cases as well. Add tests for everything.
      881b5104
    • 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/ors: test: Use valid frequencies · 7a22aaa0
      Kirill Smelkov authored
      So far in the unit tests we were only generating enb.cfg without semantically
      processing as running lteenb is not possible on testnodes due to licensing
      restrictions. That allowed to use arbitrary numbers, even invalid, for
      frequencies without hitting an error.
      
      However in the next patch we are going to start handling frequencies ourselves,
      and invalid frequencies will lead to instantiation failures like
      
          ... in dl2ul(dl_earfcn)
          KeyError: 'no band that corresponds to DL EARFCN=325320'
      
      Avoid that by switching to valid LTE and NR frequency numbers in the test.
      7a22aaa0
    • 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
      nexedi/slapos@bf6b2ef3
      c83fa3cb
    • Kirill Smelkov's avatar
      software/ors-amarisoft: enb/generic: Add basic tests · b168cb33
      Kirill Smelkov authored
      As promised add tests for generic enb that exercise enb instantiation with
      multiple Radio Units and cells in all kind of combinations:
      
         FDD|TDD x LTE|NR x SDR|Lopcomm|Sunwave
      
      and not only one particular case, but verifying instantiation with many
      combinations at the same time - verifying how cells of different kinds are
      handled and how radio units of different kinds are handled too. Using multiple
      cells on top of several radio units of the same type is verified too.
      
      For Lopcomm we also exercise generated cu_config.xml a bit.
      
      See added tests for details.
      
      Enb/generic tests are bootstrapped now.
      
      From now one every fix to enb/generic and every semantic change will go on only
      if it is accompanied test change or enhancement.
      b168cb33
    • 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: slapos-render-config: enb: Also render CELL-drb.cfg and CELL-sib23.asn · f2927790
      Kirill Smelkov authored
      As promised in indicated TODO.
      
      It is useful for debugging and for being able to take all the rendered files,
      copy them to a callbox, and to be able to run lteenb directly on them.
      
      Besides enb.cfg we need to also have those drb and asn23, because enb.cfg
      references them.
      f2927790
    • Kirill Smelkov's avatar
      software/ors-amarisoft: slapos-render-config: enb: Add various examples of configuring RU and CELLs · 525b1036
      Kirill Smelkov authored
      Extend slapos-render-config to simulate not only what ORS does, but also
      simulate multiple radio units and/or multiple cells with RU being SDR or
      CPRI-based Lopcomm. It is useful as an example on how to configure things in
      new "shared instances" MultiRU, and to verify handling of all those combinations.
      525b1036
    • 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: slapos-render-config: Add peers · 69602afe
      Kirill Smelkov authored
      We already have peer cells in the setup of generated enb/gnb, but there were no
      X2/XN peers there. Add them to be able to see how handling of peers works.
      
      Rendered files change as expected:
      
      ```
      $ ./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 252c2e379..15f3b68e9 100644
      --- a/config/old/ors/enb/enb.cfg
      +++ b/config/out/ors/enb/enb.cfg
      @@ -22,7 +22,7 @@
           },
         ],
         gtp_addr: "127.0.1.1",
      -  x2_peers: [],
      +  x2_peers: ["44.1.1.1", "44.1.1.2"],
         enb_id: 0x1A2D0,
      
         // LTE cells
      diff --git a/config/old/ors/gnb/enb.cfg b/config/out/ors/gnb/enb.cfg
      index b401f3513..ac564db6c 100644
      --- a/config/old/ors/gnb/enb.cfg
      +++ b/config/out/ors/gnb/enb.cfg
      @@ -22,7 +22,7 @@
           },
         ],
         gtp_addr: "127.0.1.1",
      -  xn_peers: [],
      +  xn_peers: ["55.1.1.1", "55.1.1.2"],
         gnb_id_bits: 28,
         gnb_id: 0x12345,
         en_dc_support: true,
      ```
      69602afe
    • Kirill Smelkov's avatar
      software/ors-amarisoft: slapos-render-config: Diverge enb.cfg and ue.cfg generation · 1e3e198d
      Kirill Smelkov authored
      The procedures to generate those are currently very similar, and that's why we
      employ a shared `do` function to render them. But enb and ue rendering will
      become different from each other in the next step.
      
      -> Prepare to that by pushing necessary bits of do into do_enb and do_ue insides.
      
      No change in rendered files.
      1e3e198d
    • Kirill Smelkov's avatar
      software/ors-amarisoft: slapos-render-config: Retarget currently generated... · 28ab315b
      Kirill Smelkov authored
      software/ors-amarisoft: slapos-render-config: Retarget currently generated enb.cfg and gnb.cfg to out/ors/
      
      Besides ORS we will soon add other cases to enb.cfg generation. It will be
      handy to clearly see what is what and to keep ORS case to be also alive and distinguished.
      
      Prepare to that by emitting generated enb.cfg and gnb.cfg to out/ors/enb/ and
      out/ors/gnb instead of just out. Name the file itself enb.cfg always to match
      what happens for real in the SR.
      
      There is no change to generated files - it is only renaming:
      
      ```
      $ ./pythonwitheggs slapos-render-config.py && xdiff config/{old,out}
      ```
      
      ```diff
      diff --git a/config/old/enb.cfg b/config/out/ors/enb/enb.cfg
      similarity index 100%
      rename from config/old/enb.cfg
      rename to config/out/ors/enb/enb.cfg
      diff --git a/config/old/gnb.cfg b/config/out/ors/gnb/enb.cfg
      similarity index 100%
      rename from config/old/gnb.cfg
      rename to config/out/ors/gnb/enb.cfg
      ```
      28ab315b