Print a clear error if a config file does not exist (unclear previously,
when the user would get a confusing, unspecific, "file I/O error" on
line 0)
I tried to free the memory that had been allocated at that point, and
verified that using the address sanitizer. Nevertheless, the function
does too much, and is too complicated for refactoring.
Use correct baseTag for Unit Tests build in execution:
- if build_helper or othe files changed, which would trigger rebuild of
ran-base, use the corresponding ci-temp tag
- use that tag consistently afterwards
38.321 6.1.3.1 says: "The size of the RLC headers and MAC subheaders are
not considered in the buffer size computation" [for BSR]. However, prior
to this commit, we take the size signaled of the BSR and schedule the UE
with that amount of data, making it impossible for the UE to transmit
all its data at once (because it is the size signaled + headers).
In this commit, over-estimate the buffer status size. As we cannot know
the exact number and size of headers, we simply use "BSR size + n", as
done in function overestim_bsr_index().
It can happen that in the current DL slot, we cannot send an allocation
for Msg3 in a later UL slot. Up to this commit, MAC printed a warning.
However, this is not really a warning, as it will likely work in the
next or a later slot. So demote this to debug.
In some pipelines, it happens that iperf3 is hanging on 100% CPU load.
In these cases, a simple TERM signal does not seem to be enough to kill
it; KILL is necessary.
While e.g., RemoteCmd's driver paramiko has a timeout command, the
documentation [1] is not really clear how it is trying to stop commands.
Since it effectively does not stop, we have to assume it is only sending
TERM.
To remedy this, use the timeout command to start iperf3. We use option
-v for diagnose timeouts on stderr, and send KILL after an additional 3
seconds (-k3) if TERM does not succeed. The timeout is sent to the same
duration as the overall iperf timeout.
[1] https://docs.paramiko.org/en/3.4/api/channel.html#paramiko.channel.Channel.settimeout
A to-be-added UE's RA is added through nr_mac_add_test_ue() (the name is
misleading, it is not a "test UE") through its CellGroupConfig. Using
the process_CellGroupConfig() is unfortunate, because it is not really
clear what part of the CellGroupConfig gets evaluated (it is certainly
not all). Move the code for adding a new RA directly in the user-add
function, and refactor this one.
Introduce new LC configuration "priority", as specified in 38.321, and
use to sort LCs by priority. We set the priority of an SRB according to
38.331 Section 9.2.1, and for a DRB to be the minimum priority of the
QoS flows associated to this DRB.
Introduce new functions to add/release LCs without needing to go through
the intermediate CellGroupConfig. This harmonizes LC handling at the "DU
handler" to keep it consistent with RLC bearer handling.
These functions allow to group LC configuration handling, and we can
remove functions for setting NSSAIs and QoS by handling in one central
place (while adding LCs).
nr_mac_add_test_ue() is used by simulators and also in NSA mode to add a
new UE. Ideally, these users should also call the ue context setup
request handler to add a UE context; for the moment, respect the passed
list of LCs to add. Similarly, for do-ra, we require a dedicated
function to still parse the CellGroupConfig, so we keep that part of
functionality.
On reestablishment, since we do not process the CellGroupConfig from the
old UE, we need to add LCs for the new UE based on the onces from old
UE.
Use a common structure nr_lc_config_t to group LC configuration for one
logical channel. Use seq_arr for simple lookup, adding, removing of
elements without manual indexing logic.
This commit retains the previous logic of adding/releasing LCs through
the process_CellGroupConfig(), although we know while building the
CellGroupConfig if we add/release LCs. The next commit fixes this.
If we do not make this change, with the next commit, we get the
following error from gcc:
openair2/E2AP/RAN_FUNCTION/O-RAN/ran_func_kpm.c:299:46: error: assignment of read-only location '*(arr_ue_id.ue_info_list + (sizetype)(arr_ue_id.sz * 2444864))'
| arr_ue_id.ue_info_list[arr_ue_id.sz] = *ue;
In a later commit, we will use find_if in L2. In the case of building
with E2 agent, we link e2_agent which comes with its own implementation
of find_if_arr(), which results in a name clash. Rename the OAI
implementation, as nothing uses this, anyway.
This reverts commit 0d0e111135. It was
set to UE RX to TX time to 2 as it was deemed that the UE could sustain
this time. However, we noticed a degradation of performance, so reset
the RX to TX time to something higher to ensure proper performance.
uper_encode_to_buffer() of asn1c returns the number of BITS that have
been encoded; if we use this, we need to calculate the resulting number
of bytes (rounding up) to get the right buffer size.
Note that do_NR_ULInformationTransfer() uses
uper_encode_to_new_buffer() which returns the number of BYTES, hence, in
this similar function, we should not modify the return value.
Taking the example of the AMF Set ID, the previous version of the macro
used another macro to encode the number, then marked the last 6 bits in
the bit string (of length 16/2 bytes) as unused. This is wrong, because,
assuming AMF Set ID=3, it basically truncates the number by encoding all
16 bits and cutting off the last 6, like this:
------------------- encode 16 bits
0000 0000 0000 0011
------------ take these 10 bits
So what remains is these bit positions of the number:
(16,15,14,13,12,11,10,9,8,7) -- the last 6 bits are cut (and the first 6
are either 0 or garbage, because they don't exist).
Instead, manually encode bits (10,9,8,7,6,5,4,3) in the first byte, and
(2,1) in the second byte of the bit string, like so:
------------ encode 10 bits
0000 0000 1100 0000
------------ take these 10 bits
Do the same with the pointer.
The AMF Region ID above is correct, as it is exactly 8 bits.
In the case of PDU sessions in the NG UE context setup request, we first
have to set up security. Hence, in this commit, implement the "delayed"
set up of theses PDU sessions, and acknowledge the setup request after
reconfiguration, as requested by O-RAN.WG5.C.1-v11.
Trigger UE ctxt setup response for the case of "registration request"
(no PDU sessions in UE Context setup response), as mandated by
O-RAN.WG5.C.1-v11.
As of this commit, since we now send the UE security command as a DL NAS
message, there is no F1 UE Context setup request. Hence, instead of
sending a UE context modif request, send the UE context setup request
after the E1 bearer setup response (which logically also makes more
sense, as the E1 setup procedure comes before the F1 setup procedure).
This reverts commit 0f100a6e94, which
introduced a hack to possibly wait with a PDU session setup at the RRC
in case a RRC UE capability transaction (requesting UE capabilities from
a UE) was ongoing. This happened, as we delayed the UE capabilities to
after the first RRC reconfiguration; in that case, certain UEs were
requesting the next PDU session, and if RRC did not delay the new PDU
session (as requested from the core), this procedure might occur while
UE capability enquiry was ongoing, leading to failures in these
transactions.
The default RRC reconfiguration was previously sent after the security
mode command as a "first" RRC reconfiguration. However, it is simply not
needed, as it will be triggered through a subsequent reconfiguration
that also sets up DRBs.
Move the Measurement Config to the "other/dedicated" RRC
reconfiguration.
This reconfiguration would have forwarded a NAS PDU (typically a
registration accept). This is now done by a dedicated forwarding of NAS.
In the DU, read slice information from the DU config file. Handle
multiple slices within the F1 Setup Request structure representation,
and forward it via F1 to CU. The DU slice information is stored in the
setup request structure.
This reverts commit eaf28414ca.
This assertion was introduced as we (wrongfully) thought we needed to
calculate the SSB ARFCN at the CU. Since PBCH might carry one bit, which
is not available at the CU, only certain SSB ARFCNs would have been
possible.
With the availability of the SSB ARFCN through the
MeasurementTimingConfiguration, this is not necessary anymore.
MeasTimingConfig may not come with F1 Setup Request: some DUs send it
with the DU configuration update. Handle this gracefully by checking for
MTC before using it.
Reset all the circular buffer to zero; this ensures that we cannot read
uninitialized data. Since this is RFsimulator, performance is not a
problem here either (and zeroing out happens only once).
Memsan complains that uninitialized reads originate because of these
warnings. Most of the corresponding variables are actually read into
through by libconfig; nevertheless, initializing them should not have a
bad side-effect (because the initialized value is overwritten).
We access G_N at indexes that are not necessarily 32-byte aligned,
leading to segfaults. Use simde_mm256_loadu_si256() to load from memory
at an unaligned memory address to avoid the segfault.
Discovered using clang; it is unclear why gcc did not encounter the same
segfault.
-rdynamic is necessary for clang as well to properly link shared
executables. Add furthermore an option to ignore unused command line
arguments, to suppress warning
clang: warning: argument unused during compilation: '-rdynamic' [-Wunused-command-line-argument]
This is likely because -rdynamic is only relevant for the linker, but
the corresponding option add_link_options() is only available starting
cmake 3.13, while we are still at 3.12 (for Ubuntu 18, to my
understanding).
Unlike the previous commit, in noS1, we cannot use Attach(), as noS1
automatically brings up an interface, no matter whether the connection
succeeded or not. Therefore, consistently wait a bit longer to increase
the chance that the radio is really up.
Robert Schmidt