better identification of BTS model / capabilities to BSC
- 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.
- Assignee set to msuraev
- 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)
- 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.
- 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.
- 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.
I have reverted 9eeb0b1a136fc8c24a86cb4d832c264674c10db0 in d36b3a84638d6db940387f0e18c98855202f554d.
Explanation in http://git.osmocom.org/osmo-bts/commit/?id=d36b3a84638d6db940387f0e18c98855202f554d