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
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.
- many structs and definitions are overlapping between the two different E1 procedures
- introduced naming specific to E1 Bearer Context Modification to improve readability
- grouped SDAP and PDCP configuration IEs for better reusability and readability
- introduced functions to set and get default PDCP config (DRBs and Bearer Contexts)
find_or_next_pdu_session:
- find_or_next_pdu_session refers to the E1 Bearer Context Modification Request
-- therefore it has to return pdu_session_to_mod_t* and takes in input e1ap_bearer_mod_req_t *
see !MR2545 for more context
- according to specs, in NR there are 4 SRBs
- in OAI the relevant define is used in the RRC procedures
- this commit harmonizes code by removing redundancy
Giulio Carota