aboutsummaryrefslogtreecommitdiffstats
path: root/src/libbsc/bsc_init.c
AgeCommit message (Collapse)AuthorFilesLines
2018-05-27move 'extern struct gsm_network *bsc_gsmnet" to header fileHarald Welte1-4/+1
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
2018-05-10dyn TS: init only when both RSL and the Channel OM are establishedNeels Hofmeyr1-1/+3
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
2018-05-05dyn ts, bts_ipaccess_nanobts.c: init PDCH on Chan OPSTART ACKNeels Hofmeyr1-1/+0
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
2018-04-13fix handling of state changes in acc rampingStefan Sperling1-1/+3
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
2018-04-11ensure that acc_ramp_init() is only called onceStefan Sperling1-3/+6
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
2018-04-09fix initialization of acc rampingStefan Sperling1-10/+4
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
2018-04-07Start Dynamic PDCH Initialization after RSL is upHarald Welte1-1/+3
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
2018-03-07implement support for 3-digit MNC with leading zerosNeels Hofmeyr1-3/+4
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
2018-03-05cosmetic: bsc_network_init(): imply default 001-01 PLMNNeels Hofmeyr1-1/+1
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
2018-02-27Add support for Access Control Class ramping.Stefan Sperling1-1/+14
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
2018-02-05Make "waiting indicator" of IMMEDIATE ASSIGN REJECT dynamic.Stefan Sperling1-0/+2
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
2017-12-19Remove bogus MM INFO configurationHarald Welte1-3/+0
The network name and other MM INFO is controlled by the MSC, not the BSC. Change-Id: I1cbf72fc50cff29e7c1633ba752cbf15b4b84c58
2017-12-19Remove dead code left over from NITB splitHarald Welte1-2/+2
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
2017-12-09Move many counters from BSC-global to per-BTS granularityHarald Welte1-2/+2
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
2017-11-29auth: remove obsolete VTY commandsPhilipp Maier1-8/+0
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
2017-11-21bsc_init: fix Werror: define rc for 2quater with si2q_count == 0Neels Hofmeyr1-0/+1
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
2017-10-11ctrl: add oml-uptime commandMax1-0/+20
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
2017-10-09OML: consider RSL link stateMax1-0/+1
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
2017-09-25Further cleanup leftovers from BSC/MSC splitMax1-1/+0
* drop unused header * fix name of jenkins test * remove dead code Change-Id: I986904864741995910b6ba92173b9f7b1b03e2f1
2017-09-06move include/openbsc to include/osmocom/bscNeels Hofmeyr1-14/+14
Change-Id: I39e7b882caa98334636d19ccd104fd83d07d5055
2017-08-30split off osmo-bsc: remove files, apply buildNeels Hofmeyr1-1/+0
Change-Id: I64d84c52f6e38e98144eb9be8f0ab82e0e1f6cca
2017-08-27gsm_bts_trx_set_system_infos(): Disable non-existing SIHarald Welte1-6/+17
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
2017-08-27Fix regression causing loss of static system-information messagesHarald Welte1-2/+2
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
2017-08-27Fix BTS attribute requestsMax1-2/+2
* 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
2017-08-27Implement IuCS (large refactoring and addition)Neels Hofmeyr1-6/+0
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
2017-08-27SI3: indicate R99+ MSC to GSM MS to enable UMTS AKANeels Hofmeyr1-0/+3
Change-Id: I796e1f4281628061f4522c43c549de9e751bc045
2017-08-27Use libvlr in libmsc (large refactoring)Harald Welte1-0/+7
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
2017-08-27move openbsc/* to repos rootNeels Hofmeyr1-0/+552
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