1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
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?
|
