An error occurred fetching the project authors.
- 29 Nov, 2023 4 commits
-
-
Kirill Smelkov authored
Similarly to sdr-busy, if we have several radio units, we want each of them to have its own rx-saturated promise. See nexedi/slapos.toolbox!126 for corresponding part in slapos.toolbox that makes check_rx_saturated per-RU configurable. 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 @xavier_thompson, @Daetalus /reviewed-by @jhuge, @lu.xu /reviewed-on nexedi/slapos!1485
-
Kirill Smelkov authored
If we have several radio units, we want each of them to have its own sdr-busy promise. See nexedi/slapos.toolbox!125 for corresponding part in slapos.toolbox that makes check_sdr_busy per-RU configurable. 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 @xavier_thompson, @Daetalus /reviewed-by @jhuge, @lu.xu /reviewed-on nexedi/slapos!1485
-
Kirill Smelkov authored
This promise applies to any CPRI-based Radio Unit not only to Lopcomm RU. -> Move its code to generic part, so that the promise is generated for any CPRI-based RU. /cc @xavier_thompson, @Daetalus /reviewed-by @jhuge, @lu.xu /reviewed-on nexedi/slapos!1485
-
Kirill Smelkov authored
Because for-RU DHCP-server should be provided to all CPRI-based radio unit, not only to Lopcomm. /cc @xavier_thompson, @Daetalus /reviewed-by @jhuge, @lu.xu /reviewed-on nexedi/slapos!1485
-
- 28 Nov, 2023 3 commits
-
-
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
-
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
-
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
-
- 23 Nov, 2023 3 commits
-
-
Lu Xu authored
accidentally removed [slaplte.jinja2] _update_hash_filename_ = slaplte.jinja2 md5sum = from buildout.hash.cfg
-
Lu Xu authored
The Netconf subscriptions were added twice, causing the RU to reboot because there was no supervision check on the redundant subscription.
-
Lu Xu authored
The Ncclient does not have a timeout for taking notifications, causing it to wait indefinitely. This can result in the connection being lost while the waiting process is still ongoing.
-
- 21 Nov, 2023 2 commits
-
-
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
-
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
-
- 17 Nov, 2023 7 commits
-
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
- 16 Nov, 2023 1 commit
-
-
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
-
- 13 Nov, 2023 1 commit
-
-
Lu Xu authored
-
- 07 Nov, 2023 1 commit
-
-
Kirill Smelkov authored
We can use mathematical relation in between ports, channels and tx/rx endpoints to bring structure and clarity in RU setup. Also, while on it, document how tx/rx data flow are organized as it was not clear just from reading ORAN specs and I had to deduce it. /cc @jhuge, @lu.xu, @xavier_thompson, @Daetalus /reviewed-by @lu.xu /reviewed-on nexedi/slapos!1468
-
- 06 Nov, 2023 1 commit
-
-
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
-
- 02 Nov, 2023 3 commits
-
-
Joanne Hugé authored
-
Joanne Hugé authored
-
Kirill Smelkov authored
In multiRU we will need to be able to check multiple CPRI boards and multiple SFP ports on them, not only SFP ports on CPRI board 0 that was implicitly used until now. -> As a preparatory step the SR to explicitly specify which CPRI resources are being verified. This patch is necessary because in nexedi/slapos.toolbox!127 we adjust check_cpri_lock plugin to require CPRI device + SFP port to be explicitly specified. /cc @tomo, @xavier_thompson, @Daetalus /reviewed-by @lu.xu, @jhuge /reviewed-on nexedi/slapos!1461
-
- 31 Oct, 2023 2 commits
-
-
Kirill Smelkov authored
In multiRU we will need to be able to check multiple radio units for RX saturation separately. -> As a preparatory step adjust the SR to explicitly specify the list of RX antennas to be verified. This patch is necessary because in nexedi/slapos.toolbox!126 we adjust check_rx_saturated plugin to require list of RX channels to check to be explicitly specified. /cc @tomo, @xavier_thompson, @Daetalus /reviewed-by @jhuge, @lu.xu /reviewed-on nexedi/slapos!1459
-
Kirill Smelkov authored
In multiRU we will need to be able to check multiple devices and DMA channels, not only /dev/sdr0@0 that was implicitly used until now. -> As a preparatory step adjust the SR to explicitly specify which SDR resource is being verified. This patch is necessary because in nexedi/slapos.toolbox!125 we adjust check_sdr_busy plugin to require SDR device/DMA channel to be explicitly specified. /cc @lu.xu, @tomo, @xavier_thompson, @Daetalus /reviewed-by @jhuge /reviewed-on nexedi/slapos!1458
-
- 20 Oct, 2023 3 commits
-
-
Joanne Hugé authored
-
Joanne Hugé authored
-
Joanne Hugé authored
-
- 16 Oct, 2023 2 commits
- 13 Oct, 2023 1 commit
-
-
Lu Xu authored
-
- 12 Oct, 2023 1 commit
-
-
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
-
- 27 Sep, 2023 1 commit
-
-
Thomas Gambier authored
-
- 22 Sep, 2023 3 commits
-
-
Joanne Hugé authored
-
Joanne Hugé authored
-
Lu Xu authored
-
- 04 Sep, 2023 1 commit
-
-
Joanne Hugé authored
-