building on the previous refactor this patch now adds support
for peridoic BSR reporting (using short BSR). It furthermore does
the following changes:
* add BSR packing
* add proc_bsr_nr unit test
* move mac_nr test code into test folder under src (needs to be done with other test code too)
this should fix log warnings then demux was trying to feed MAC CEs
to RLC:
10:50:54.845116 [MAC ] [I] [ 1153] Handling subPDU 1/2: rnti=0x0 lcid=61, sdu_len=1
10:50:54.845117 [RLC ] [E] Radio bearer id must be in [0:11] - 61
10:50:54.845118 [RLC ] [W] LCID 61 doesn't exist. Dropping PDU.
10:50:54.845119 [MAC ] [I] [ 1153] Handling subPDU 2/2: rnti=0x0 lcid=63, sdu_len=33
10:50:54.845119 [RLC ] [E] Radio bearer id must be in [0:11] - 63
The window elements are not being correctly cleaned up when clear() is called
or when overwritten by newer SN. Furthermore, the window count member is not being
correctly updated when the insertion of a newer SN overwrites the previous one.
I used the circular_map container to avoid this sort of bugs
not handling the case where allocation was failing was causing a
segfault. It seems that when doing high rate UDP iperf and
disconnecting the UE causes the buffer pool to become empty due
to the PDU buffering. Thus, causing a crash when attaching the UE again.
previously we were only counting retx if we retx the start of a segment.
this could lead to unwanted behaviour, i.e., not counting retx
correctly and thus not triggering the maxretx attempt, if the receive
always sends NACKs with a SO_start.
The RLC spec is not clear on how this should be handled correctly but
IMHO using an integer number of retx is reasonable, even for segments
that might be retransmitted more often.
The alternative of using a fractional retx counter that may be increamented
proportional to the segment size that is retx is another alternative
but considered too complex to implement (and test correctly).