Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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.

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

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).

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?