The RA process may be in the state:
RA_active == FALSE and wait_ack_Msg4 == 1
Testing only the rnti should be enough, if everything else works
properly.
Also, don't break, just in case. (Not sure it makes a
difference.)
The previous version was calling taus(), which
may return any value in [0..65535].
The new version restricts it to [1024..59999]
(arbitrary values, big enough, and in the valid range).
It also checks that the new RNTI is not already present
in the MAC.
I think we should also check that it's not used by a RA
process.
The "loop" thing may not be the best solution either.
To be refined.
A RA process is not available if
and RA_template[i].wait_ack_Msg4 != 0
We can have RA_active==FALSE and wait_ack_Msg4==1,
in which case the RA process is in use and cannot
be reassigned.
RRC does not work very well when one UE goes away and comes
back in some situations.
This commit is an attempt at making things work better.
It is probably not the end of the story.
Modern UEs have very long UE capabilities.
It disrupts realtime behaviour of the modem.
Let's put a simple log message indicating we got the
UE capabilities.
Here is the problem:
Sometimes the UE has no PHY context but
is still present in the MAC with 'ul_failure_timer' = 0 and
'ul_out_of_sync' = 0. It seems wrong and the UE stays there forever. Let's
start an UL out of sync procedure in this case.
The root cause of this problem has to be found and corrected.
In the meantime, this hack...
This has to be redone at some point.
Here is the problem:
UE comes. SRB2 is configured via message to RRC.
At some point the RLC AM is created but not configured yet.
At this moment (I think) MAC calls mac_rlc_status_ind
which calls this function. But the init was not finished yet
and we have a crash below when testing mem_block != NULL.
The "solution" is to test if rlc->input_sdus is NULL.
This is a very dirty hack. I would say the solution
is to use proper locking mechanism because RLC is used
by two threads: PHY/MAC on one hand and RRC on another
hand (I think).
The management of uplink failure generates a DCI to send
a RA PDCCH order. It calls add_ue_spec_dci which increases
DCI_pdu[CC_id]->Num_ue_spec_dci, but this was reset to 0
*after* the DCI generation. Let's reset *before*.
Bug reported by Liang Yong on openair5g-user mailing list.
The function may return NULL if the UE has been dropped
in the PHY layer but is still present in the MAC layer.
Deal with the NULL case everywhere it's needed.
Cedric Roux