Integration: `2024.w10`
See merge request oai/openairinterface5g!2608
* !2427 Scan build: Result of operation is garbage or undefined
* !2477 cleanup of nfapi_nr_interface.h and more
* !2523 CI: AW2S pipeline - test with 16 UEs including RAN code fixes
* !2530 Rework of MAC UE handling of DAI
* !2583 Small-bug-from- cdb18d38bfa6aee288a68d9e8881615a48addd83-and-one-gcc-warning
* !2592 NR DMRS RX comments
* !2599 Log module small cleaning
* CI: mark as failed if UE log analysis fails
* !2465 NVIDIA Aerial Integration
* !2409 Ue rework keep sync in frame
* !2603 tx_timestamp computation doesnt count slots from rx timestamp, and a small...
* !2607 preventing negative RX absolute slot in NR softmodem
* !2606 Instructions on how to debug using container images and core dump of CI
* !2609 Upgrade Open Cells Project UICC/SIM programming tool and rename FR2 SA configuration file
* fixup after merge of Aerial
nr_fill_indication() fills CRC and RX requests, to be sent from L1 to
L2. Before this commit, nr_fill_indication() is called when
- we finally decoded LDPC (or not)
- low signal on PUSCH
This might happen at the same time, i.e., nr_fill_indication() might try
to fill both CRC and RX, in the same list, from different threads. This
can lead to this assertion:
Assertion (crc->rnti == rx->rnti) failed!
In handle_nr_ulsch() ../../../openair2/NR_PHY_INTERFACE/NR_IF_Module.c:190
mis-match between CRC RNTI e071 and RX RNTI 5e3b
e.g., e071 is low energy, and while 5e3b related message are filled in
one thread, e071 is being put into the message structure as well.
At least that is my understanding. I could not actually reproduce this
assertion; to be seen if it still happens.
Do not assert if the list of phy statistics is full; instead return
NULL.
In most places, this is handled appropriately (we do not store anything
if we can't). In nr_decode_pucch0(), the return value of get_phy_stats()
is used a little bit all over the function, and a constant
if (uci_stats)
uci_stats->variable++;
would look ugly, so make uci_stats point to the stack if we cannot store
in the phy_stats.
the uci_stats variable (pointing to per-UE statistics for UCI) is used
in function nr_decode_pucch0() to store information which is important
beyond statistics, e.g., uci_stats->pucch0_thres as a threshold (which
comes from somewhere else)
This commit refactors to use original or intermediate variables to not
mix uci_stats usage with actual processing.
Also, group uci_stats a bit more.
They use 4G NUMBER_OF_UE_MAX, which is not supposed to be present in 5G.
Further, the mutex and variable are global state; for Paging, we should
use F1.
We can only support up to 30 UEs for SRS. In this commit, we change:
- if the total number of UEs is > 32, throw error during compilation to
raise awareness (32 so that a multiple of two still works, everything
else is confusing, see also next point)
- during runtime, handle gracefully if UID is 30 or 31 to not abort (we
can simply not allocate SRS resources)
Also, refactor config_srs() to always give back new memory; the code is
shorter and clearer. Rename to get_contig_srs() to make it explicit.
Set ulimit of core to -1 enable core dumps for file-based core dumping.
Note that it is not necessary for e.g., systemd-coredumpd, but put it
for completeness.
- Return code says if copying succeeded
- Improve handling of the recursive code paths, which copy files or
directories recursively into another directory
- both for RemoteCmd/LocalCmd
Some CI users (OAI developers) expressed that the warning of the `docker
volume prune` before starting RFsim is confusing. To avoid the warning in
the HTML, force the removal; if the volume does not exist, no warning is
emitted.
To still catch possible problems, do not do this in the `terminate.xml`
so we might still see if there are other problems.
The original UL max MCS of 9 was chosen for performance reasons. In the
meantime, machines became faster, and the ULSCH decoding faster. Improve
UL max MCS to be 28 by default to use the complete range of possible
MCS.
Doing only 5 LDPC iterations by default leads to a poor reception
performance, and correspondingly many retransmissions. Increase to 8 as
the new default to improve user experience.
Ensure that the UE has an IP address before continuing the test.
Otherwise, it might happen we ping before the UE is connected.
Do not do this in do-ra and phytest, as they use --noS1, which implies
statically assigned IP address, so IP address check always succeeds(!).
Make RFsim start up faster by starting core and RAN start at the same
time. This speeds up because we do not wait for "healthy" containers
serially, but parallely.
For the RAN, it is safe to start gNB and UE at the same time in SA mode
(as the UE will only attach once the radio, and hence the full gNB, is
ready).
We do not start in parallel in do-ra and phytest, as in these modes the
gNB first has to write a UE-specific configuration file. If we start
both gNB and UE at the same time, the UE might try to read the file
before it is written, leading to a failure.
The previous code removed the "secondary UE" data (about DU association,
DU UE ID, associated CU UP), and only filled the F1-related data. In
other words, the associated CU-UP was lost. This commit reworks this
piece of code to retrieve old data, and update the relevant data without
destroying other.
CI: Integration Branch 2024 week 08
See merge request oai/openairinterface5g!2585
* !2540 NR UE max MIMO layers from UEcap
* !2554 NR UE RRC minor improvements
* !2563 Add missing backtick for proper code style in README.md
* !2567 Avoid integer overflows, buffer overflows, in channel levelling
* !2574 NR UE fix for configuring coreset0 and SS0
* !2575 NR UE fix init PDCP phy-test
* !2551 NR UE improvements for contention resolution timer
* !2570 CI: Replace nrmodule2 by up2
Integration: 2024.w06
Closes#733 and #732
See merge request oai/openairinterface5g!2564
* !2490 reworking configuration of LogicalChannelConfig at MAC UE
* !2548 NR UE MSG3 buffer
* !2556 Support RC SM aperiodic subscription for "UE RRC State Change"
* !2557 fix duplicate call of RCconfig_NR_L1
* !2550 use pointer to structure instead of module_id inside MAC
* address #733
* !2560 chore(ci): force rebuild of ran-base for integration branches
* !2495 Sidelink configuration passed from RRC->MAC
* !2220 L1 tx thread
* !2559 FH 7.2 improvements
* !2566 Provide right E1 instance when creating E2 agent in CU-UP
* !2513 Update NR SA tutorials
CUuniqInstance is also used for GTP module identification, which
uses the UDP server socket as its ID. This leads to arbitrary IDs (>0),
which is wrong.
PUSCH decoding is started multiple times in nr_ulsch_procedures() for
each ULSCH segment, and stopped once inside
phy_procedures_gNB_uespec_RX(). Not only is it not clear if that works
with the API, it also might measure more than just PUSCH decoding.
Remove the PUSCH decoding, it is misleading. Check L1 RX processing
instead.
The CI would only detect a deviation from the normalized value based on
a configurable threshold, typically 1.25 (so we would tolerate a 25%
increase). However, it often happens that a timing gets shorter (e.g.,
forgot to put the timing measurements). This commit introduces a
"Deviation Threshold" (smaller than 1) to not only check that we exceed
1.0 + "Deviation Threshold" (as before), but also that are not below 1.0
- "Deviation Threshold".
In other words, assuming a maximum divergence of 25%, instead of just
checking if val > 1.25, we now also check if val < 0.75 (and flag
error).
The UL_INFO_mutex is used in only one place, and therefore useless.
Also, the scheduler uses a lock internally to prevent concurrent access.
Hence, the UL_INFO_mutex is not needed.
Remove kill_gNB_proc(), as it is now dead code.
The next commit introduces a separate gNB TX processing thread. To
properly separate DL scheduler (for scheduling decisions) from UL
indication handling (for UL packets), this commit introduces a slot
indication "tick" to run the DL scheduler which will be put into the gNB
TX processing chain instead of the UL indication.
For different reasons, the frame/slot numbers might jump (e.g., gNB and
RU machines not properly synced). The scheduler would assert for PUCCH
allocations. Handle this gracefully by printing an error message, and
resetting the PUCCH structure.
Disable DPDK telemetry to skip creation of one/two threads (depending on
DPDK version). To force users to do this, bump the version of the patch
checked by cmake.
More information on DPDK telemetry:
https://doc.dpdk.org/guides/howto/telemetry.htmlCloses: #732 (suggestion 2)
Suggested-by: Andrew Sergeev <andrew.sergeev@adtran.com>
Force the CPU affinity for ru_thread explicitly to ru_thread_core. It is
already done via threadCreate(), but force again as per change request.
Delete commented 7.2 code that did the equivalent. We cannot set it in
the driver, as we don't have access to variable ru->ru_thread_core.
Closes: #732 (suggestion 2)
Suggested-by: Andrew Sergeev <andrew.sergeev@adtran.com>
system_core is the core reserved for DPDK control threads. It was
hardcoded to 0, but it seems that one some systems, CPU 0 cannot be
reasonably isolated from kernel threads. Make it therefore configurable
(default: 0)
Closes: #732 (suggestion 1)
Suggested-by: Andrew Sergeev <andrew.sergeev@adtran.com>
Integration: 2024.w05
See merge request oai/openairinterface5g!2549
* !2537 Fix for UE PUSCH scheduler DURATION_RX_TO_TX assertion
* !2538 Fix for UE MAC PDU LCID handling
* !2542 Fix L1_SSB_CSI_RSRP table mapping and check validity
* !2544 NR UE RRC timers improvement
* !2546 Correcting the location of packages
* !2493 Fix for computing SSB subcarrier offset
* !2496 MCS for retransmission fix in case of dci failed detection at NR UE
* !2503 Handle PDU Sessions in NG Initial UE context Setup and forward 5G-S-TMSI to core
* enable caching in the docker build of the CI build steps
* !2541 Fix RA bug, improve overall logging
We used to trigger the UECapabilityEnquiry right after
SecurityModeComplete, and before the RRCReconfiguration (which we call
"default" reconfiguration). However, 38.401 tells us that we should send
the RRCReconfiguration right after the SecurityModeComplete. In fact,
even though we get the UE capabilities, we cannot use them during this
reconfiguration, as we would first need to update the DU with a UE
Context Modification Request, which we cannot, as we just sent the UE
Context Setup Request, and the DU relies on first getting the
RRCReconfiguration.
Since we rely on a subsequent reconfiguration anyway, we can safely
trigger the UECapabilityEnquiry after RRCReconfigurationComplete.
(38.331 also says we can send UECapabilityEnquiry at any point.)
To cater for the possibility that there might not be any reconfiguration
coming afterwards, we check if a DRB has been set up. If not, we assume
a reconfiguration will come, and do not trigger one only for the UE
capabilities (this is what we do before this commit). If we already have
DRBs set up, they might have been set up during the "default" RRC
Reconfiguration, and another reconfiguration might not follow soon; in
this case, we trigger the reconfiguration by sending the UE capabilities
to the DU right away.
The next commit moves the UE Capability Enquiry after the first
reconfiguration. This has the effect that for some UEs (e.g., iPhone),
the Setup Requests come too close to each other, triggering RRC
Reconfigurations while previous transactions are ongoing.
I think the "true" solution would be to implement some tracking of
transactions across RRC, F1AP, E1AP, but this might require many
changes. For the moment, limit to delaying PDU session resource setups
to prevent above problem. Delaying is done using ITTI timers (to be able
to serve other UEs), waiting 10ms each time, up to 20 times (to not
deadlock the transaction -- after all, if the UE is unhappy, it will
drop the connection).
This commit allows the gNB to handle PDU sessions that the core requests
to setup during the NGAP Initial UE Context Setup. Previously, we only
managed them as part of PDU Session Resource Setup Request.
The RRC will, depending on whether a PDU session is in the NGAP Initial
UE Context Setup, either directly trigger the Security Command, or first
do a bearer setup at the CU-UP. Some asserts have been lifted, as now
the PDU sessions might be present before the RRC Connection is fully
established.
Implement the correct forwarding of the bearers in an F1 UE Context
Setup Request message.
This solves bug #672.
Robert Schmidt