Previously, the CU sent the Security Mode Command as part of a UE
context setup request. This was done "because it was possible", not
because there was an inherent need to do this. However the LiteOn DU
does not like this, as it expects to also have a DRB in the UE context
setup request procedure, which is not always the case.
Hence, send the Security Mode Command in a normal DL RRC msg transfer
over F1. As of this commit, there is not UE context Setup Request (so it
might not work with all DUs), but the OAI DU is cool and does not care,
so RFsim still works.
This also aligns the CU's behavior with O-RAN.WG5.C.1-v11.
Finally, as of this commit, we do not trigger a UE context setup
request, so we cannot handle PDU sessions inside the initial UE context
setup request at the same time as the security mode command (which was
done previously before reaching this point). This will be fixed in a
later commit.
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.
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.
Use the correct MIB data structure, MIB_t. This is required by 38.473,
and the LiteOn DU sends only that. So our CU needs to handle it, so
align the OAI DU as well.
- according to 5.3.7.4 of TS 38.331: 1> re-establish RLC for SRB1;
- gNB:
1) re-establish RLC for SRB1 in nr_rlc_update_id
2) re-establish RLC for remaining RBs concurrently with RRCReconfiguration
issue: gNB) in nr_rlc_update_id the gNB is re-establishing RLC for all
RBs at the same time when receiving RRCReestablishmentRequest
from UE
UE) according to the specs, the UE is re-establishing RLC for
SRB1 with RRCReestablishmentRequest the other RBs are
re-established during RRCReconfiguration (in our case in
nr_rrc_ue_process_RadioBearerConfig) when receiving
reestablishRLC IE in rlc_BearerToAddModList
RLC TX) this leads to RLC counters mismatch after re-establishment:
control PDUs discarded until max nb of retx is reached
and then UL failure occurs
- remove PDCP reestablishment for DRBs from RRCReestablishment message generation
- do PDCP reestablishment and CUUP notification calls after reception or RRCReestablishmentComplete
- this is necessary to make it consistent with the RRCReconfiguration message that contains
RadioBearerConfig with the list of bearers to add/release
which is followed by PDCP re-establishment at UE
- SRB1 shall be re-established at the time of RRCReestablishmentRequest
according to 5.3.7.4 of 3GPP TS 38.331
- SRB2 shall be re-established when creating srb-ToAddModList
according to 5.3.5.6.3 of 3GPP TS 38.331
38.473 section 8.2.3.1 says that upon F1 Setup Request, UE associated
signalling should be erased. In this commit, we trigger a release of all
UEs that were still connected to a DU when we received the SCTP
shutdown, i.e., when the DU disconnects.
From the spec, it does not seem to be mandated to check that the random
identity needs to be unique within a cell. Also, from experience we see
that this only happens when the same UE "comes back"; so since one UE
can only have one connection, the other RRC UE contexts (with the same
identity) should be removed at some point, anyway, leaving only one with
the same identity.
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.
- PDCP reestablishment on CUCP (DRBs) triggering Bearer Context Modification procedures over E1
- Performing PDCP reestablishment for requested DRBs on CUUP
- Introduced function to notify re-establishment to CU-UP
- removed call to PDCP reestablishment for the DRBs on CUCP (it's done on CUUP)
cuup_notify_reestablishment:
- to fetch PDU session to setup in E1 following logic as in e1_send_bearer_updates
- fill bearer context modification request with stored F1-U tunnel information
during E1 reestablishment, otherwise it would initialized to 0 by default
- update GTP tunnel with the stored configuration after E1 reestablishment
Giulio Carota