| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* the return value of bsc_update_timers() is required for applications to find out if a timer was fired
(Andreas Eversberg)
|
|
CCCH load indications
|
|
somewhat of an overlap
with the signals, but I think paging always has one reason and thus one caller wants to
get notified about completion, including a caller-specific context, etc)
* introduce TLV parser definitions for GSM 04.08
* parse and generate BCD number IE's for 04.08 call control
|
|
some different ideas)
* introduce new notion of subsystem in addition to signal number
* no need for bitmasks of 'areas' (aka subsystems)
* pass subsystem/signal_nr/... per argument rather than by data structure
|
|
This is removing a memleak, saving some mallocs and a crash
in the timer expired function that attempted to remove the
paging_request from a list it was not in....
|
|
move_to_next is using the last_request but we do not have
one... but we know the list is not empty so just pick the
first entry.
|
|
Remove the parameter and move the signal kind into the
signal struct. Make register/deregister fully symmetric.
|
|
When the paging request timed out, send a signal... lchan
is NULL in case of a failure.
|
|
Send up to available_slots paging requests but only
iterate over the list once. This was not tested on
a bts.
|
|
|
|
|
|
Kill the paging timer and send paging upon paging load notifications.
|
|
|
|
support
We do have a dispose timer, there is no need to discard the
paging request this way... remove the code.
|
|
* use a new timer that stops paging requests after some time, rather than
sending them indefinitely
|
|
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.
|
|
|
|
Mostly cosmetic and in preparation for proper page load indicator
handling.
|
|
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)
|
|
Update the last_request when stopping the paging operation and also
free the associated memory of the request.
|
|
|
|
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...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Currently we get OVERLOAD (8.6.3 of 08.58) and no CCCH LOAD INDICATION...
we will have to handle the OVERLOAD somehow...
|
|
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.
|
