N3101 potentially being updated only during RBBP poll but not during USF poll
N3101 spec can be found in TS 44.060 "13.4 Counters on the Network side". Regarding possible values it states: "N3101max shall be greater than 8."
N3101 is set per-bts over PCUIF. In turn the BTS gets that N3101 value from BSC over OML (NM_ATT_IPACC_RLC_CFG). The value "10" is harcoded in osmo-bsc here:
Something alarming though... spec says: "the network will increment counter N3101 for each USF for which no data is received for this TBF.", and from looking at the code I have the feeling we are only increasing it only during tbf::poll_timeout(), but not each time that an UL packet from the tbf was expected (eg data ul packets, polled by USF). It looks as if N3101 was implementing N3105 in mind instead (which triggers T3195 which also ends up calling tbf_timeout_free()).
N3105 seems to be implemented (also increasing in tbf::poll_timeout()), but it may not be necessarily being increased in all RRBP cases (eg. CTRL ACKins a Packet Cell Change Continue). A dl_tbf::is_waiting_for_rrbp(curr_fn, curr_ts); function covering all cases would be welcome here.
First of all, I'd look at whether poll_timeout() is called when the BTS doesn't receive data for a given MS which was asked to transmit by USF. That can be done easily by writing a TTCN3 case in PCU_Tests.
AFAIU poll_timeout() should only be called when a poll FN is reserved by means of RRBP, but not USF (see sched_select_uplink() in gprs_rlcmac_sched.cpp).
To see other current polling scheduler issues, see #5020.