Cellular Network Infrastructure » Radio Access Network » OsmoPCU

• N3101_MAX is reached, by incrementing N3101 (unanswered USF transmitted blocks).
• N3103_MAX is reached, by incrementing N3103 (unanswered last UL ACK by means of CTRL ACK by MS, incremented on each retransmition of UL ACK).

Furthermore, when T3169 is enabled, the tbf should be in state RELEASING so that its USF is not used (see below some uses of it don't fullfil this).

• tbf.cpp gprs_rlcmac_tbf::poll_timeout(): This is at first sight the only proper place where it should happen, that is, after increasing N3101. It has to yet bee seen whether this whole block is correctly placed here in this function (see rant at the description of the ticket).
• tbf.cpp gprs_rlcmac_tbf::poll_timeout(): Check for the "N3103_MAX" condition. This one looks good to me.
• bts.cpp bts_rcv_rach(): T3169 is IMHO abused here and wrongly used, since the TBF is not set to RELEASE state (for obvious reasons). It needs to be checked with a TTCN3 what happens exactly under the scenario where MS never transmits UL data after requesting the UL ASS, specially for single block allocations. If a TBF exists, AFAIU we should simply rely on N3101 and drop the T_START for this case.
• tbf_ul.cpp tbf_alloc_ul(): Same here, we should rely on N3101 to eventually start T3169.
• tbf_ul.cpp gprs_rlcmac_ul_tbf::rcv_data_block_acknowledged(): This seems like a complete abuse of T3169 in order to make sure to drop eventually the TBF.

So all in all, my feeling is that N3101 counting may be broken and hence we rely on abusing T3169 by setting it directly in different places.

pespin wrote:

• bts.cpp bts_rcv_rach(): T3169 is IMHO abused here and wrongly used, since the TBF is not set to RELEASE state (for obvious reasons). It needs to be checked with a TTCN3 what happens exactly under the scenario where MS never transmits UL data after requesting the UL ASS, specially for single block allocations. If a TBF exists, AFAIU we should simply rely on N3101 and drop the T_START for this case.

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23232 pcu: Introduce test TC_n3101_max_t3169

So my concerns seems to be true. AFAICT there's no system in place for osmo-pcu now (PCUIF issue?) to detect USF assigned UL blocks for which no data was received, hence N3101 doesn't seem to be incremented, only by lost RRBP polls (gprs_rlcmac_tbf::poll_timeout() only called in that case, and N3101 being incremented there).

I still need to investigate further what goes on in BTS and PCUIF when the BTS is unable to decode a PDCH block (FN). A potentially good improvement would be to send some sort of NOPE-ind as we do in TRXDv1 nowadays.

remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23486 Fix: left shift cannot be repesented in type int [NEW]
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23487 sched: Fix scheduling UL TBF not matching conditions [NEW]
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23488 sched: Simplify usf selection code [NEW]
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23489 Set matching USF if available when polling a UL TBF [NEW]
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23490 pdch: Add mising pdch_ulc_release_node in Rx Cell Change Notif [NEW]
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23491 pdch_ulc: Create helper API pdch_ulc_release_node [NEW]
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23492 Track scheduled UL blocks through USF [NEW]
remote: https://gerrit.osmocom.org/c/osmo-pcu/+/23493 Properly implement N3101 [NEW]

• Make sure TTCN3 tests for T3169, N3101, N3103 and N3105 are passing fine. That means, investigating whether those counters are being incremented/reset in a correct way.
• Rework T3169 to only be armed as a result of N3101_MAX, N3103_MAX, etc. (when TBF goes into RELEASE state iirc), instead of having it always armed and re-arm it every itme something is received.

What's missing regarding this ticket:

• Make sure TTCN3 tests for T3169, N3101, N3103 and N3105 are passing fine. That means, investigating whether those counters are being incremented/reset in a correct way.

This is done in several tests, all of them behaving fine:

    execute( TC_n3101_max_t3169() );
    execute( TC_n3103_max_t3169() );
    execute( TC_n3105_max_t3195() );

I just submitted the missing one for N3103 here:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/23811 pcu: Introduce test TC_n3103_max_t3169

• Rework T3169 to only be armed as a result of N3101_MAX, N3103_MAX, etc. (when TBF goes into RELEASE state iirc), instead of having it always armed and re-arm it every itme something is received.

^ This is still TODO.

pespin wrote:

• Rework T3169 to only be armed as a result of N3101_MAX, N3103_MAX, etc. (when TBF goes into RELEASE state iirc), instead of having it always armed and re-arm it every itme something is received.

^ This is still TODO.

Done here, once merged the ticket can be closed:
https://gerrit.osmocom.org/c/osmo-pcu/+/23872 Stop abusing T3169

Merged, closing.