Choose SBA allocation offset based on AGCH queue load in the BTS
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.
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.
- 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 <email@example.com> 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 <firstname.lastname@example.org> 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