Cellular Network Infrastructure » Radio Access Network » OsmoBSC

I added BSC_Tests.TC_paging_500req which checks that osmo-bsc schedules paging requests to the BTS quick enough if the BTS allows for it.
Other scenarios are in general already handled by other TC_paging_* tests.

In this patch I schedule several (up to 20) paging requests every 500ms:
https://gerrit.osmocom.org/c/osmo-bsc/+/27885
It was tested on the field and seems to be fixing SYS#5922.

I have been thinking about implementing such a "dynamic timer timeout scaling", and I'm not sure we can improve this further "easily".
I don't thnk we can reliably set a T3113 based on load, since we have 2 levels of request buffering here, the one at the BTS and the one at the BSC. Furthermore, the current load doesn't really tell much information about the future state, only about the current state, which is not that useful to calculate the time required in the future.

As an example, the BSC queue is empty and we receive a burst with a lot of pagings from the MSC: At this point the BSC queue becomes loaded (lots of requests pending), but that doesn't necessarily mean the first requests will require a lot of time to be answered/timeout, because there may not be other requests already scheduled in the BTS beforehand.

I think current approach after all my recent patches (https://gerrit.osmocom.org/c/osmo-bsc/+/27946/ and prev) is actually kind of doing that:
Our T3113 actually just stores a buffer of time big enough to handle several retransmissions (taking into account network configuration). Since we allow retransmissions every 500ms, this means basically the BTS CCH LoadInd driven queue + BSC scheduling of 10 requests every 250 ms will already throttle effectively the amount of retransmissions submitted based on load.

So in summary, if PCH load at the BTS/BSC is lower, then the paging request will have more chances to be retransmitted quicker (hence more times) over the T3113 period of time. If there's more load, that paging request will have to fight against other requests in the queue to be scheduled for retransmission, hence autocontrolling the load of paging requests to be transmitted in the PCH.

While it's true it's difficult to account for the entire time the request will need, we can at least estimate the time according to current BSC queue, so I'm working on adding that now. This is useful if for instance a burs tof lots of requests arrive at a given point in time: The laters will take a lot more time to be scheduled, so we have to increment T3113 there, otherwise they will be dropped too quickly without even reaching the BTS.

https://gerrit.osmocom.org/c/osmo-bsc/+/27965 paging: Increase T3113 based on paging group load in BSC queue

Also related:
https://gerrit.osmocom.org/c/osmo-bsc/+/28002/

All patches have been merged. We can close the ticket.