Start with a large number of available slots. It is guranteed
that we will - at some point - get a paging load and will properly
update the counter and keep it updated.
There is a 1:1 relationship between gsm_bts and the paging
operation. Move the paging state into the gsm_bts which is
simplfying the code a lot. This was hinted by LaF0rge.
(I'm not happy with the names of the structs)
In our setup (1xCCCH combined, BS_AG_BLKS_RES=0,
BS_PA_MFRMS=0x3 -> 5) we have MAX(1,3-0) * 5 paging
sub-channels. Using this 15 I was able to successfully page
my phone/IMSI (934%15 -> 4).
My confusion is coming from the terms used for paging throughout
the documentation. GSM05.02 6.5.2 talks about "N = number of
paging blocks 'available' on one CCCH = (number of paging blocks
'available' in a 51-multiframe on one CCCH)xBS_PA_MFRMS" which
is already misguiding and GSM04.08 is talking about number of
different paging subchannels on the CCCH and is providing a
formula.
I deduct that N == number of different paging subchannels on the CCCH
as of GSM04.08 and will simply test this with different IMSIs and
see if I can page them as well.
- The paging block calculation is wrong but I have a hard time finding
the right information. The table of 05.02 (Table 5 of 9) looks good
but my phone is not happy with that group...
Wrote and test code to add and remove paging requests... This
will be using the fact that the linux list is building a circle
on each tick we can send one/x paging requests and continue round
robin...
You can request to open a channel to a MS and the paging layer
will call you once the channel is allocated. Internally the CCCH
Load Indication will be handled and retry to page a terminal.
Holger Freyther
Harald Welte