On Wed, May 04, 2016 at 02:37:26PM +0200, Holger Freyther wrote:

I don't think this belongs into the gsm_subscriber. If you compare this with the architectural change that removed the "subscriber queue" we are going to repeat the same mistake again. The timeout belongs into the logical "operation" and not the subscriber (the object of the logical operation).

I must admit that I haven't fully grokked the master branch aka NITB paging semantics. I've just taken a closer look. It's quite complex...

Here is how the paging_timeout ended up in gsm_subscriber:

First I wanted to add the paging timeout to a gsm_subscriber_connection, which obviously doesn't make sense. There is no conn yet when we want to page.

The next thought would be to add the timeout to struct subscr_request. But taking a look at subscr_request_conn(), I see that gsm_subscriber has an is_paging flag, and when a request comes along while we're already paging, it is just added to the list without launching another paging [1]. So it seems there is a paging semantic that is separate from the request, that's why is_paging is in gsm_subscriber I presume, and that's why I put the paging timeout next to that, but read on.

[1] see subscr_request_conn() on sysmocom/iu, or subscr_request_channel() on master

Now I understand that the libbsc paging is much more than just one paging request. There's the bts->paging.work_timer that keeps retrying to page as long as requests exist. It rotates every first request to the back and does another paging; I don't really understand the part where the "available slots" of 20 are reduced to zero, where the paging_give_credit() is queued with a separate timeout, which sets the slots back to 20 (20 credits??). Nevertheless, I understand now that is_paging is not about a single paging, but remembers whether we can skip kicking off the cascade of paging retries. Then there's the separate req->T3113 timer which separately removes each request from the list of requests waiting for a paging.

I could re-implement this kind of algorithm in libmsc:

* Upon first request, start paging * Retry paging "indefinitely" while requests are queued ("paging worker") * Upon second or later request, just add to the queue * Time out each request separately * Stop paging once the queue of requests is empty

The current status quo is somewhat simpler:

* Upon first request, send out a single paging request * Upon second or later request, add to the queue * If the single paging timed out, discard all requests

If I re-implement the more complex algorithm like in libbsc, I would need a paging worker in the gsm_subscriber struct, and a timeout per each subscr_request.

OTOH, if the BSC level already has the paging-retries semantics built-in, then it makes sense to send out only a single paging request from the MSC level.

It's not as clear cut. osmo-bsc receives a paging request from the MSC, and does numerous paging retries. But it doesn't store the requests in detail, it even has the request callbacks set to NULL. All that happens during a paging response is that a connection to the MSC is initiated. So the knowledge for various detailed requests is in the MSC, while the paging retries still are in osmo-bsc.

So it's not trivial to figure out how the various levels should behave. The MSC should not have the same paging resend logic as the BSC, or if it does then with a much longer timeout.

It would be interesting to find out whether RNCs resend pagings like our osmo-bsc.

I would appreciate opinions on how standalone MSC level paging should behave in detail.

Also, could someone please explain the 20 slots and "give credit" semantics I mentioned above?

~Neels