Project

General

Profile

Actions

Bug #5538

closed

OsmoBSC assumes more features from OsmoBTS than it announces

Added by osmith about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/21/2022
Due date:
% Done:

100%

Spec Reference:

Description

OsmoBSC prints log entries like:

Get Attributes Response: reported feature 'PAGING_COORDINATION' is not supported, while we thought it is.

This is due to features being assumed to be supported by OsmoBSC in bts_model_osmobts_init(), but not being announced by OsmoBTS. At time of writing, these are assumed:

    osmo_bts_set_feature(&model_osmobts.features, BTS_FEAT_GPRS);
    osmo_bts_set_feature(&model_osmobts.features, BTS_FEAT_EGPRS);
    osmo_bts_set_feature(&model_osmobts.features, BTS_FEAT_PAGING_COORDINATION);
    osmo_bts_set_feature(&model_osmobts.features, BTS_FEAT_IPV6_NSVC);
    osmo_bts_set_feature(&model_osmobts.features, BTS_FEAT_CCN);

OsmoBTS has multiple bts_model_init() functions, where it seems we should mark the same features as supported as expected by OsmoBSC after carefully verifying that everything still works as expected.

OsmoBSC sometimes checks for the features of the model (osmo_bts_has_feature(bts->model->features, ...)), sometimes for the features actually reported by the BTS (osmo_bts_has_feature(bts->features, ...)).

Actions #1

Updated by osmith about 2 years ago

  • Status changed from New to In Progress
  • Assignee set to osmith
  • % Done changed from 0 to 20
It should be relatively safe to enable BTS_FEAT_PAGING_COORDINATION according to the commit message of https://gerrit.osmocom.org/c/osmo-bsc/+/18936, so I did it here: Additional patch to sort the list of features and to add a comment about keeping it in sync with OsmoBTS:
Actions #2

Updated by laforge about 2 years ago

I think for years I have been bewildered with this weird notion that the BSC has some pre-existing assumption about what features a given osmo-bts will support. The entire point of reporting those features from osmo-bts at runtime to the BSC is to make sure that no matter what older/future osmo-bts version or hardware is used, the BSC will alwasy base its decision on what is reported at runtime.

static / compiled-in feature flags make only sense for non-osmo-bts models, where we do not have this capability.

Actions #3

Updated by osmith about 2 years ago

  • % Done changed from 20 to 90

More patches to resolve this; now the bts->model->features are only used to validate VTY configurations. The features the BTS actually reports is used in all code paths once available to change BSC behavior.

https://gerrit.osmocom.org/q/topic:bts-feats

Actions #4

Updated by osmith almost 2 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)