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
Introduce the structure nr_pdcp_integrity_data_t and adapt code to use it.
Note: in nr_pdcp_sdu_t we keep the 'count' variable (which is also present
in nr_pdcp_integrity_data_t). They represent the same value, but 'count'
in nr_pdcp_integrity_data_t is to be specifically used for integrity while
the other one has other uses, so it's better to keep it.
The case securityModeFailure didn't seem to be implemented
properly, so I just removed it entirely.
The variable 'securityMode' did not make much sense, removed as well.
Plus for integrity, there was: securityMode |= 1 << 5 for nea1
and << 6 for nea2, which does not seem correct (I would expect << 4
and << 5 respectively), so it was properly incorrect.
'securityModeCommand->criticalExtensions.choice.securityModeCommand'
was accessed before checking that
'securityModeCommand->criticalExtensions.present'
is 'NR_SecurityModeCommand__criticalExtensions_PR_securityModeCommand',
which is wrong.
The tests 'securityMode >= NO_SECURITY_MODE' and 'securityMode != 0xff'
don't make sense/are unclear, so removed too.
So let's simplify this function, wrong in several places. And put
some AssertFatal() so that the code won't do weird things. The
AssertFatal() can be removed later and the function improved later
if needed. The case securityModeFailure can also be handled later,
but I think there is more work to do than just encoding the message
and send it to the gNB, so it's not bad to remove it for the moment.
The use of security_mode_completed in the PDCP entity was a hack.
Plus it was not working at all with the deregistration request
when nea2 is used, sent when doing ctrl+c in the nrUE.
So let's remove it.
And let's handle activation of integrity and ciphering more in
accordance with what 38.331 says. SecurityModeComplete has to
be sent integrity protected, but not ciphered. Only after should
the ciphering be activated. (See 38.331 5.3.4.3.)
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.
Robert Schmidt