apply same change that we've done on the eNB also on the UE
to avoid the PHY processing TTIs faster than the stack.
Without that, we see lots of those in the logs:
...
08:39:17.580325 [STCK] [W] Detected slow task processing (sync_queue_len=7).
...
before entering RRC idle, after receiving a RRC connection release for example,
we need to wait until the RLC for SRB1 or SRB2 have been flushed, i.e.
the RLC has acknowledged the reception of the message.
Previously we have only waited for SRB1 but the message can also be received on SRB2
and in this case both bearers need to be checked.
The method is now streamlined to check both SRBs and is also used when
checking the msg transmission of an detach request.
* Added the appropriate code for handling and sending the
re-establishment procedure messages to rrc_ue.c/.h.
* Triggered RRC reconfiguration after the reception of RRC
re-establishment complete
* Refreshed K_eNB at the reception of re-establishment
request
* Changed the mapping of TEIDs to RNTIs in the GTP-U layer,
as the RNTI might change with reestablishment.
Bugfix the wrong ra_rnti calculation in ra_proc::state_pdcch_setup.
According to TS 36.321 Subsection 5.1.4 Random Access Response reception, we can see the formula on RA-RNTI, which is,
RA-RNTI= 1 + t_id + 10*f_id,
where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0≤ f_id< 6). Then, reading the srslte source code, we can see that, the code should bugfix.
BTW, the wrong code can run normal for LTE_FDD, causing of the info_f_id = 0; but it should be wrong, when it is LTE_TDD.
if no cell/PLMN can be found if the UE is switched on, the UE was never
trying again.
In theory this would be handled by T3410, but the timer
is not started in case the PLMN search isn't done yet.