Project

General

Profile

Actions

Bug #1614

open

better identification of BTS model / capabilities to BSC

Added by laforge about 8 years ago. Updated almost 4 years ago.

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

60%

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.


Checklist

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

Related issues

Related to OsmoBSC - Feature #1946: Add checks to the BSC VTY to prevent configurations known to not workNew02/08/2017

Actions
Related to OsmoBTS - Bug #2316: osmo-bts aborts on sysmoBTSClosedneels06/01/2017

Actions
Related to OsmoBTS - Bug #2317: multibts setup produce unnecessary OML warningClosedmsuraev06/06/2017

Actions
Related to OsmoBSC - Bug #3799: OsmoBSC send OML "Get Attributes" with wrong length valueResolvedlaforge02/12/2019

Actions
Related to OsmoBTS - Bug #3938: Get Attribute Response parsing is broken: NM_ATT_SW_DESCR is ignoredResolvedfixeria04/18/2019

Actions
Actions #1

Updated by laforge over 7 years ago

  • Priority changed from Normal to High
Actions #2

Updated by laforge about 7 years ago

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

Updated by laforge about 7 years 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.

Actions #4

Updated by laforge about 7 years ago

Actions #5

Updated by msuraev about 7 years 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.

Actions #6

Updated by laforge about 7 years ago

I agree, we should use get_attributes

Actions #7

Updated by msuraev about 7 years ago

  • % Done changed from 0 to 10

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

Actions #8

Updated by msuraev almost 7 years ago

Related gerrit 2144 is under review.

Actions #9

Updated by msuraev almost 7 years ago

  • % Done changed from 10 to 20

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

Actions #10

Updated by msuraev almost 7 years 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.

Actions #11

Updated by msuraev almost 7 years ago

  • Status changed from In Progress to Stalled
Actions #12

Updated by msuraev almost 7 years ago

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

Actions #13

Updated by msuraev almost 7 years 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.

Actions #14

Updated by msuraev almost 7 years ago

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

Actions #15

Updated by msuraev almost 7 years 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
Actions #16

Updated by neels almost 7 years ago

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

Updated by neels almost 7 years ago

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

Actions #18

Updated by msuraev almost 7 years ago

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

Updated by msuraev almost 7 years 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.

Actions #20

Updated by msuraev almost 7 years ago

  • % Done changed from 50 to 60

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

Actions #21

Updated by laforge over 6 years ago

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

Updated by msuraev about 6 years ago

  • Assignee changed from msuraev to dexter
Actions #23

Updated by laforge almost 6 years ago

  • Priority changed from High to Normal
Actions #24

Updated by laforge about 5 years ago

  • Related to Bug #3799: OsmoBSC send OML "Get Attributes" with wrong length value added
Actions #25

Updated by fixeria almost 5 years ago

  • Related to Bug #3938: Get Attribute Response parsing is broken: NM_ATT_SW_DESCR is ignored added
Actions #26

Updated by laforge about 4 years ago

Actions #27

Updated by laforge almost 4 years ago

  • Assignee deleted (dexter)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)