Age | Commit message (Collapse) | Author | Files | Lines |
|
It's not a good idea to keep extern declarations copied over
half a dozen C files. Let's move it to a header.
Change-Id: I6f643f1393ba0955d9c0cf1cf78d5c604e7b9451
|
|
Recent Icf6e25ff068e8a2600562d52726ead65e864ec02 changed the dyn_ts_init() hook
from bootstrap_rsl() to the Channel OPSTART ACK, but this is not sufficient.
Now RBS2k never calls dyn_ts_init(), and we may need to wait for RSL:
Dyn TS should actually be initialized only when *both* OML opstart and RSL link
are established. To that end, introduce a generalized API to query OML and RSL
status and to trigger a timeslot init at the appropriate time.
Add gsm_ts_check_init() to be called both when RSL and OML opstart are
established: trigger gsm_ts_init() only when both are given.
Add gsm_bts_trx_ts->initialized flag to mark whether initialization has already
taken place. Add gsm_bts_mark_all_ts_uninitialized() to conveniently clear this
flag for all TS in a BTS.
Add gsm_bts_model.oml_is_ts_ready() callback so that each BTS implementation
can return the OML status of a timeslot in its own OML implementation.
Actually, currently all BTS models that need this init mechanism store the TS'
OML status in ts->mo.nm_state. While we would in practice correctly init dyn TS
by just looking at ts->mo.nm_state, semantically, the decision whether the TS
is ready is up to the BTS models' specific OML implementations.
From bootstrap_rsl(), call gsm_ts_check_init(), in case the TS OML Opstart has
happened before RSL is established -- applies to all BTS models.
For all BTS models:
- call gsm_{bts,trx}_mark_all_ts_uninitialized() when OM is torn down, to make
sure the TS init mechanism will work a second time.
For all BTS models supporting dyn TS, i.e. osmo-bts, nanobts and RBS2k:
- implement oml_is_ts_ready().
- call gsm_ts_check_init() when a Channel OM is taken into operation.
Any BTS models that don't set oml_is_ts_ready() will see a ts init as soon as
RSL is bootstrapped (incidentally, the old dyn TS behavior before recent
Icf6e25ff068e8a2600562d52726ead65e864ec02).
This firstly fixes dyn TS for RBS2k by re-adding the initial switch to PDCH,
and furthermore does so only after both OML TS opstart and RSL are through.
This fixes the ttcn3-bsc-tests around dyn TS, since for the osmo-bts-virtual,
the RSL is established only after OML opstart on the TS, which was broken by
Icf6e25ff068e8a2600562d52726ead65e864ec02.
Nokia Site and Siemens BS11 practically do not require this init mechanism,
since all that happens there so far is dyn TS init, and these BTS models do not
support dyn TS of any kind. A future patch may add oml_is_ts_ready().
Related: OS#3205
Change-Id: I99f29d2ba079f6f4b77f0af12d9784588d2f56b3
|
|
Sending PDCH activation upon RSL bootstrap is too early. Introduce OPSTART ACK
handling to call dyn_ts_init() only when the dynamic timeslot is indeed ready
to receive a PDCH activation.
Related: OS#3205
Change-Id: Icf6e25ff068e8a2600562d52726ead65e864ec02
|
|
Take both the operative and administrative states into account
when deciding whether to start ACC ramping, and examine old/new
state values to avoid triggering ramping for a no-op state change.
This requires a fix to gsm_trx_lock_rf(): This function overwrote
the old administrative state of a trx before enqueuing a state
change request towards the BTS.
The BTS will confirm this request with an ACK, at which time a
signal is generated which the ACC ramp code listens to. We must
not overwrite the old state value until the signal has been handled,
otherwise the signal handler cannot tell what the old state was.
Tested with a virtphy setup, nanobts, and osmo-bts.
Change-Id: Ib3291439655598fb5ddc891a3e4cc35b0bad250f
Related: OS#2591
|
|
There are plans to register signal handlers in acc_ramp_init(). Once we
do that, the acc_ramp_init() function should only be called once to
avoid duplicate signal handlers on the handler list.
However, the acc_ramp_init() function currently serves a dual-purpose:
1) Initialize the acc_ramp structure for a bts
2) Enable or disable ACC ramping
Add new functions to support use case 2, and call acc_ramp_init()
just once while reading the configuration file. The VTY commands
which enable/disable ACC ramping use the new APIs instead.
Also, rename acc_ramp_start() to acc_ramp_trigger() and tweak its
semantics so that it can always be called regardless of what the
current configuration settings are. This prepares us for triggering
ACC ramping upon events other than "RSL link-up".
Change-Id: Ia25bff85d9e5c277da76bffa11d31972e9fdc323
Related: OS2591
|
|
Remove a redundant call to acc_ramp_init() during bootstrap_bts().
ACC ramping state is already initialized during VTY config parsing,
and bootstrap_bts() accidentally disabled ACC ramping again even
if it was enabled in the configuration.
This bug was introduced in last-minute refactoring during
review of https://gerrit.osmocom.org/#/c/6324/ when the
acc_ramping_enabled flag was moved from struct gsm_bts to
the acc_ramp structure itself.
Also remove an acc_ramp_init() call in bootstrap_rsl().
It is no longer needed as it serves no purpose other than
initializing the bitmasks of barred ACCs. To ensure that
ACC ramping configuration provided to the BTS via system
information stays correct, we move the call to acc_ramp_start(),
which has the same effect on barred ACCs, further up.
Change-Id: Ib7d99c9d3d5d424e21bb7710f719c42f9aef3e95
Fixes: 6442e4327b1100ecfed7a242e397ac37b7529bea
Related: OS#2591
|
|
We used to start the dynamic PDCH initialization right after the
respective OML initialization of the related timeslot. However, this
is problematic as the RSL link may very well not even be up yet at
that point. So let's do this at RSL link esetablishment time, not
from OML.
Change-Id: I8ac30ca075a1db4b624dc38a423d844d705fda7e
Closes: OS#1841
|
|
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
The changes to abis_test and gsm0408_test show that this code now handles
3-digit MNC correctly, by not dropping the leading zero as 0xf in the encoded
PLMN.
Re-implement CTRL commands 'mcc', 'mnc' and 'mcc-mnc-apply' to preserve the
presence of the third digit of the MNC. Always reply with all leading zeros.
Adjust the expected results in ctrl_test_runner.py, to show that it works.
In VTY and CTRL, the parsing of MCC and MNC is inherently made stricter by use
of osmo_{mcc,mnc}_from_str() -- they will no longer allow surplus characters
and detect errno returned by strtol() (in contrast to atoi()).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore),
I020a4f11791c61742a3d795f782805f7b7e8733e (libosmocore)
Change-Id: I8e722103344186fde118b26d8353db95a4581daa
|
|
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ic16bc0bab3f2d4721e86a1a04f9d9f988d777df2
|
|
Access Control Class (ACC) ramping is used to slowly make the cell
available to an increasing number of MS. This avoids overload at
startup time in cases where a lot of MS would discover the new
cell and try to connect to it all at once.
Ramping behaviour can be configured with new VTY commands:
[no] access-control-class-ramping
access-control-class-ramping-step-interval (<30-600>|dynamic)
access-control-class-ramping-step-size (<1-10>)
(The minimum and maximum values for these parameters are hard-coded,
but could be changed if they are found to be inadequate.)
The VTY command 'show bts' has been extended to display the
current ACC ramping configuration.
By default, ACC ramping is disabled.
When enabled, the default behaviour is to enable one ACC per
ramping step with a 'dynamic' step interval. This means the
ramping interval (time between steps) is scaled to the channel
load average of the BTS, i.e. the number of used vs. available
channels measured over a certain amount of time.
Below is an example of debug log output with ACC ramping enabled,
while many 'mobile' programs are concurrently trying to connect
to the network via an osmo-bts-virtual BTS. Initially, all ACCs
are barred, and then only one class is allowed. Then the current
BTS channel load average is consulted for scheduling the next
ramping step. While the channel load average is low, ramping
proceeds faster, and while it is is high, ramping proceeds slower:
(bts=0) ACC RAMP: barring Access Control Class 0
(bts=0) ACC RAMP: barring Access Control Class 1
(bts=0) ACC RAMP: barring Access Control Class 2
(bts=0) ACC RAMP: barring Access Control Class 3
(bts=0) ACC RAMP: barring Access Control Class 4
(bts=0) ACC RAMP: barring Access Control Class 5
(bts=0) ACC RAMP: barring Access Control Class 6
(bts=0) ACC RAMP: barring Access Control Class 7
(bts=0) ACC RAMP: barring Access Control Class 8
(bts=0) ACC RAMP: barring Access Control Class 9
(bts=0) ACC RAMP: allowing Access Control Class 0
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 1
(bts=0) ACC RAMP: step interval set to 354 seconds based on 59% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 2
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
(bts=0) ACC RAMP: allowing Access Control Class 3
(bts=0) ACC RAMP: step interval set to 30 seconds based on 0% channel load average
Change-Id: I0a5ac3a08f992f326435944f17e0a9171911afb0
Related: OS#2591
|
|
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
|
|
The network name and other MM INFO is controlled by the MSC, not the BSC.
Change-Id: I1cbf72fc50cff29e7c1633ba752cbf15b4b84c58
|
|
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
|
|
We used to have a lot of counters only globlly per BSC, but they're
much more useful on a per-BTS level.
Change-Id: I954b9dda72b83b91d46a934c221a8b3375743599
|
|
Authentication is no longer done in the BSC, the variables that
set the authentication policy and the IMSI regex have no longer
any effect.
Remove auth policy and authorized-regexp
Change-Id: Ie31b921b5fd0af5501ec0c77c0f08089c10075e2
|
|
src/libbsc/bsc_init.c: In function ‘rsl_si’:
src/libbsc/bsc_init.c:153:2: error: ‘rc’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return rc;
^
Change-Id: Iedad1efcb477c77db8c741777ea076761658c7d1
|
|
Expose OML link uptime available via vts's "sh bts 0" command with the
new "bts.0.oml-uptime" ctrl command. To avoid code duplication, move
uptime computation into separate function and use it for both.
Change-Id: Iec405aa949d6a38a9c8e64cd7ee4b49fd416835d
Related: OS#2486
|
|
OML link state is available via vty ("sh bts 0" command) and
ctrl ("oml-connection-state" RO variable).
When showing OML link state, take into consideration RSL link state as
well: if OML is up but RSL is missing show it as degraded.
That's implemented via BTS model-specific functions (currently Sysmo- and
Nano- BTS only)
Change-Id: I5952fc59e4d82e0aa627ad91d20f964d9559a4c4
Related: OS#2486
|
|
* drop unused header
* fix name of jenkins test
* remove dead code
Change-Id: I986904864741995910b6ba92173b9f7b1b03e2f1
|
|
Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
|
|
Change-Id: I64d84c52f6e38e98144eb9be8f0ab82e0e1f6cca
|
|
If we previously had a given SI present/active, we must send a
zero-length BCCH FILLING for that SI type to the BTS to stop it from
further transmitting this SI.
Change-Id: I33e356e2fa3a69efac9080813e3e9ef4e6438ed1
Closes: OS#2368
|
|
In commit 8b1a2f8cd7a81c6b8c7cdb0963dcf89de7c46100 we started to
initialize bts->si_valid to 0. This means we are skipping the manually
configured static system information.
Instead, we have to initialize bts->si_valid to bts->si_mode_static,
i.e. start with those that are static and not to be auto-generated.
Found while developing
http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo
Change-Id: Iab9cc93cf6d54560a72cc393cc3721a8d10e04bf
Closes: #2367
|
|
* fix BTS numbers: use 0 to indicate given BTS and 0xFF to indicate all
BTS' as it's explained in 3GPP TS 52.021 §9.3.
* only request attributes from supported (OsmoBTS) types
Change-Id: I8f43055c38000248033a8ff9ddaf0910d68d794b
Related: OS#2317
|
|
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw
Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.
Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
|
|
Change-Id: I796e1f4281628061f4522c43c549de9e751bc045
|
|
Original libvlr code is by Harald Welte <laforge@gnumonks.org>,
polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>.
This is a long series of trial-and-error development collapsed in one patch.
This may be split in smaller commits if reviewers prefer that. If we can keep
it as one, we have saved ourselves the additional separation work.
SMS:
The SQL based lookup of SMS for attached subscribers no longer works since the
SQL database no longer has the subscriber data. Replace with a round-robin on
the SMS recipient MSISDNs paired with a VLR subscriber RAM lookup whether the
subscriber is currently attached.
If there are many SMS for not-attached subscribers in the SMS database, this
will become inefficient: a DB hit returns a pending SMS, the RAM lookup will
reveal that the subscriber is not attached, after which the DB is hit for the
next SMS. It would become more efficient e.g. by having an MSISDN based hash
list for the VLR subscribers and by marking non-attached SMS recipients in the
SMS database so that they can be excluded with the SQL query already.
There is a sanity limit to do at most 100 db hits per attempt to find a pending
SMS. So if there are more than 100 stored SMS waiting for their recipients to
actually attach to the MSC, it may take more than one SMS queue trigger to
deliver SMS for subscribers that are actually attached.
This is not very beautiful, but is merely intended to carry us over to a time
when we have a proper separate SMSC entity.
Introduce gsm_subscriber_connection ref-counting in libmsc.
Remove/Disable VTY and CTRL commands to create subscribers, which is now a task
of the OsmoHLR. Adjust the python tests accordingly.
Remove VTY cmd subscriber-keep-in-ram.
Use OSMO_GSUP_PORT = 4222 instead of 2222. See
I4222e21686c823985be8ff1f16b1182be8ad6175.
So far use the LAC from conn->bts, will be replaced by conn->lac in
Id3705236350d5f69e447046b0a764bbabc3d493c.
Related: OS#1592 OS#1974
Change-Id: I639544a6cdda77a3aafc4e3446a55393f60e4050
|
|
This is the first step in creating this repository from the legacy openbsc.git.
Like all other Osmocom repositories, keep the autoconf and automake files in
the repository root. openbsc.git has been the sole exception, which ends now.
Change-Id: I9c6f2a448d9cb1cc088cf1cf6918b69d7e69b4e7
|