Project

General

Profile

Feature #1946

Add checks to the BSC VTY to prevent configurations known to not work

Added by neels over 1 year ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
sysmocom
Category:
-
Target version:
-
Start date:
02/08/2017
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,
similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),
and so on.


Related issues

Related to OsmoBSC - Bug #1614: better identification of BTS model / capabilities to BSCStalled2016-02-23

History

#1 Updated by neels over 1 year ago

Isn't it so that we use 'type sysmobts' for BTS types that are in fact not
sysmo?

const struct value_string bts_type_names[_NUM_GSM_BTS_TYPE+1] = {
        { GSM_BTS_TYPE_UNKNOWN, "unknown" },
        { GSM_BTS_TYPE_BS11,    "bs11" },
        { GSM_BTS_TYPE_NANOBTS, "nanobts" },
        { GSM_BTS_TYPE_RBS2000, "rbs2000" },
        { GSM_BTS_TYPE_NOKIA_SITE, "nokia_site" },
        { GSM_BTS_TYPE_OSMO_SYSMO, "sysmobts" },
        { 0,                    NULL }
};

To prevent for example octasic misconfiguration, we would have to increase that
granularity to match real BTS models. ...not that it would prevent users from
running a nanobts with type=sysmobts, as we've seen on the 33c3 ;)

But of course we can already implement various checks based on the current situation.

#2 Updated by laforge over 1 year ago

Please note that this ticket is just for nanobts/bs11/ericsson specific restrictions.

For capability discovery (and associated restrictions) in case of OmsoBTS based hardware/PHY, we have a separate issue #1614

#3 Updated by laforge over 1 year ago

  • Related to Bug #1614: better identification of BTS model / capabilities to BSC added

#4 Updated by dexter over 1 year ago

I wonder how this could be implemented. What we need here is basically a feature-matrix, where we can lookup if a certain feature is supported by a specific BTS. If an unsupported or wrong configuration is hit we could just exit the program.

Maybe it makes sense to include a severity information to distinguish between totally broken configurations and partially working ones. Configurations that would just lead into partial malfunction (e.g. gprs is configured, but BTS does only support CSD, calls work, data not) would print out a warning and the software keeps running.

Concerning the granulartiy we could just add another field in the VTY configuration, that sets a bts subtype. (e.g. "type sysmobts" "model 1002"). If the model parameter is missing, we could expect a default, or we even ignore all checks that depend on the model information. To encourage users to supply a model information, we should print a warning.

The feature check functions should be reachable from anywhere in the code. Features might not only be requested by the vty-config, but also during runtime by various other interfaces.

The feature matrix data can be stored a struct variable (like the infostrings).

#5 Updated by neels over 1 year ago

I believe the main focus is to get very basic validation with what we already have,
without adding new configuration items or extensive code.

It may be easier to have one function that goes through the gsm_network struct
and with few if() catches the cases that we know do not work. A feature matrix is
nice from a code design viewpoint, but I believe will be far more complex in this case.

At first, a function can be called e.g. after OsmoNITB finished reading its config file.
Running it for each VTY command is not necessary, I believe, since most of those
also don't work right away (e.g. TS config change needs a BTS re-connect). Also if a
user issues several commands piecemeal to achieve a different configuration, it may
be impossible to transition there, because changing the values one-by-one hits a
a validation failure and exits the program. When checking commands on an interactive
VTY, we would thus only print warnings and not exit the program ...
Also, on an interactive VTY we would need to print messages using vty_out(),
where in a main() we would fprintf(stderr,...). Maybe first avoid added complexity
for two ways of printing.

Let's

  • have a simple if() check once at NITB startup for now?
    (implement as validator function that fprintf()s errors and lets the caller decide whether to abort the program)
  • start off with the few items in this issues' description,
  • and add more items that come to mind and don't take much effort to add.

Does that sound good?

#6 Updated by laforge over 1 year ago

This ticket is not about how to figure out the sub-type within an
osmo-bts based BTS. There are separate tickets about the design and
implementation of such a mechanism.

This ticket is about checks for capabilities within those models known
to libbsc at this point already:

  • BS-11 supports only FR and HR codecs, maybe EFR, but definitely no AMR
  • BS-11 supports no GPRS/EGPRS and hence also no dynamic channels
  • nanoBTS supports no osmocom-style dynamic channels but ipa-style
  • nanoBTS supports all codecs except HR
  • rbs2000 supports only osmocom-style dynamic channels, no ipa-style
  • osmo-bts supports both osmocom-style and ipa-style dynamic channels

#7 Updated by laforge 11 months ago

  • Assignee changed from Osmocom Developers to sysmocom

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)