Merge branch 'next' into agpl_next

delete erab if gtpu tunnel creation failed

Merge branch 'next' into agpl_next

Remove -Winline from compiler flags.

proc_bsr: fix race condition in BSR reporting

fix for #1934

This fixes a race condition between Stack thread and DL
PDU processing that lead to updates of the RLC buffer that
are undetected by the BSR routine.

What happens is that in a UL SCH PDU all outstanding data is transmitted
and and a LBSR with all zero buffers is sent.

14:39:47.327301 [MAC ] [D] [ 3793] BSR:   LCID=3 old_buffer=59
14:39:47.330600 [MAC ] [I] [ 3793] UL LCID=3 len=58 LBSR: b=0 0 0 0

Note that "old_buffer" isn't set to zero here.

At the same time (same TTI), the MAC PDU processing thread handles DL-SCH PDUs
that may generate new UL PDUs:

14:39:47.330749 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=1)
14:39:47.330762 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=2)
14:39:47.330775 [RLC ] [I] DRB1 Tx SDU (54 B, tx_sdu_queue_len=3)
..

Those PDUs are "new data" since the previous buffer state was zero.

Here is the race now between the threads, at the end of the bsr::step() function
old_buffer of each LCG is updated with the previous new_buffer, so
the buffer state of LCG=2 is now 59.

Now MAC starts the next TTI:

14:39:47.331910 [MAC ] [D] [ 3794] Running MAC tti=3794
14:39:47.331928 [MAC ] [D] [ 3794] Update Bj: lcid=0, Bj=0
14:39:47.331934 [MAC ] [D] [ 3794] Update Bj: lcid=1, Bj=0
14:39:47.331938 [MAC ] [D] [ 3794] Update Bj: lcid=2, Bj=0
14:39:47.331941 [MAC ] [D] [ 3794] Update Bj: lcid=3, Bj=-1752
14:39:47.331951 [MAC ] [D] [ 3794] BSR:   LCID=0 update new buffer=0
14:39:47.331960 [MAC ] [D] [ 3794] BSR:   LCID=1 update new buffer=0
14:39:47.331964 [MAC ] [D] [ 3794] BSR:   LCID=2 update new buffer=0
14:39:47.331971 [MAC ] [D] [ 3794] BSR:   LCID=3 update new buffer=335
14:39:47.331976 [MAC ] [D] [ 3794] BSR:    check_new_data() -> get_buffer_state_lcg(0)=0
14:39:47.331980 [MAC ] [D] [ 3794] BSR:    check_new_data() -> get_buffer_state_lcg(1)=0
14:39:47.331984 [MAC ] [D] [ 3794] BSR:    check_new_data() -> get_buffer_state_lcg(2)=59
14:39:47.331988 [MAC ] [D] [ 3794] BSR:    check_new_data() -> get_buffer_state_lcg(3)=0
14:39:47.331993 [MAC ] [D] [ 3794] BSR:   LCID=0 old_buffer=0
14:39:47.332000 [MAC ] [D] [ 3794] BSR:   LCID=1 old_buffer=0
14:39:47.332003 [MAC ] [D] [ 3794] BSR:   LCID=2 old_buffer=0
14:39:47.332007 [MAC ] [D] [ 3794] BSR:   LCID=3 old_buffer=335

And since the buffer state of LCG=2 isn't zero, the new data for LCID=3 of that LCG is considered.
So effectivly, the BSR missed the "empty" buffer state for a fraction of time and doesn't
consider the outgoing data generated in the same TTI as new. It therefore
doesn't transmit a BSR.

in which a BSR wasn't

update readme and bump version of 20.04.2

rrc_cell_cfg: fix potential div by zero

similar fix has been applied for SR resources

cell_search_nbiot: show DL frequency in MHz

fixing bug in RRC measurement when receiving periodic config

in the UE conformance testing we've spotted an issue
where an event was evaluated even though the trigger type for
the report was periodic which caused an exception in RRC

SRSENB: Fixed PUCCH resource selection