First OpenBSC supported BTS Siemens BS-11 was 2-TRX
OpenBSC (OsmoNITB) had multi-trx support from the very beginngin
ip.access nanoBTS can be stacked for multi-TRX
OpenBSC (OsmoNITB) has supported this for many yeasr
Classic OsmoBTS was single-TRX
osmo-bts-trx was extended with 2 TRX support but not in master
until recently
OsmoBTS supported hardware (currently)
osmo-bts-sysmo for sysmoBTS (1002/1020/1100)
osmo-bts-trx for OsmoTRX (UmTRX, USRP, …)
osmo-bts-octphy for Octasic OCTDSP / OCTPHY-2G
osmo-bts-litecell15 for Nuran Litecell 1.5
osmo-bts-sysmo
osmo-bts-sysmo for sysmoBTS (1002/1020/1100)
shared memory message queues between PHY-DSP and ARM core
DSP can only implement a single TRX. MultiTRX can be achieved by
stacking like in nanoBTS
would require one OsmoBTS per sysmoBTS board, each handling one TRX
OML router needed to route OML to different boards
OsmoBTS would need to be able to run a TRX without BCCH
osmo-bts-trx
osmo-bts-trx for OsmoTRX (UmTRX, USRP, …)
had two-trx support in fairwaves branch
assumes two soft TRXs in a single "transceiver" program (OsmoTRX)
has lots of global variables assuming a single transceiver program
handling all TRXs :(
osmo-bts-litecell
osmo-bts-litecell15 for Nuran Litecell 1.5
shared memory message queues between PHY-DSP and ARM core
very similar to osmo-bts-sysm, but:
has two TRXs available to ARM CPU
osmo-bts-octphy
osmo-bts-octphy for Octasic OCTDSP / OCTPHY-2G
various different hardware boards (OCBTS3000/3500/4000) with
different number of DSPs and radios
DSPs interconnected with ARM/x86 CPU over Ethernet
There can be multiple DSPs, each with two radios and multiiple
software TRX
most flexible/versatile configuration
served as the blueprint for phy_link/phy_instance abstraction
phy_link / phy_instance
above hierarchy exists independent of the BTS/TRX/TS/lchan hierarchy
every TRX gets mapped to a phy_instance
PHY link
A PHY link is a physical connection / link towards a given PHY.
This might be, for example,
a set of file descriptors to device nodes in the /dev/ directory
(sysmobts, litecell15)
a packet socket for sending raw Ethernet frames to an OCTPHY
a set of UDP sockets for interacting with OsmoTRX
Each PHY links has a set of attribute/parameters and a list of 1 to n PHY instances.
PHY links are numbered 0..n globally inside OsmoBTS.
Each PHY link is configured via the VTY using its individual top-level
vty node.
The PHY links and instances must be configured above the BTS/TRX nodes in the configuration file. If the file is saved via the VTY, the code automatically ensures this.
PHY instance
A PHY instance is an instance of a PHY, accessed via a PHY link.
In the case of osmo-bts-sysmo and osmo-bts-trx, there is only one
instance in every PHY link. This is due to the fact that the API
inside that PHY link does not permit for distinguishing multiple
different logical TRXs.
Other PHY implementations like the OCTPHY however do support addressing multiple PHY instances via a single PHY link.
PHY instances are numbered 0..n inside each PHY link.
Each PHY instance is configured via the VTY as a separate node beneath each PHY link.
Mapping PHY instances to TRXs
Each TRX node in the VTY must use the phy N instance M command in
order to specify which PHY instance is allocated to this specific TRX.