Project

General

Profile

Bug #1614

better identification of BTS model / capabilities to BSC

Added by laforge over 2 years ago. Updated 4 months ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

60%

Estimated time:
Spec Reference:

Description

Right now, there is a lot of implied knowledge at the BSC level about the BTS, i.e.
  • the BSC needs to be told which BTS model it is
  • the BSC needs to be told the nominal transmit power of each TRX
  • the BSC needs to be told about the codec capabilities, etc.

In order to reduce the currently seemingly endless possbilities how somebody can end up with a non-working
configuration, it would be good if the BTS would express its capabilities towards the BSC. As there is
no standard in the Abis specs for this, we have to come up with a mechanism of our own.

It might be a vendor-specific OML request from BSC to BTS, which we could use to determine from BSC side if the BTS supports this request at all (if not, proceed as usual). This would also ensure backwards compatibility with nanoBTS or older OsmoBTS versions.


Related issues

Related to OsmoBSC - Feature #1946: Add checks to the BSC VTY to prevent configurations known to not workNew2017-02-08

Related to OsmoBTS - Bug #2316: osmo-bts aborts on sysmoBTSClosed2017-06-01

Related to OsmoBTS - Bug #2317: multibts setup produce unnecessary OML warningClosed2017-06-06

History

#1 Updated by laforge almost 2 years ago

  • Priority changed from Normal to High

#2 Updated by laforge over 1 year ago

  • Related to Feature #1946: Add checks to the BSC VTY to prevent configurations known to not work added

#3 Updated by laforge over 1 year ago

  • Assignee set to msuraev
The BTS should report via OML after connection [or after inquiry?]:
  • OsmoBTS version number string
  • OsmoPCU version number string (if any connected, or maybe at PCU connection time?)
  • OsmoBTS variant (sysmo, octphy, trx, lc15, ...)
  • per-TRX PHY version number (taken from DSP of sysmo/octphy/lc15, taken from OsmoTRX in case of omso-bts-trx)
  • per-TRX nominal transmit power
  • BTS sub-model (osmo-bts-sysmo supports 1002, 1020, 1100, 2050)
  • a bit-mask of capabilities (that can be extended in length as needed by future versions, like classmark in GSM L3)
To expand a bit on the capabilities that need reporting via the bit-masks (one for the BTS, separate one for each TRX):
  • TRX: codec capabilities (hr/fr/efr/amr-hr/amr-fr)
  • TRX: band capabilities (850/900/1800/1900, maybe even the exotic ones like 400/450?)
  • TRX: dynamic TCH/F_PDCH (IPA style)
  • TRX: dynamic TCH/F_TCH/H_PDCH (Osmocom style)
  • TRX: DTXd (separate bits for each codec)
  • BTS: generation of OML alerts
  • BTS: AGCH/PCH proportional allocation
  • BTS: CBCH support

The feature-bit definitions should probably be part of a shared header file (maybe put them in gsm_data_common)?

The OML message exchange should then transfer the capability bit-mask from the 'struct gsm_bts' and 'struct gsm_bts_trx' from OsmoBTS into that of libbsc (OsmoBSC/OsmoNITB(. The libbsc code can then take those capabilities into consideration when trying to configure or use the BTS.

#4 Updated by laforge over 1 year ago

#5 Updated by msuraev over 1 year ago

  • Status changed from New to In Progress

After reading 3GPP TS 52.021, there seems to be several options:

- for sending OsmoPCU version string we can re-use § 8.8.2 Failure Event Report using manufacturer-defined NM_PCAUSE_T_MANUF with osmocom-specific sub-types for versions as it's unlikely to be already known when we report capabilities to BSC.

- for reporting capabilities we have several options:
1) use §8.8.1 State Changed Event Report - unsolicited report from BTS, without ack/nack
2) use §6.10.1 Get Attributes - request by BSC

In case of 1) we can use either §9.4.48 Site Inputs TLV (up to 128 parameters with boolean state) or §9.4.7 Availability Status TLV (octet per feature with pre-defined status encoding like "In test", "Not installed" etc) for feature sets. BTS variant and sub-model can be encoded using §9.4.28 Man.dep. State TV which give us up to 255 variants.

In case of 2) we can use §8.11.3 Get Attribute Response with §9.4.64 Get Attribute Response Info. This way we can request any attributes from §9.4 using §9.4.26 List of Required Attributes TLV.

The 2) seems to be more flexible (we can stuff BTS version into §9.4.62 SW Description TV for example) on the other hand we already using 1) actively. Overall I think we should use 2) unless it's somehow incompatible with other BTS hw we support.

#6 Updated by laforge over 1 year ago

I agree, we should use get_attributes

#7 Updated by msuraev over 1 year ago

  • % Done changed from 0 to 10

Gerrit 2093 has been merged with changes necessary for backward compatibility between new BSC and old BTS.

#8 Updated by msuraev over 1 year ago

Related gerrit 2144 is under review.

#9 Updated by msuraev over 1 year ago

  • % Done changed from 10 to 20

Gerrit 2144, 2161 were merged, 2165, 2166, 2087 are under review, additional patches will follow.

#10 Updated by msuraev over 1 year ago

  • Checklist item OsmoBTS version number string added
  • Checklist item OsmoPCU version number string added
  • Checklist item OsmoBTS variant added
  • Checklist item per-TRX PHY version number added
  • Checklist item per-TRX nominal transmit power added
  • Checklist item BTS sub-model added
  • Checklist item a bit-mask of capabilities added

PCU version number is handled by #1615.

#11 Updated by msuraev over 1 year ago

  • Status changed from In Progress to Stalled

#12 Updated by msuraev over 1 year ago

Gerrit 2165, 2166, 2087, 2544 merged, 2545 is under review, additional patches will follow.

#13 Updated by msuraev over 1 year ago

  • Checklist item OsmoBTS version number string set to Done
  • Checklist item OsmoBTS variant set to Done
  • Checklist item BTS sub-model set to Done
  • % Done changed from 20 to 50

Gerrit 2545 has been merged.

#14 Updated by msuraev over 1 year ago

Gerrit 2784, 2785 are merged; 2783, 2786, 2794, 2797, 2799, 2800 are under review.

#15 Updated by msuraev over 1 year ago

  • Checklist item deleted (a bit-mask of capabilities )
  • Checklist item BTS bit-mask of capabilities added
  • Checklist item TRX bit-mask of capabilities added

#16 Updated by neels over 1 year ago

  • Related to Bug #2316: osmo-bts aborts on sysmoBTS added

#17 Updated by neels over 1 year ago

I have reverted 9eeb0b1a136fc8c24a86cb4d832c264674c10db0 in d36b3a84638d6db940387f0e18c98855202f554d.
Explanation in http://git.osmocom.org/osmo-bts/commit/?id=d36b3a84638d6db940387f0e18c98855202f554d

#18 Updated by msuraev over 1 year ago

  • Related to Bug #2317: multibts setup produce unnecessary OML warning added

#19 Updated by msuraev over 1 year ago

Note: due to #2317 it'll not work if BTS is configured in OpenBSC with number higher than 0 because corresponding OML requests will be ignored by BTS.

#20 Updated by msuraev over 1 year ago

  • % Done changed from 50 to 60

Merged: 2783, 2794, 2797, 2800, 2786, 2799.

#21 Updated by laforge 9 months ago

  • Project changed from OpenBSC to OsmoBSC
  • Category deleted (libbsc)

#22 Updated by msuraev 7 months ago

  • Assignee changed from msuraev to dexter

#23 Updated by laforge 4 months ago

  • Priority changed from High to Normal

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)