Add utility functions to print the FAPI messages contents
Add dump functions for DL_TTI.request PDUs, remaining message structures to be finished
Add file examples.md with some examples on how to use nfapi_hex_parser
Now uses RC.nb_nr_L1_inst instead of RC.nb_nr_inst in order to configure the L1, since in PNF RC.nb_nr_inst is always 0, and so, it wouldn't configure the L1
chore(ci): Move to new Jenkins and Openshift Cluster
- Update helm-charts with new node roles
- Add resource definition in physim helm-charts to easily schedule them
on different cluster servers
- Update entitlement creation methodology
- Add namespace for aerial pipeline
Due to HW version differences between the CI RHEL build machine and
the FHI 7.2 test machine (cacofonix), FHI 7.2 test using RHEL image
failed, reporting an 'Illegal Instruction' error.
* this commit is making explicit the mandatory IE cn_support
in the E1 Setup Request message
* also, init cn_support in E1 Setup Request initial message preparation
* E1 CU-CP Setup Request is an E1 Interface Management message
whose type defition was missing, and it is introduced in this commit
(see 9.2.1.7 of 3GPP TS 38.463)
LDPC coding was yet not properly stopped by using free_nrLDPC_coding_interface in gNB and UE.
This was not causing major issue until now. It was especially not causing any issue with T2 LDPC coding using the PF.
But using T2 VFs, if the coding library is not properly stopped then the VF cannot be used anymore unless the admin app is restarted.
So this MR adds the missing free_nrLDPC_coding_interface.
The offset provided for each code block in the HARQ combined input and output buffer shall not be above 512.
A modulus was performed on the offset of the TB in the buffer to avoid this situation.
But the offset of the code block was added afterward so that the total offset was sometimes going above 512.
This commit performs the modulus after adding the code block offset.
- extend get_xran_prb_map() function to handle mixed slot
- properly fill PRB configuration based on DL/UL direction and duplex mode
- do not implicitly assume TDD
Modify xu_add_f1_ue_data() to be xu_addmod_f1_ue_data(), i.e., "addmod"
behavior in which it is possible to also update f1_ue_data. I do it this
way since an xu_updade_f1_ue_data() function would be almost the same as
the add function (only deleting existing data, whereas the original
add() was asserting in that case).
Modify tests to test for this behavior.
This fixes a concurrency bug. For instance, during reestablishment, the
CU needs to update the DU UE ID under which the UE is identified in the
DU. Previously, the CU would remove, then add the DU UE ID info.
At the same time, the PDCP thread might look up the information. This
can lead to asserts. Use the above addmod functionality to do the
remove-add under a mutex.
- the parameters used in DL/UL are exactly the same, except the direction and the number of PRBs;
therefore, passing the direction seems convenient for visibility purposes and reduces the code.
Note: Number of PRBs we store in fh_config for both DL/UL is num_rb_dl of openair0_config struct.
At the end, it is actually the same info.
Cedric Roux