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.
Prior to this commit, the handling of DRBs is complex: first the RRC
"guessed" a DRB ID when setting up DRBs via E1AP (in
rrc_gNB_process_NGAP_PDUSESSION_SETUP_REQ()), and later chose one for
real in fill_DRB_Configlist() (called in
rrc_gNB_generate_dedicatedRRCReconfiguration()).
To simplify, remove fill_DRB_Configlist(), and instead allocate the DRB
using generateDRB() before sending the message via E1AP, in
rrc_gNB_generate_dedicatedRRCReconfiguration(). The rest of the logic is
the same.
For PDU sessions, always mark PDU sessions as "done" to match pdu
session state logic.
It might happen that a UE has no CU-UP (e.g., never requested a PDU
session). When triggering a release, we previously and implicitly
associated a CU-UP in that case. That is not good, and confusing.
This commit adds a function to look up if the UE has an associated
CU-UP. We only send a release if it is the case.
The function get_existing_cuup_for_ue() now instead verifies that a
CU-UP exist, and does not implicitly create an association (which might
be unwanted, see above).
The function rrc_gNB_process_RRCReconfigurationComplete() does almost
nothing, we can delete it.
The variable name ue_reconfiguration_after_reestablishment_counter is
misleading, as it counts all reconfigurations; rename to make it clear.
The drb_active array keeps track of active DRBs. However, it only
replicates some of the information in established_drbs, and could lead
to a reuse of DRB IDs when two bearers are to be set up. Consider the
following:
1. trigger first DRB creation at RRC
2. DRB ID chosen from free drb_active entry
3. trigger second DRB creation at RRC
-> The first reconfiguration has not been acknowledged
-> drb_active is not marked as DRB_ACTIVE
4. The second DRB ID is chosen from a free drb_active entry, which is
the same as in 2.
By reusing established_drbs everywhere, this cannot happen, as we
1. select the DRB to be used using next_available_drb() and then
2. use generateDRB(), which marks the DRB used
all from within fill_DRB_configList, which gives a new DRB.
The logic is still overly complex, though.
If there are no active bearers, the function previously returned an
empty list. Return NULL if there are no bearers, so it is safe to call
this function even when no bearers are present. We can also pass it
every time to do_RRCReconfiguration(), which will not add an empty list
for DRBs.
Create a single function to activate an SRB. This function derives the
corresponding keys, triggers the setup in PDCP, and marks the SRB as set
up, instead of doing all of this common functionality in individual
steps. Use it at the corresponding places.
This commit implements retrieval of 5G-S-TMSI from Parts 1&2, or the
entire 5G-S-TMSI, depending on what the UE sends. Further, if it has
been retrieved, print a log of all constituent parts of it.
The UE-specific variable ng_5G_S_TMSI_Part2 is not needed, as we compute
the full 5G-S-TMSI as soon as we have Part2 (and 1).
The correct forwarding to the core is implemented in the following
commit.
We did not give a cause value, and therefore NGAP's "PDU sessions
failed" encoding failed. Give a cause value in all cases, so that this
cannot happen anymore.
To prevent against this, put an AssertFatal() into the encoder that
stops if an internally sent message does not have a correct cause value
(we can at least select a default).
Print an info message for all failed PDU sessions.
In rrc_gNB_send_NGAP_INITIAL_CONTEXT_SETUP_RESP(): if a PDU session is
already established, don't count it as failed.
Robert Schmidt