From 2814fba32901422acd86dd852a7b7770796c5342 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Fri, 22 Apr 2016 11:39:01 +0200 Subject: add phy_link/phy_instance slides @ osmodevcon --- 2016/osmobts-phy/osmobts-phy.adoc | 118 + 2016/osmobts-phy/osmobts-phy.html | 4174 +++++++++++++++++++++++++++++++++++ 2016/osmobts-phy/osmobts-phy__1.png | Bin 0 -> 29123 bytes 3 files changed, 4292 insertions(+) create mode 100644 2016/osmobts-phy/osmobts-phy.adoc create mode 100644 2016/osmobts-phy/osmobts-phy.html create mode 100644 2016/osmobts-phy/osmobts-phy__1.png (limited to '2016') 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 + +[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? diff --git a/2016/osmobts-phy/osmobts-phy.html b/2016/osmobts-phy/osmobts-phy.html new file mode 100644 index 0000000..a9fbc0b --- /dev/null +++ b/2016/osmobts-phy/osmobts-phy.html @@ -0,0 +1,4174 @@ + + + + +OsmoBTS phy_link / phy_instance + + + + + + + + +
+

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

+
+
+
+osmobts-phy__1.png +
+
+
    +
  • + +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?

+
+
+ + diff --git a/2016/osmobts-phy/osmobts-phy__1.png b/2016/osmobts-phy/osmobts-phy__1.png new file mode 100644 index 0000000..177bafd Binary files /dev/null and b/2016/osmobts-phy/osmobts-phy__1.png differ -- cgit v1.2.3