Age | Commit message (Collapse) | Author | Files | Lines |
|
In addition to logging the current values of a BTS's channel load
average and T3122 override, maintain stat items for these values.
This allows for plotting these values over time, for instance.
These values show up in the VTY under 'show stats' like this:
base transceiver station:
Channel load average.: 25 %
T3122 IMMEDIATE ASSIGNMENT REJECT wait indicator.: 32 s
Change-Id: Icace0176e8b1d23d7c7b4816f7c67c65312844fa
Suggested-by: laforge
|
|
Change-Id: I806b957b7f6fbbb1206d29ceeccd401c98c26990
|
|
The IMMEDIATE ASSIGN REJECT message contains a wait indicator which
tells an MS requesting a channel to wait for a specified amount of
time before trying to request a channel again, i.e. the wait indicator
controls the T3122 timeout value in the MS.
Previously, the wait indicator was fixed to 10 seconds.
This is not sufficient if there are a lot of MS requesting channels
because the MS will retry too soon. Instead of using a fixed value,
maintain a dynamic wait indicator value based on average channel load.
The load (used vs. available channels on a BTS) is sampled once per
second, and once 8 samples have been collected we update a BTS-specific
T3122 wait indicator based on the measured load.
While the wait indicator could go up to 255 seconds, this initial
implementation keeps it in the range from 10 to 128 seconds.
Further experimentation and testing will show whether higher wait
indicator values are desirable, if the sampling rate needs to change,
or if the function mapping the load measurement to a wait indicator
value should change (currently we map the load average linearly into
the range [10, 128] inclusive).
Change-Id: I57e38f6d6ba3b23cc6e1f9520b90261dbb1f1cec
Related: OS#2592
|
|
This member was merely a cache for conn->lchan->ts->trx->bts,
so let's avoid having to keep copies of the same data (which needs
to be kept up to date).
Change-Id: Id3bff8b18425ef5d45eb460ac9eb620023013ba0
|
|
This penalty timer is used to temporarily block cells where handover
or assignment failed or where handover is not allowed. This is usefull
to prevent repeated handover attempts to broken cells or cells that have
limited allowed distance.
Change-Id: I95cb7e3211b2470b773965e7aa94d8eb6c8c1a3a
|
|
Add ho_dtap_cache to gsm_subscriber_connection, a stock msgb queue to be used
with msgb_enqueue() and msgb_dequeue().
Keep a counter of queue length, to enforce a sane maximum counter for cached
messages. So far a hardcoded maximum of 23 messages will be cached.
Have balanced ho_dtap_cache_add() and ho_dtap_cache_flush() functions.
The original patch was by jolly, but I have basically completely replaced it
with the simpler msgb queue pattern.
Change-Id: I6e4d93628befb3d97e5cee0343cd9f8ba0b8620c
|
|
Change-Id: Ie746f76433f6b46a71a91b7714cc034c4355d993
|
|
This is needed for handover algorithm to balance free slots and to prevent
congestion of one cell, while other cells still have free capacities.
Change-Id: Ic8bee8a515ee8aa9a99af71756fe60b8dd8f868b
|
|
Change-Id: I8811ee8a75be09048042b511ee4bd9bc1de63976
|
|
Change-Id: I224884c84895ebf6c8cf498c16616214cb2b5779
|
|
If we want to average over up to 10 measurement reports (as configurable
at VTY), we need a history of at least 10 measurements.
Change-Id: Ia7cfac073bdc464092ca3e51dec319ac30401dd1
|
|
Change-Id: Iaf99d4e9ae08c38bf364dbb37d42098f976f6b8c
|
|
Change-Id: I465caef03626e67d9b3a21bdf730589b9852c211
|
|
Change-Id: I3471e38327c4b98490faed9b604fb76438ba9954
|
|
get_meas_rep_avg will return -EINVAL, if the required number of
measurements are not reached. There will be no handover possible until the
given number of measurements are available.
Change-Id: Ibc4410b4e162cdb6c070128d2c63946bb79d6d65
|
|
In order to keep processing power at BTS at a defined level, the handover
decision might want to limit maximum number of slots that require RACH
detection.
Change-Id: I8908e37fe0d8d2eda906cc6301ba0969b25a5575
|
|
It is desirable to allow configuring handover for each individual network cell.
At the same time, it is desirable to set global defaults.
Treat the 'network' node handover parameters as global defaults, add another
set of parameters for each individual BTS.
This raises questions on how the 'network' node should affect the individual
BTS. The simplistic solution would have been: on creating a BTS in the config,
just copy the current defaults; with serious drawbacks:
- tweaking any parameter in the telnet VTY on network node will never affect
any running BTS.
- network node defaults *must* be issued before the bts sections in the config
file.
- when writing a config back to file, we would copy all net node defaults to
each BTS node, making the network node configs pointless.
Instead, add a handover_cfg API that tracks whether a given node has a value
set or not. A bts node ho_cfg gets a pointer to the network node config and
returns those values if locally unset. If no value is set on any node, use the
"factory" defaults, which are hardcoded in the API. Only write back exactly
those config items that were actually issued in a config file / on the telnet
VTY. (ho_cfg API wise, we could trivially add another ho_cfg level per TRX if
we so desire in the future.)
Implement ho parameters as an opaque config struct with getters and setters to
ensure the tracking is always heeded. Opaqueness dictates allocating instead of
direct embedding in gsm_network and gsm_bts structs, ctx is gsm_net / bts.
This is 100% backwards compatible to
old configs.
- No VTY command syntax changes (only the online help).
- If a 'bts' sets nothing, it will use the 'network' defaults.
- The 'show network' output only changes in presence of individual BTS configs.
On 'show network', say "Handover: On|Off" as before, iff all BTS reflect
identical behavior. Otherwise, output BTS counts of handover being enabled or
not.
Use the same set of VTY commands (same VTY cmd syntax as before) on network and
BTS nodes, i.e. don't duplicate VTY code. From the current vty->node, figure
out which ho_cfg to modify.
For linking, add handover_cfg.c (the value API) in libcommon, while the
handover_vty.c is in libbsc. This is mainly because some utility programs use
gsm_network and hence suck in the ho stuff, but don't need the VTY commands.
Review the VTY online help strings.
Add VTY transcript test for handover options, testing config propagation from
network to bts nodes, 'show network' output and VTY online help strings.
(Needs recent addition of '... !' wildcard to osmo_interact_common.py.)
I considered leaving parts of this more readable, but in the end decided for
heavy use of macros to define and declare the API, because more values will be
added in upcoming patches and I want to prevent myself from messing them up.
Inspired-by: jolly/new_handover branch, which moves the config to 'bts' level
Depends: I7c1ebb2e7f059047903a53de26a0ec1ce7fa9b98 (osmo-python-tests)
Change-Id: I79d35f6d3c0fbee67904378ad7f216df34fde79a
|
|
Do not instruct the MGW to move the RTP to the new lchan before we have
received a HANDOVER DETECT.
Before:
Chan Activ
Chan Activ Ack
IPACC-CRCX
-ACK
IPACC-MDCX
-ACK
MGCP MDCX --> MGW
...
HANDOVER DETECT
Call continues on new lchan
In above sequence, if the HANDOVER DETECT times out, the MGW has moved to the
new lchan which never becomes used and is released. Furthermore, from the IPACC
MDCX until the HANDOVER DETECT, the RTP stream would break off momentarily.
After:
Chan Activ
Chan Activ Ack
IPACC-CRCX
-ACK
IPACC-MDCX
-ACK
...
HANDOVER DETECT
MGCP MDCX --> MGW
Call continues on new lchan
If the HANDOVER DETECT times out, the call happily continues on the old lchan.
This change is inspired by Ivan Kluchnikov's HO work, who implemented a similar
fix in the openbsc.git codebase (branch fairwaves/master-rebase): his patch
moves ipacc_mdcx() to connect RTP to the new lchan from switch_for_handover()
(which triggered on S_ABISIP_CRCX_ACK, i.e. creation of the new lchan) to later
on in ho_detect() a.k.a. the S_LCHAN_HANDOVER_DETECT signal handler:
http://git.osmocom.org/openbsc/commit/?h=fairwaves/master-rebase&id=9507a7a1ea627e07370c9d264816bb190b3b91b8
This patch does essentially the same: remove the mgcp_handover() call from the
MDCX-ACK handling (creation of the new lchan), and add a signal handler for
S_LCHAN_HANDOVER_DETECT to osmo_bsc_mgcp.c to effect the MGW switchover.
Note, it would have been possible to call mgcp_handover() directly from rx of
the HANDOVER DETECT message, but that produces linking fallout in some utils/
projects, which then need to link the mgcp code as well. That is because those
aren't properly separated from the more complex parts of libbsc. Using the
signal is a bit bloaty, but saves the linking hell for now. I've faced a
similar problem twice recently, it would pay off to separate out the simpler
utils/ and ipaccess/ tools so that they don't need to link all of libbsc and
osmo-bsc, at some point (TM).
Change-Id: Iec58c5fcc5697f1775da7ec0111135108ed1fc8f
|
|
A subsequent patch will add registration of a signal; cosmetically prepare by
creating a common mgcp_init() function. It makes sense for the FSM registration
to move to it.
Change-Id: I510e1081171706eb3d9fb2db50a9aa4f768929b5
|
|
We can now either page an invidual BTS directly or page several BTS in a
given location area. This decision is taken based on the contents of the
cell identifier list in the paging request. Select a set of BTS for paging
while processing the cell identifier list, rather than requiring the
paging layer to loop over all BTS in the MSC.
This change requires some adjustment in bssap_test. In particular,
this test must now add a BTS to its network in order to pass.
The purpose of this change is to make the layering a bit cleaner.
There is one functional change: We no longer abort paging if paging fails
for a particular BTS. Instead, we keep trying to page on other BTS.
Change-Id: Ic1c72c7f83e53988eb9fedf314b1dc459836833d
Suggested-by: Harald Welte
Depends: Ic7772e75c3d7fb0df6e17e118bb33b3248352d4d
Related: OS#2753
|
|
The stow-enabled jenkins builds are currently failing like below:
make[3]: Entering directory '/build/src/libcommon'
CC bsc_version.o
CC common_vty.o
CC debug.o
CC gsm_data.o
In file included from debug.c:34:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
In file included from common_vty.c:27:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
In file included from gsm_data.c:37:0:
../../include/osmocom/bsc/gsm_data.h:15:38: fatal error: osmocom/sigtran/sccp_sap.h: No such file or directory
#include <osmocom/sigtran/sccp_sap.h>
^
compilation terminated.
Let's make sure the common gsm_data.h have all required CFLAGS to compile.
Change-Id: I30b75db6ffba227b05b5413b84b15f69e0c213f2
|
|
This builds upon https://gerrit.osmocom.org/#/c/5698/ which implements
support for paging by LAI.
The ttcn3 test TC_paging_imsi_nochan_ci passes with this code when
run in isolation. It does not pass if another paging test (such as
TC_paging_imsi_nochan_lai) is executed beforehand. This problem
looks similar to the scenario tested in TC_paging_imsi_a_reset.
Change-Id: Ic7772e75c3d7fb0df6e17e118bb33b3248352d4d
Depends: Ic3c62ff0fccea586794ea4b3c275a0685cc9326e
Related: OS#2753
|
|
This change removes a few USSD specific declarations, which are
not actually used now, and probably accidentally migrated from
legacy OpenBSC.
Change-Id: I060223349971a7fce169a018bf16eb91f0e20342
|
|
This is a common include guard way for Osmocom projects.
Change-Id: Iee73e24a2438b6081a5d569db7d48725b564ee3a
|
|
Add a new control command 'msc.N.connection_status' which can be used
to query the connection status of a particular MSC with number N.
Keep the old control command 'msc_connection_status', which always
queries MSC 0, for backwards compatibility.
Change-Id: Ibd41474a1be80e782b19ec337c856b5efc593fa8
Related: OS#2729
|
|
T3109 is started when the BSS sends a RR CHAN REL to the MS and stops
downlink SACCH generation. Stopped when the MS successfully releases the
LAPDm link. After stop or timeout, the radio channel is released using
RSL RF CHAN REL.
Recommended values in literature are 1-2s + RadioLinkTimeout*0.48s or
5s, while we had the absurdly high 19s timeout. This means we occupy
the radio channel way longer than needed in situations where the MS is
no longer able to properly release Layer2 (LAPDm DISC) due to loss of
signal or the like.
See also: https://osmocom.org/projects/osmobsc/wiki/Timers
Change-Id: I7416b4118e5b73c6ffb98e3546bc62a36c7a967a
Closes: OS#2734
|
|
This is a new inline function that hides all accesses to conn->bts.
A follow-up patch will then point this to conn->lchan->ts->trx->bts
to get rid of the bts field.
Change-Id: Ib6cf7097ced34eebe80441c29ab1534f21956a33
|
|
when a transaction to the MGW times out, then the context
information is freed. Unfortunately the client is not informed
about this and will try to execute the callback anyway.
explicitly cancel the transaction in order to prevent access
to already freed data structures.
Change-Id: I40794dff7d10e2b6a96863a2da7e9fbd5662a1bf
|
|
This field was used in write-pnly mode, i.e. set but never read.
Change-Id: I319945538fd3e3bc5cf3b9d82533641cb8ba5256
|
|
Change-Id: I429fe7817f075d0794645d37f5ea11b104102ba0
|
|
This clarifies which members of the struct are for what.
Change-Id: I618822e6f2d48adce25f9df5c25acbce7c858412
|
|
Change-Id: I674ed61a22fad5cc09c45128dbc73474893aefb6
|
|
Change-Id: Ibc4b8f3776c35df7e81252efb78ec740a371de7f
|
|
libosmo-sccp is the old sccp-lite-focused SCCP implementation that we
used before libosmo-sigtran was created. The new osmo-bsc in this
repository is using libosmo-sigtran and shouldn't be using parts of
libosmo-sccp anymore.
We only keep it around in configure.ac and Makefile.am for osmo-bsc_nat,
which is not even built in this repository anymore (or 'again yet'?)
Change-Id: I8f274be7d196cd7a5b1ec9ada949130fb06e984d
|
|
Change-Id: I919bffe88babd90227c89abd4434322965c32ebb
|
|
The network name and other MM INFO is controlled by the MSC, not the BSC.
Change-Id: I1cbf72fc50cff29e7c1633ba752cbf15b4b84c58
|
|
The LU reject cause (like anything MM related) is under control of
OsmoMSC, not BSC.
Change-Id: I559ae31d67726845c9699c8b6127e21c6f63ace6
|
|
RRLP is handled in OsmoMSC after the split from NITB, so let's remove
any bogus VTY commands left over in the BSC.
Change-Id: Ib626f43a3a3ca69dfc127afe5832eb58f7fb6a38
|
|
There still is a lot of dead code that we inherited from the NITB
days, let's remove more of it.
libtrau will be re-introduced as part of osmo-mgw later.
Change-Id: I8e0af56a158f25a4f1384d667c03eb20e72df5b8
|
|
Those NACKs shouldn't happen in production, and if they do, you probably
want to have a more persistent figure than a line in the log file about
it. Having counters allows the user to monitor this efficiently.
Change-Id: Ic82c6baaf4cb88d07bc5cdc200f8279cf130f396
|
|
Those NACKs (CRCX/MDCX/PDCH_ACT) shouldn't happen in production, and
if they do, you probably want to have a more persistent figure than
a line in the log file about it. Having counters allows the user
to monitor this efficiently.
Change-Id: I5edf979c9a2b4c9a5a60eef9f66c26da54f2bddf
|
|
Change-Id: I268f222140fa5783e1d19f81fbd45614aaa4b8c4
|
|
Change-Id: I471b598af194dee78ebaa3414b6290c72d9bbcff
|
|
Our T3113 timer default of 60s was set early in the development of
OpenBSC, where we didn't really know what values to use and used
excessively large/safe values. Paging the same MS for 60 seconds (even
if there's no paging response) will however create a lot of PCH load for
no good reason.
It seems there's no clear guidance as to what the value should be. Other
implementations use something in the order of 10 seconds (OpenBTS,
yateBTS), which seems more realistic. THe Siemens BS-11 has a default of
5 seconds.
Let's be conservative and go to 10s as a default, which is already 6
times less potential PCH usage than our default so far...
Closes: OS#2756
Change-Id: If9c8441939c6fdcf6e2b9ede8cc576eb86296209
|
|
Counting the number of T3113 expirations (one per subscriber per BTS)
vs the number of paging attempts (Bsc global) is a ueseless figure,
as you cannot relate each other.
We count on the BSC level:
* how many PAGING we received from the MSC (total)
* how many of those were for cells/LACs we don't serve
* how many of those resulted in PAGING RESPONSE
We count on the BTS leve:
* how many PAGING CMD we sent to the BTS (total)
* how many of those we ignored as we were already paging
* how many of those resulted in PAGING RESPONSE
* how many were expired due to T3113 expiring
Change-Id: I410bbcbb2621f95f11238f7a5da01ab438f5fee1
|
|
Make the comments for struct mgcp_ctx more expressive
Change-Id: Ie80b4915055e3f944ff1870c38e3609197ab72b2
|
|
According to the spec it's an empty 1-byte element reserved for future
extension but we still have to generate padding properly. Add stub
function similar to the used for SI2ter and adjust test output
accordingly.
Related: OS#2711
Change-Id: I3c278c57880a173df3c4648c9724339d23ce94fd
|
|
When the MSC has lost its state and issues a RESET, we should not only
clear all ongoing radio connections, but we should also stop any paging.
There's no point in paging a subscriber if the MSC doesn't know about
this paging anymore.
Change-Id: If3f53d3bb66ad2dc02db823cb813590c6b59c700
Closes: OS#2736
|
|
The call-back was needed inside the NITB to determine which part (CC,
SMS, ...) had triggered a given paging. A pure BSC doesn't need that
feature, so let's get rid of it.
The 'void *cbfn_data' is replaced with a 'struct bsc_msc_data *', as
all callers use it with that type.
Change-Id: I8839e8338d3ad1a91b41e687e8412fcdca3fd9ab
|
|
This timer is started when a channel is allocated with an IMMEDIATE
ASSIGNMENT message. It is stopped when the MS has correctly seized the
channel. Ever since the early days of development we were using a very
long timeout to be on the safe side. However, in production networks
this is a terrible waste of resources, as we will occupy 10s worth
of air-time on one of our channels for each RACH request we receive.
The only scenarios where you might need something absurdly high as 10s
would be if you have 8s of RTT between your BTS and the BSC.
See also https://osmocom.org/projects/osmobsc/wiki/Timers
Change-Id: If3c52a7cf0c06d074c44a2fc414679279189aab9
Closes: OS#2733
|