Age | Commit message (Collapse) | Author | Files | Lines |
|
Add some code to count TCH/H and TCH/F and also handle
the neci bit of the network. Our channel allocator will
allocate a TCH/F if we request a TCH/H but can not allocate it.
|
|
Only page if we have a load that is acceptable for paging. This
option is off by default, and can be enabled per bts. The idea
is that when we have no resources right now we will not page as
it will only create more RACHs and increase the load.
|
|
Instead of throwing a huge pile of paging commands to the BTS
we will submit one paging command every half second. This way
we can have different messages between the paging commands.
|
|
Make sure the paging timer is restarted after giving some credit
and send out paging requests.
|
|
|
|
This is a band aid and not a proper fix. Reduce the time between two
IPA commands even if it is breaking rugby sized BTSs, limit the paging
commands we send during one iteration through the event loop. This should
prevent us from killing ourselves in a RACH loop.
|
|
It might be that we run down to zero available slots but the BTS
might not send us a load indication. This can happen if we think
we send paging requests and the BTS disagrees and considers them
as errors and does not count the paging message.
When we drop to zero we will start a credit timer to give us extra
credit after six seconds, if we get a CCCH load indication before
we will stop the timer.
|
|
Conflicts:
openbsc/include/openbsc/abis_rsl.h
openbsc/include/openbsc/mgcp.h
openbsc/src/abis_rsl.c
openbsc/src/chan_alloc.c
openbsc/src/handover_logic.c
openbsc/src/mgcp/mgcp_network.c
openbsc/src/vty/command.c
openbsc/src/vty_interface.c
|
|
Implement a method to count the number of pending paging requests
per bts and print it on the VTY. This helps to see how big the
backlog of requests is for a given BTS.
|
|
paging.c:259: warning: implicit declaration of function ‘trx_is_usable’
|
|
The value 20 is just a random number and it really depends
on the number of TRX on a bts to be a sane or insane limit.
|
|
|
|
The current code was overly complex. It tried to iterate over
the list in a round robin and we had to keep track of the last
element, see if we remove that one, check if the list becomes
empty... This can all replaced by treating the double linked
list as a queue. We take the item at the front, do something
on it and then and then put it back to the list at the end.
|
|
On the nanoBTS we do not receive any load indication for the
paging channel and we just decrement our available slots and
the unsigned int wraps to the maximum value. Together with a
not yet understood bug this makes us go amock.
For the nanoBTS and even the Siemens BS11 resetting the load
to 20 after two seconds should be just fine. For the nanoBTS
we would need to reset the 20 a lot more earlier but we need
to take a look at how often we run low.
|
|
The value 20 is just a random number and it really depends
on the number of TRX on a bts to be a sane or insane limit.
|
|
|
|
The current code was overly complex. It tried to iterate over
the list in a round robin and we had to keep track of the last
element, see if we remove that one, check if the list becomes
empty... This can all replaced by treating the double linked
list as a queue. We take the item at the front, do something
on it and then and then put it back to the list at the end.
|
|
|
|
On the nanoBTS we do not receive any load indication for the
paging channel and we just decrement our available slots and
the unsigned int wraps to the maximum value. Together with a
not yet understood bug this makes us go amock.
For the nanoBTS and even the Siemens BS11 resetting the load
to 20 after two seconds should be just fine. For the nanoBTS
we would need to reset the 20 a lot more earlier but we need
to take a look at how often we run low.
|
|
Increment the counter before we call the remove request
which is freeing the request...
|
|
Increment the counter before we call the remove request
which is freeing the request...
|
|
Send a Paging Request to the BTS every two seconds. This way it is
unlikely that a phone will try to respond to two paging requests as
it is currently happening.
|
|
* Move to libosmocore
* Move to new debugging architecture
* Register the BTS types
* Has only been compile tested
Conflicts:
openbsc/include/openbsc/Makefile.am
openbsc/include/openbsc/gsm_data.h
openbsc/include/openbsc/ipaccess.h
openbsc/include/openbsc/mgcp.h
openbsc/include/openbsc/msgb.h
openbsc/include/openbsc/tlv.h
openbsc/src/Makefile.am
openbsc/src/abis_rsl.c
openbsc/src/bsc_init.c
openbsc/src/bsc_mgcp.c
openbsc/src/chan_alloc.c
openbsc/src/debug.c
openbsc/src/gsm_subscriber_base.c
openbsc/src/msgb.c
openbsc/src/rest_octets.c
openbsc/src/sccp/sccp.c
openbsc/src/vty/command.c
openbsc/src/vty_interface.c
openbsc/tests/Makefile.am
|
|
This library is intended to collect all generic/common funcitionality
of all Osmocom.org projects, including OpenBSC but also OsmocomBB
The library currently includes the following modules:
bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer,
tlv_parse, linuxlist
msgb allocation error debugging had to be temporarily disabled as it depends on
'debug.c' functionality which at the moment remains in OpenBSC
|
|
Send a Paging Request to the BTS every two seconds. This way it is
unlikely that a phone will try to respond to two paging requests as
it is currently happening.
|
|
This is useful information to know and actually fixes a segfault
in rllp.c where lchan is accessed even tough it could be NULL in
case of failure.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
|
|
this ensures we don't send paging requests to currently inactive transceivers.
|
|
This has the advantage that counters can be added all over the code
very easily, while having only one routine that stores all of the
current counter values to the database. The counters are synced
every 60 seconds, providing relatively fine grained statistics
about the network usage as time passes by.
|
|
the statistics will give us some idea about the network load and
performance.
|
|
Before this commit, OpenBSC used templates for the SYSTEM INFO
1, 2, 3, 4, 5 and 6 messages. Those templates were patched in
various places to reflect the network config like ARFCN.
Now, we actually generate those SI messages ourselves, using
values from the configuration file, and even calculating neighbor
cell lists.
All bts'es that you have configured in OpenBSC will end up in
the neighbor cell list - which should be more than sufficient for
the current small-single-site networks.
|
|
Add it to the configuration files and make use
of it in the the paging.c.
|
|
Not doing this could lead to a double deletion due the paging
request being removed during the callback and afterwards as
well. Change the code to save the callback data, remove the
request, do the callback.
A patch was proposed by Andreas Eversberg and this one is
based on it.
|
|
This loop looks a lot like the one inside the paging code. Call
it instead and change the code in paging_request_stop to cope
with a NULL _bts.
|
|
|
|
Try to page by IMSI when the TMSI is not set. This will be required
to properly support the MSC/BSSMAP.
|
|
tmsi is four octets long, there is no need to make it a string
and then jump through hoops to convert it to a number. Keep the database
using it as a string to benefit from the NULL handling of the db.
Introduce the reserved tmsi which has all bits set to 1 according
to GSM 03.03 §2.4 and start checking for it and make sure the db
code will never allocate such a tmsi.
|
|
Prefix generate_mid_from_tmsi with a gsm48_, create a new method
to binary encode the imsi. Add a unit test for parsing and decoding.
The implementation can parse the data it generated and the
last octet seems to be filled with the end mark.
|
|
|
|
this helps the caller to determine if he will ever get called back
or not (and if he should free his data structures now or not)
|
|
|
|
this enables the caller to detect if the paging request was rejected
by the paging layer, especially in case it is already paging this very
subscriber.
In the case of SMS / 04.11, we used to have a memory leak of struct gsm_sms's,
since we would only free them from the paging succeeded/expired callbacks.
|
|
the various constructors get called in a non-obvious, linker determined
order, which makes certain objects disappear from the talloc report.
This change moves the talloc context creation into a new talloc_ctx.c file
|
|
The existing code always paged for a TCH/F, which is really wasteful
when considering the delivery of SMS messages.
Also, increase the verbosity of the debug message a bit.
|
|
this task is performed by the paging.c code already.
|
|
This is much more optimal than checking if the context exists every
time we allocate the respective object.
|
|
|
|
|
|
This is Harald's reworked MNCC base, slowly heading towards integration
into master. The key changes are:
* provide much more structure to the data in gsm_mncc
* encode_* and decode_* functions now take a structure rather than tons
of individual arguments (whose order nobody can remember)
* make sure we don't have copies of the same code everywhere by introducing
mncc_set_cause() and mncc_release_ind()
* save horizontal screen space if possible
* make sure we break lines > 80 characters
|
|
Reuqests for a subscriber a stored within the gsm_subscriber
datastructure and it will keep track how many channels are
allocated for this user and of which type to decide on policy...
e.g. attempt to submit SMS during a phone call and not doing
paging but a simple (immediate) assignment of the channel...
|
|
By calling _paging_request_stop with NULL for the lchan we
have never used the paging complete callback... I didn't
spot that when moving the code over and thought it is a great
simplification to not call paging_request_stop first and then
loop... *sigh*
restore the old behaviour. Call the callback first and then
free the requests.
|