Cellular Network Infrastructure » Radio Access Network » OsmoPCU

During all the improvements done recently in the SBA and TBF poll infrastructure (#5020), it was noticed that there are still some shortcomings in the SBA allocation process that may forbid MS to allocate an SBA (Single Block Allocation), specially under high subscriber load on the BSS where lots of channels are assigned.

Background:
The MS sends a RACH req on CCC requesting an SBA. The RACH req is passed over PCUIF to the PCU, which allocates the SBA and sends the Imm Ass message containing the time at which the block is allocated (and hence when the MS can transmit data to the PCU). This Imm Ass is queued in the BTS and eventually sent.
As it can be noted, the PCU has no way to know the exact timing that will take for the Imm Ass to reach the MS, since it has to move over PCUIF, then queued in the BTS (with variable number of other Imm Ass queued before it), then needs to be scheduled over CCCH.
Hence, it is important for the PCU to allocate a time for the SBA which is long enough in the future to arrive to the MS (via Imm Assign ewxplained above) before it expires. Otherwise, the MS has no time to transmit the UL block since the timing is too tight or in the past.
On the other hand, it is important for better service to make this time lapse as small as possible, in order to avoid huge delays when setting up a TBF, hence improving connection latency at startup. This can be directly seen with an MS starting a "ping" command: First ping will usually nowadays take in the order of 1000-1200ms, while follow up pings take around 450ms (because the TBF is already established).
So, in summary, the timing needs to be the shortest possible, but long enough to make sure the MS has time to answer to it.

Right now, osmo-pcu uses a hardocded "empirically found to be good enough in usually tested scenarios" timing of AGCH_START_OFFSET=52 (FNs). Recent improvements made this value to be "52 or higher if for whatever reason 52 was already allocated". However, this current situation doesn't garantee:

• That 52 FNs is big enough in all cases (high Imm Ass load, hence queue size)
• That 52 FNs is a good starting poing if there's no load at all. Can it be lower? (counting delays of PCUIF, Um/AGCH scheduling, etc.)

The idea to improve this situation would be to make this AGCH_START_OFFSET be low enough for 0 load on the BTS (empty AGCH queue), and then monitor the AGCH of the BTS from the PCU somehow in order to be able to predict (with certain margin) the extra amounf of delay to add to AGCH_START_OFFSET.

Related previous commits improving the situation:

commit 2f59e673ebe06e159d2a6bf685edf88d62446eaa
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date:   Mon Mar 29 12:13:13 2021 +0200

    Pick unreserved UL FN when allocating an SBA

    Make sure an unreserved FN is picked and reserved when allocating and
    scheduling an SBA.
    In practice this has no change in behavior right now, since anyway using
    an offset of 52 FNs ensure no USF or POLL has alredy been scheduled that
    far in the future. Since it's also impossible to allocate more than 1
    SBA per PDCH and RTS FN, we are also safe about multiple SBAs being
    allocated, because we use a hardcoded offset of 52.
    However, that could change in the future, when we dynamically tweak the
    current offset of 52 FN based on information from BTS about its AGCH
    queue load:
    * If load is high, we may need to increase the offset since it
    will take more time for the BTS to transmit the TBF and hence we must
    reserve a TBF starting time further in the future (higher FN).
    * If load turns low, we may schedule next SBA a bit more nearby in time
      than the previously allocated SBA, hence here there could be a
      collision.

    Related: OS#5020
    Change-Id: I2d4e21e2307de6c17748e8da5c7e149c947a7eb9

commit 8238739a745c6064e3b84619f21a98c21010e4b8
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date:   Fri Mar 26 20:44:48 2021 +0100

    sba: Document AGCH_START_OFFSET after some experimental tests

    Related: OS#5020
    Change-Id: Id1460207be25750aeb5c1d7af2fac6591cf5e424

diff --git a/src/sba.c b/src/sba.c
index 2c3519d..4b878b7 100644
--- a/src/sba.c
+++ b/src/sba.c
@@ -33,8 +33,24 @@
 #include "pdch.h" 
 #include "pdch_ul_controller.h" 

-/* starting time for assigning single slot
- * This offset must be a multiple of 13. */
+/* TBF Starting Time for assigning SBA.
+ * See TS 44.060 12.21 "Starting Frame Number Description".
+ * According to spec, k=0 (offset=4) "should not be used, so as to leave time
+ * for the MS to analyse the message and get ready to receive or transmit".
+ * Hence, k=1 (offset=8-9) is hteoretically the minimum offset which could be
+ * used.
+ *
+ * However, it was found, empirically, that it takes around 30-40 FNs time for
+ * the Immediate Assignment message created with this "TBF Starting Time" to
+ * travel from PCU->BTS and be transmitted over CCCH on the Um interface. Hence,
+ * we must account for this delay here, otherwise the MS would be receiving eg.
+ * a TBF Starting Time of FN=40 while the Imm Assigned containing it is sent in
+ * eg. FN=50, which would be too late for the MS to answer to it.
+ *
+ * The situation described above, can even get worse on high BTS load for AGCH,
+ * since the Immediate Assignment will queue in the BTS waiting to be
+ * transmitted one after the other, hence increasing the required delay.
+ */
 #define AGCH_START_OFFSET 52