Commit Graph

7653 Commits

Author SHA1 Message Date
Pau Espin 8831160631 Revert "update neighbor ARFCNs on startup and config changes"
This patch caused major breakage in my setup, with BSC printing at
startup: "(bts=0,trx=0) Failed to generate System Information".

And bts-trx printing all the time:
"sysinfo.c:162 PH-RTS-IND: Unable to determine actual BS_AG_BLKS_RES
value as SI3 is not available yet, fallback to 1"

This reverts commit c1a5310a3e.

Change-Id: I5da365c93aedc6668a77b82ee9b68cbec64967e3
2021-04-23 13:38:58 +02:00
Neels Hofmeyr c1a5310a3e update neighbor ARFCNs on startup and config changes
The effects of the neighbor configuration depend on the LAC, Cell
Identity, ARFCN, BSIC configuration of neighbor cells. Make sure that
the neighbor ARFCN list in the System Information is updated.

This may seem rather aggressive: updating the SI of all BTS if only one
config item changed. But indeed even modifying one config item of one
BTS may cause a change in the neighbor relations that many other BTS may
have to the changed BTS. For example, if many BTS configure a
'neighbor lac-ci 42 23', and this cell's config changes to LAC 43, all
of those other BTS need to update their neighbor ARFCNs.

Also update the system information even before the BTS are connected and
started up. The main benefit here is that the VTY 'show bts N' command
then already lists the correct neighbor ARFCNs.

In gsm_bts_trx_set_system_infos(), make sure that the updated SI is only
sent to TRXes that are actually usable, otherwise abis_rsl_sendmsg()
spams the log with complaints that a message's dst == NULL. Still return
an error rc in case a TRX is not connected, so that the CTRL command
bts.N.send-new-system-informations accurately returns whether SI were
actually sent to all TRXes.

The desire to have the ARFCNs listed in the VTY before starting up BTSes
came during analysis for Ifb54d9a91e9bca032c721f12c873c6216733e7b1,
which fixes a bug that is now much easier to verify being fixed.

Change-Id: I2222e029fc225152e124ed1e8887f1ffd4a107ef
2021-04-22 18:50:32 +00:00
Pau Espin 5bc54d6ce8 Send EUTRAN neighs based on whether Common Id msg contained Last used E-UTRAN PLMN ID
From 3GPP TS 48.008 sec 3.1.30 "Common ID":
"""
If the SCCP connection is established due to CSFB from E-UTRAN and the MSC supports
return to the last used PLMN after CS fallback, then it should send the COMMON ID message
to the BSS including the Last used E-UTRAN PLMN ID information element if available at
the MSC immediately following the successful SCCP connection setup.
"""

Furthermore, 3GPP TS 48.008 version 16.0.0 Release 16 "3.2.1.21 CLEAR COMMAND",
for field CSFB Indication, states:
"""
NOTE: This information element doesn't serve any useful purpose. MSCs should not send the
information element unless it is required by the recipients (due to the need to interwork
with older versions of the protocol). It is expected that in future versions of the present
document, this information element will be deleted from this message.
"""

Hence, build up the EUTRAN neighbor list based on whether we received
the Last E-UTRAN PLMN ID IE during Common Id. In the future, we should
probably filter the list while populating it based on the received IE.

This change will also allow reusing same mechanism for SRVCC
EUTRAN->GERAN support, where te Last E-UTRAN PLMN ID IE can be found
inside "Old BSS to New BSS information" IE in msg HANDOVER REQUEST.

Related: SYS#5337
Change-Id: I5d290ac55eca5adde1c33396422f4c10b83c03d5
2021-04-19 12:12:31 +02:00
Neels Hofmeyr 6be9e42a1d fix wrong ARFCNs in local-cell neighbor config
For neighbors configured without explicit ARFCN+BSIC ('neighbor bts N',
'neighbor lac-ci N M', ...), actually use the local neighbor cell's
ARFCN.

So far the code looked correct on first sight, but passed an unused part
of the struct neighbor union, always resulting in ARFCN 0.

Related: SYS#5367
Change-Id: Ifb54d9a91e9bca032c721f12c873c6216733e7b1
2021-04-18 16:23:20 +02:00
Pau Espin da6dae0daa bssap: pass whole tlv_parsed to event GSCON_EV_A_COMMON_ID_IND
This change will allow handling more IEs in the future, like
"Last used E-UTRAN PLMN ID" one.

Related: SYS#5337
Change-Id: I96a0e1a7491fabf7aaad62207886821ad6194927
2021-04-15 16:36:23 +02:00
Pau Espin 00ae402627 cosmetic: Fix typo in func description
Change-Id: I26cd31bc3e127cba17be508d10a5fd3cf6498901
2021-04-15 16:36:23 +02:00
Neels Hofmeyr 446e3c7869 deprecation: use osmo_bts_features_*()
For "reported feature '%s'...", use the short feature name, which better
matches the message.

Change-Id: Ie09506fbf3a1f0e899f9f4c8070e3139fd1d5e9d
2021-04-14 17:40:45 +00:00
Neels Hofmeyr defb5b1200 drop unused gsm_bts_trx->description
Change-Id: I3c0778322b8c630b0eb9d9cd3ac3cc71386c9c12
2021-04-14 17:40:45 +00:00
Neels Hofmeyr 14f9860e79 drop unused func decl rsl_lchan_mark_broken()
Change-Id: Ib08e69720e2b9a6ea5f5b5d13baa9920c415f078
2021-04-14 17:40:45 +00:00
Vadim Yanitskiy d51d96c99c Replace all references to 'sysmobts' with 'osmo-bts'
sysmoBTS is a BTS model sold by Sysmocom, which runs osmo-bts.
The later may also work with some other back-ends, including
the genaral purpose SDR hardware.  Therefore, it's more
logical to call it 'osmo-bts'.

Change-Id: I93ab4dbf483e0786c35685b75ee4ea83bd591f7b
2021-04-12 18:54:40 +00:00
Vadim Yanitskiy 3fd19268ae vty: deprecate BTS type 'sysmobts' in favor of 'osmo-bts'
Change-Id: I60d5ff887a7c830180088904c2458f7e73ce3893
2021-04-12 18:54:40 +00:00
Alexander Chemeris e9a44fdedd stats: Count transitions from BORKEN state due to LCHAN_EV_TS_ERROR signal.
Change-Id: Ice3379020039dc3634aa3887939740729d720dee
2021-04-12 17:56:55 +00:00
Vadim Yanitskiy cd622e0f5f [hopping] bootstrap_rsl(): do not call generate_ma_for_ts() again
It's already being called in inp_sig_cb(), once the A-bis/OML link
is established.  There is no need to do this on the A-bis/RSL link
establishment again.

Change-Id: I435018f439181cdd046ca99fe7e01ac85e226cce
2021-04-12 12:17:40 +00:00
Vadim Yanitskiy 6a8536d4da [hopping] Rework generation of Cell/Mobile Allocation
Calculating the Cell Allocation (basically a bit-vector of all the
frequencies allocated to a cell) on the OML link establishment has
several downsides and potential problems:

  * Theoretically, more than 64 ARFCNs can be allocated for a cell
    via the VTY interface.  The problem here is that the Mobile
    Allocation IE cannot contain more than 64 channels.

  * The BSC's operator will neither be warned by the interactive
    VTY shell during configuration, nor during the startup.

  * The BSC will accept such a configuration, but then will be
    unable to encode the Mobile Allocation IEs at run-time.

This change aims to improve the situation by separating part of
the logic from generate_cell_chan_list(), and invoking this
part directly from the VTY commands.  This way it will become
impossible to configure more than 64 ARFCNs, neither via the
config file, nor interactively from the VTY.

Change-Id: I98211fb0684a973239f5760e1de52a24a1f4c33c
2021-04-12 12:17:40 +00:00
Neels Hofmeyr 711ac95c26 fixup for neighbor config for coverity
Check against NULL pointers to allow only resolving local or only remote
neighbors in resolve_neighbors(). (Though no caller exists currently
that would need this feature, it is trivial and more future-safe.)

Related: CID#220459 CID#220460
Change-Id: I8c2046335ec6f8a5d6b757446c98d8e630ee015f
2021-04-08 21:12:49 +00:00
Vadim Yanitskiy 2fbdc7c5de abis_nm: cosmetic: use osmo_bts_feature_name()
Change-Id: I15078ac030b0b824a554239b19bc501c624e2a87
2021-04-07 16:41:22 +00:00
Vadim Yanitskiy 23c1c975c0 abis_nm: rework warnings about unknown / not supported features
The reported feature vector may contain new features the BSC is
not aware of.  Report each of them individually as NOTICE.

It's normal when some BTS feature is considered as not supported
by the BSC, but a BTS reports that it is - do not log this.

Change-Id: I2f925bcdb010cb10d074bf7c82619e3ae1f8818b
2021-04-07 16:41:22 +00:00
Vadim Yanitskiy 2b07628949 [hopping] generate_ma_for_ts() returns no meaningful value
Change-Id: Ic3ba3323459bba1336adb1f902cb2371edea1f71
2021-04-06 04:38:28 +02:00
Vadim Yanitskiy d63690e473 [hopping] gsm48_send_rr_ass_cmd(): use Cell Channel Description from SI1
Calling generate_cell_chan_list() on each Assignment Command is
quite expensive, because this function basically re-constructs
the Cell Allocation (using bitvec API) and the Frequency List
from scratch.  This IE can be borrowed from pre-calculated
SI1 message, so let's do this.

Change-Id: I9c8c5ae9059ff096765412b3f3c7181a94163afc
2021-04-06 04:38:28 +02:00
Vadim Yanitskiy b77c5eb0bc [hopping] generate_cell_chan_list(): make some pointers const
Change-Id: Ied4ee60224d71567ec613942ba1c03088e9b02f3
2021-04-06 04:38:28 +02:00
Vadim Yanitskiy e2034e0283 [hopping] vty: ensure no duplicate hopping ARFCN entries
Change-Id: Ie27c859e3f16ada08a5cdc8ab4ac6e20a885a378
2021-04-06 04:15:45 +02:00
Neels Hofmeyr 45c72350b3 debug log, lchan_fsm: explain leaving wait_rll_rtp_establish state
Before, it is not clear whether the RTP is already done setting up or
the RTP is skipped entirely. This log message clarifies that.

Change-Id: I18ffcf93e82ee47413e4b2f741ffbfbb18322e1d
2021-04-04 16:20:34 +00:00
Keith Whyte 1823f89c1e Ignore CHANnel ReQuireD with Access Delay IE > 63
It is observed that a CHANnel ReQuireD with access delay
greater than 63 can be received from the Ericsson RBS.
This results in osmo-bsc sending back a CHANnel ACTIVation with
a Timing Advance IE containing the access delay value.
The RBS NACKs this, leading to a BORKEN Channel.

This patch makes the maximum acceptable access delay vty-configurable
and Ignores CHANnel ReQuireD RSL Messages with Access Delay IE greater
than that configured. Default value is 63.

Related: OS#5096
Change-Id: Ie8987bcc0e43921bc753162b77a0efc68799b3ce
2021-04-04 15:39:53 +02:00
Neels Hofmeyr 764449ec2e fix/refactor neighbor config
The neighbor configuration storage is fundamentally broken: it requires
all local cells to be configured before being able to list them as
neighbors of each other. Upon config write-back, the neighbor config
however is placed back inline with the other config, and hence a
written-out neighbor config no longer works on program restart.

The cause of this problem is that the config is stored as explicit
pointers between local cells (struct gsm_bts), which of course requires
the pointer to exist before being able to reference it.

Instead, store the actual configuration that the user entered as-is,
without pointers or references to objects that need to be ready. Resolve
the neighbors every time a neighbor is needed.

Hence the user may enter any config at any place in the config file,
even non-working config (like a BTS number that doesn't exist), and the
relation to actual local or remote neighbor cells is made at runtime.

Abort program startup if the initial neighbor configuration contains
errors.

Related: OS#5018
Change-Id: I9ed992f8bfff888b3933733c0576f92d50f2625b
2021-03-24 21:22:21 +01:00
Neels Hofmeyr dc60505bc5 drop neighbor_ident_test.c
This tests the opaquely designed neighbor config storage. However, a
subsequent patch will refactor the neighbor config storage, and this
neighbor ident API will change fundamentally. No need to test this.

The new storage will use the usual scheme of transparent struct and
llist, the opaque design is not necessary and just bloats. There is no
need to test a plain llist, so this test needs no replacement.

Related: OS#5018
Change-Id: I6522796bf0bbb9ab83e49168bcbff7bc70fd6c6d
2021-03-24 10:02:29 +01:00
Neels Hofmeyr d88f9a5384 refactor handover penalty timers
So far the list of penalty timers was stored for an opaque target
pointer. That was either a gsm_bts pointer for a local BTS, or a cell
identifier list pointer for a remote-BSS cell.

Reasons to refactor penalty timers:

- The cell identifier list pointer came from the neighbor configuration
  storage, but the way cell neighbor config is stored will change in a
  subsequent patch. There will be no more cell identifier lists there.

- Storing object pointers is inherently unsafe -- if an object gets
  removed and another gets allocated, the penalty timer could
  theoretically remain in force for an unrelated object.

Rather store penalty timers for specific Cell IDs. Since remote-BSS
neighbors can be requested by a cell identifier *list*, use a
gsm0808_cell_id_list2 as key in the list of penalty timers.

Fix handover_test.c: have different CI for each local BTS. So far it was
the same LAC+CI for all BTSes, which now would make the test fail,
because any penalty timer would appear to apply to all local cells.

Related: OS#5018
Change-Id: I72dd6226a6d69c3f653a3174c6f55bf4eecc6885
2021-03-24 10:02:29 +01:00
Oliver Smith 3ac1278dcf stats: T3122 related: num_values 16 -> 60
Increase the number of values saved in the FIFO from 16 to 60, so there
is more time to read them out.

Related: SYS#4877
Change-Id: Ic5fd7c0fa030004fd88fee74f0028fb93c9f2d10
2021-03-17 16:21:21 +01:00
Javi 2d168bd1d7 Add command to enable RX diversity to RBS2000
Allow selection of RX diversity from VTY
Options are a,ab,b
Default is 'a' so there is no change from previous behavior

Change-Id: I430762b8cfa51060841d90ba4446de73bd557c6c
2021-03-15 18:50:32 +00:00
Javi 0a3913ee71 Add vty command for Ericsson RBS2000 sync
This commit adds support for Selection of syncronization source.
Options are internal for E1 and external for GPS

Change-Id: Ia3d1acd6b3442238b35fc911092e12a6ac989adb
2021-03-13 07:43:17 +01:00
Harald Welte 0ed69da597 remove obsolete dependency on libosmo-sccp
We only use libosmo-sigtran these days, so we can remove the depdency
to the old libosmo-sccp from osmo-bsc.  We don't use LIBOSMO_SCCP_*
variables in any Makefile.am, nor do we #include <osmocom/sccp/...>
anywhere [anymore].

Change-Id: Ie478016ffb6e767ba10968c1ee2ab98db15a45a3
Related: OS#2601
2021-02-23 20:18:50 +01:00
Pau Espin 6505f692d4 Bump version: 1.6.0.558-f5d07-dirty → 1.7.0
Change-Id: I0afcb06f8a7466f98cac26ff939a3813d4add1cc
2021-02-23 18:43:04 +01:00
Harald Welte f5d0733e44 CBSP: document rate counters and their mapping to basic/extended CBCH
Change-Id: Id298d547a90bb5d8e40f2cd300b7e1303bb43fdc
2021-02-22 13:44:32 +00:00
Vadim Yanitskiy 3991ae5b87 abis_nm: enrich debug messages with contextual info
Change-Id: I68f64e6cae061a49733c4885ba383d2b9b4cfca9
2021-02-20 23:24:09 +01:00
Pau Espin 679eeca824 tests: Replace deprecated API log_set_print_filename
Change-Id: I4e0eb8842333c89d15fb6728a34716ea1eb4935d
2021-02-20 17:14:49 +00:00
Pau Espin f25a45abea tests: Explicitly drop category from log
Let's disable category here since we don't care about its formatting here.

In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.

Change-Id: I4d48c0c0aa46065560a020369e3b0544385f173e
Related: OS#5034
2021-02-20 17:14:49 +00:00
Keith Whyte e4b52dff39 Disallow changing the type of an existing BTS from the vty
Changing the BTS type is not supported, so don't allow it.

For example, Changing from type sysmobts to type rbs2000
may hit an OSMO_ASSERT in om2k_bts_fsm_alloc()

The default BTS type if osmo-bsc is started with an empty
configuration and the operator issues config terminal->network->bts 0
will be "unknown". This type and only this type can be
changed from the vty config node.

Change-Id: I0df97ef128a1bbd84c787654d1d842dce4dad819
2021-02-19 08:29:32 +01:00
Pau Espin Pedrol cdbd7e3bf2 SI13: Enable sending GPRS Cell Options Extension Information on GPRS-only BTS
The EGPRS bits are anyway conditionally enabled by egprs_supported.

Change-Id: Ie7a438419eb416ce3d29794febab5f952661e5c5
2021-02-18 00:56:13 +00:00
Michael Iedema 456a962c7e stats: add SIGN/SPEECH assignment subcategories
Change-Id: I73f4dab6edb0951180f2bbcfc352ff34de647679
2021-02-17 15:13:25 +00:00
Pau Espin Pedrol 0cfed38f07 Fix neigh resolution service on local neighbours
Change-Id: I217e3550aa6d7f3c3cab4e545641d790ae12b23f
Related: SYS#4909
2021-02-13 08:15:01 +00:00
Pau Espin Pedrol a27e8a5c9a Move bts_ident_key to neighbor_ident.c
The function is not really handover specific, and will be used in other
places in subsequent patches.

Change-Id: Icae8b9045e497f850f22cb3b6f93acbf61b84746
2021-02-13 08:15:01 +00:00
Philipp Maier ff5dcf7fd3 bts.adoc: describe ACCH repetition settings
The manual currently does not mention ACCH repetition yet. Lets
add some info on how to set up ACCH repetition correctly.

Change-Id: I1e27ac955882497bbeefac0c830708dd18ad46b3
Related: SYS#5114
2021-02-11 23:16:50 +01:00
Philipp Maier a2f21b3bc4 bsc_vty: mark repeat rxqual 4 (BER >= 1.6) as default
Change-Id: Iecc2395efab703cf3de8f8e16b9e4bc8c8baf260
Related: SYS#5114
2021-02-11 12:45:36 +01:00
Pau Espin Pedrol d01bc3e4c7 Introduce VTY cmd to configure Alpha in SI13
Related: SYS#5358
Change-Id: I8b97ea11bad5fe05f2f634945b5703ee9abde81d
2021-02-09 13:31:48 +01:00
Harald Welte c72c853a96 hide the "smscb-command" vty command; people should use osmo-cbc
Many years prior to the implementation of osmo-cbc, we introduced
a way how raw RSL SMSCB COMMANMD can be injected from the VTY.

These days, people should use the CBSP interface with osmo-cbc or any
other CBC.  We should not advertise the VTY command hack
as a standard feature anymore.

Change-Id: If5ddc3db989763a1f47d4cbc026e293e3134d8ef
Related: OS#4753
2021-02-08 17:21:20 +00:00
Vadim Yanitskiy ea8d6939e6 power_control: make P_CON_INTERVAL parameter configurable
Change-Id: I6e0fae81cc60f708e49d5eb8dfc0bbcad926b18f
Related: SYS#4918
2021-02-07 19:20:12 +01:00
Vadim Yanitskiy e1d2691e69 power_control: enable Uplink DPC by default if format is known
So far osmo-bsc would enable Uplink DPC (Dynamic Power Control) only
for osmo-bts, and the 'static' mode for all other BTS models.  This
decision dates back to the time when ip.access specific encoding for
dynamic power control parameters was not implemented, and the MS
Power Parameters IE was sent empty in the RSL messages.

Let's make a step forward by enabling Uplink DPC by default for
all BTS models which declare the API for vendor-specific encoding
of the power control parameters.  Currently this includes osmo-bts
and nanoBTS, both supporting ip.access specific format.

Change-Id: If86d27d4332af3d82f862737340d061e42e34eba
Related: SYS#4918
2021-02-07 04:38:15 +01:00
Vadim Yanitskiy d5a03a59b0 power_control: check BTS model in cfg_power_ctrl_avg_osmo_ewma()
Change-Id: I1c454f447d37cbc4d44b242dc4b2c62297ee3f67
Related: SYS#4918
2021-02-06 20:19:38 +01:00
Neels Hofmeyr b03e73f27b lchan activation: indicate whether TA is known
On lchan activation, we already know the Timing Advance in most
situations: from the Channel Request RACH, or from a previous lchan in
the same cell. Place this information in lchan->activate.info.ta.

So far, the lchan->last_ta (until recently called rqd_ta) was used to
store the initial TA for channel activation -- move the initial TA to
lchan->activate.info.ta, for proper scoping.

Only an inter-cell handover does not yet know a Timing Advance (until
the Handover Detection RACH is received), so indicate
activate.info.ta_known = false for that case.

If ta_known is false, do not include an Access Delay IE in the Channel
Activation message, ensuring that the BTS does not use an arbitrary TA
that is likely inaccurate.

The effect for OsmoBTS is that we will *not* start the downlink SACCH on
channel activation for inter-cell handover, but will wait for a HO RACH
first, and then use the correct TA when enabling downlink SACCH.

Related: OS#4008 SYS#5192
Change-Id: I986bf93e8acd6aef7eaf63ac962480b680aa894f
2021-02-05 20:24:43 +01:00
Neels Hofmeyr 980a28fdcb rename lchan->rqd_ta to last_ta
Originally, the lchan stored only the Timing Advance from the initial
channel request, hence it was called rqd_ta.

Since quite a while now, rqd_ta also stores the most recent Timing
Advance from each received Measurement Report. So rename to last_ta.

This is cosmetic preparation for an upcoming patch that clarifies
whether the Timing Advance is already known for Channel Activation.

Change-Id: I1049526a173819baeb4978db5bf018ba3f1006a0
2021-02-05 20:24:43 +01:00
Neels Hofmeyr 71b1bc4964 lchan assignment when RTP is set up: don't break on Mode Modify
Change-Id: I06d3f35fcc71d77e1f30c2b15ab221ef7d5f7f27
2021-02-05 20:24:40 +01:00