usrp constant and slow derive timestamp
Sample write reorder function doesn't handle properly the clock shift.
It keeps the same time origin forever, so, if the clock sifts in one direction,
we finish to reach the maximum time shift that was designed for slot to slot
maximum shift.
We may also consider if this function is useful: gNB and UE currently ensure Tx
in order because there are other issues above if we let Tx preparation run out
of order in separate threads
Closes#893
- Refactor SCTP Association Response Handling
- Unified function for both CU-CP and CU-UP handling
- CU-CP: Notifies RRC of E1 connection loss with CU-UP
- CU-UP: Initiates a new SCTP association request to regain E1 connection
- this fix will prevent issue #878 from happening
- Send list of PDU Session Resources to Failed Setup in the (PDU Session
Resource/Initial Context) Setup Response
- depending on different failure scenarios
- e.g. (#878) when No CU-UP is associated and still the CU-CP receives a PDU
Session Setup Request
- add relevant functions to handle NGAP Setup Response messages with failed
list of items
- this is an extra failure handling to make #878 is handled if it ever happens
again
- NGAP Cause Refactoring
- Refactor struct for NGAP cause group and value
- Add extended radio network cause enumeration values
- Refactor redundant code into a new NGAP cause encoding function
- Minor logging, function descriptions improvements
Closes#878
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.)
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.
Guido Casati