OsmoBTS phy_link / phy_instance
===============================
Harald Welte
:copyright: Harald Welte (Liense: CC-BY-SA)
:backend: slidy
:max-width: 45em

== Multiple Transceivers in Osmocom

* 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

[graphviz]
----
digraph G {
	label="4 TRX BTS with 2 PHY Links, each 2 Instances"
	rankdir=LR;
	p0i0 [label = "PHY0 Inst0"]
	p0i1 [label = "PHY0 Inst1"]
	p0i0->phy0
	p0i1->phy0
	phy0->bts
	p1i0 [label = "PHY1 Inst0"]
	p1i0->phy1
	p1i1 [label = "PHY1 Inst1"]
	p1i1->phy1
	phy1->bts
}
----

* 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.

== The End

Questions?
