FHI72: Management plane support
At the moment, tested with Benetel 550 and 650 RUs FW v1.2.2
- support for multiple RUs
- RPCs implemented: <connect>, <subscribe>, <get>, <supervision-watchdog-reset>,
<edit-config>, <validate>, <commit>, <disconnect>
- read PTP sync status from operational datastore xml
- get vendor name, and for xran store RU MAC, MTU and IQ bitwidth and PRACH
offset, and transfer this info
- store interface name, low-level-tx/rx-endpoint names, tx/rx-carrier names,...,
from operational datastore xml
- add reference gNB/DU config files with M-plane support
- update FHI readme
- Increase the maximum logging line for print done through
log_output_memory().
The reason is that we hit this line length when printing some machine
generated configuration (XML) through the M-plane. Increase to make
more of it visible.
- To limit the impact, only increase this locally in function
log_output_memory(), and statically assert that it will never be
larger than 64 kB.
In other places, we use the old limit.
- Move the definition MAX_LOG_TOTAL to log.c, because it's only used
there.
Shared memory realtime radio simulation
Realtime and near-realtime RFSimulator alternative without channel modelling.
The purpose of this library is to allow realtime simulation of gNB and nrUE.
The library is loaded using --device.name vrtsim. The server side (gNB) should
also configure --vrtsim.role server and --vrtsim.timescale according to
requirements.
Limitations:
- Only 1UE-to-1gNB connection supported
Future work:
- Telnet API
This implements a server-client bidirectional time domain IQ channel via
shared memory.
The server creates the channel and should be aware of the client
receiver configuration (num rx/tx antennas).
Server shall be the time source and should call shm_iq_channel_produce_samples
at regular intervals
Add support for ARM build pipeline
Modify the existing python code to be able to build images where the
image tag can be prepended with a prefix, here arm_. This is preparatory
work to create the ARM build image pipeline, and reuse the existing
internal registry on porcepix to have x86 and ARM images coexist.
Fix various bugs in the build system to allow to build on a system with
as many cores as gracehopper.
Also, fix two programs (usim, nvram) to work correctly under ARM.
Various libraries in this commit use the log headers (that is the
direct dependency). The log headers in turn include the T headers
(transitive dependency). Building on gracehopper with its many cores
triggers the build of these libraries before T headers have been
generated.
To resolve this and force the generation of T headers before building
the libraries, correctly express their dependency on the log headers,
which in turn ensures that T headers have been generated.
Depending on log_headers is preferrable because it is really the headers
that we depend on. Using instead e.g., utils, would trigger build of
source files, that we don't need for these libraries. This commit is
part of a larger cleanup that I have that is not merged yet. Follow-up
work will generalize this in the repo, and ensure that every(!) library
builds.
We have to add CONFIG_LIB, as the log module has a direct dependency
onto the configuration module (it uses it). I am not sure why this was
not relevant before.
If "utc_time" is selected, log lines are prepended with the UTC time,
formatted as YYYY-MM-DD hh:mm:ss.ssssss UTC.
The documentation has been updated. For other time methods, additional
description of what they show has been added.
Long PRACH extends beyond a slot. Changes necessary to mark future slots
that may contain prach in ru, phy and mac functions.
In RU, the PRACH IDFT is done only after receiving last slot and marks
for L1 to start processing. The L1 processes at the last prach slot and
reports to MAC with the first slot index.
In MAC scheduler, the VRB for future slots are also marked as used.
PRACH scheduler is called in advance one frame minus num prach slots.
FHI72: remove polling, fix memory leak
- FHI72 used polling to track the next slot. This is not necessary, a
simple queue does the job and allows to save one core that was
previously at 100%
- Remove a workaround to avoid a memory leak (fixes#812); allows to
also run RFsim/USRP/otehr radios when compiling for FHI72
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth
Added Support of 35Mhz,45Mhz,70Mhz Bandwidth for 30Khz Subcarrier
Spacing, Also added 35Mhz, 45Mhz bw for 15Khz Subcarrierspacing.
Referred Spec TS 38.101 v18.6.0 section 5.3.2, table 5.3.2-1
Changes to support multiple TDD patterns
- Updated the configuration changes for 2 Patterns
- Update the TDD table configuration for NFAPI
- Added the tdd bitmap for the period
- Adapted the bitmap for UL/DL for the multi TDD pattern
- Updated the RACH procedure for multi TDD pattern
- Updated DL and UL scheduler for multi TDD pattern
* the function is returning the index of the first full UL slot in tdd_slot_bitmap
or the first UL slot (including mixed) if the "mixed" flag is provided
* set_tdd_bmap_period, config_tdd_patterns: to configure TDD period, including bitmap, in the frame structure
* get_tdd_periodicity: to retrieve the periodicity in milliseconds for the given TDD pattern
* get_tdd_period_idx: to get the TDD period index based on pattern periodicities
* get_ul_slots_per_period: get the number of UL slots (including mixed with UL symbols) in period
* get_full_ul_slots_per_period: get the number of full UL slots in period
* get_dl_slots_per_period: get the number of DL slots (including mixed with DL symbols) in period
* get_full_dl_slots_per_period: get the number of full DL slots in period
Co-authored-by: vijay chadachan <vijay.chadachan@firecell.io>
ran_func_kpm.c uses cp_ba_to_str(), but it is not defined in OAI. Define
it so we can link properly, instead of relying on FlexRIC (where it was
defined).
Useful to debug realtime issues, for example when calling a periodical
routine, if it's not programmed carefully enough, it may be that the first
call takes way longer than the next ones (for example it uses some memory
that is not mapped in the process, leading to many page faults the first
time it's executed).
Having a periodic log for the timing of this routine with min/avg/max/count
will reveal that a call is way longer than average and will help in
finding where exactly in the code the time is spent, thanks to the ease
of use of the T tracer; you put T(T_XX, T_INT(1)) just before the code
you want to measure, you put T(T_XX, T_INT(0)) just after and time_meas
will show the delta time between those events. Then you cut the routine
in smaller pieces, measure with T(1)/T(0), and you finally reach the small
guilty part that takes too long.
In time_meas.c, when getting 0 for the event, we log delta time with
previous 1 for the event. "start_valid" was not cleared, so receiving
a second 0 without 1 in between may lead to wrong logging.
Should not happen in practice, but still, little bug.
(Note: we don't protect against streams of 1, but this case should also
not happen.)
francescomani