path: root/2016/osmobts-phy/osmobts-phy.adoc
diff options
Diffstat (limited to '2016/osmobts-phy/osmobts-phy.adoc')
1 files changed, 118 insertions, 0 deletions
diff --git a/2016/osmobts-phy/osmobts-phy.adoc b/2016/osmobts-phy/osmobts-phy.adoc
new file mode 100644
index 0000000..1ecca7a
--- /dev/null
+++ b/2016/osmobts-phy/osmobts-phy.adoc
@@ -0,0 +1,118 @@
+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
+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
personal git repositories of Harald Welte. Your mileage may vary