This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn 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
--
- Neels Hofmeyr <nhofmeyr at sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschäftsführer / Managing Directors: Holger Freyther, Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20160506/492ebaaf/attachment.bin>