- first PUSCH containing RRCSetupComplete not programmed for reception in PHY for some reason. DCI_0_0 received by UE.
- if RA fails, on the second attempt there is usually a crash (sometimes in L2_interface.c when getting UE context (added AssertFatal on this now).
-RRCSetupComplete successfully transferred to RLC of the UE now through SRB1, but not at the MAC yet.
-Needed to enable some additional elements for RLC config. at the gNB side (asn1_msg.c) so that the addition of the SRB does not fail at the UE.
To verify if these are really required.
The bug was:
connect a phone, disconnect, repeat five times. The fifth time the phone
does not reconnect because there is no free RA process.
When an UE is removed, we have to free associated RA processes.
Before this commit, when the gNB crashes, the eNB keeps running.
Same, if the eNB crashes, the gNB keeps running.
In a far past when this happened, the other program (the one not
crashing) was forced to exit.
Then this behavior was changed, for some reason.
But the code was not finished, so now we have a system in an inconsistent
state.
So either we accept that the connection between eNB and gNB can break,
that is one of the programs crashes, and we clean the state of the
program that keeps running. But this is a complex work and it will
surely not survive very long, because someone will change something
in the code later that will break this complex behavior.
Or, simpler, we go back to initial behavior, which is: the program that
did not crash does actually exit when the other crashes.
This commit provides the second solution.
It can easily be reverted whenever someone wants to implement the complex
solution.
We used to set 'does_nr' of an UE if we detect ENDC supported in the
UE capabilities.
Then we activate NR measurements if 'does_nr' is true.
The problem is that if the eNB is not connected to a gNB but the UE
reports some NR measurements (because a gNB is running somewhere near)
then the eNB will crash when starting the switch to NR.
A (quick) solution is to set 'does_nr' only if there is a gNB connected to
the eNB.
Maybe not the best solution. To be changed if needed.
This code has not been tested with a COTS UE. We need SRB1/2 (so we need SA)
to test.
The activation of security and integrity for SRB1 will need more code
(new functions) because it happens after some time, not at creation time
of the PDCP entity and there is no way to do this with current code.