blob: 021c6f4ff4aa93b574951ac9c65fa5ab6055182e [file] [log] [blame]
Pau Espin Pedrol46560ea2018-09-20 15:03:19 +02001[[trx_backends]]
2== OsmoTRX backend support
3
Pau Espin Pedrol6b50b622018-09-19 17:05:30 +02004[[backend_uhd]]
Pau Espin Pedrol46560ea2018-09-20 15:03:19 +02005=== `osmo-trx-uhd` for UHD based Transceivers
Pau Espin Pedrold06172c2018-07-05 18:26:52 +02006
7This OsmoTRX model uses _libuhd_ (UHD, USRP Hardware Driver) to drive the
8device, that is configuring it and reading/writing samples from/to it.
9
10So far, this backend has been mostly used to drive devices such as the Ettus
11B200 family and Fairwaves UmTRX family, and used to be the default backend used
12for legacy @osmo-trx@ binary when per-backend binaries didn't exist yet.
13
14Any device providing generic support for UHD should theoretically be able to be
Martin Hauke066fd042019-10-13 19:08:00 +020015run through this backend without much effort, but practical experience showed
Pau Espin Pedrold06172c2018-07-05 18:26:52 +020016that some devices don't play well with it, such as the LimeSDR family of
17devices, which showed far better results when using its native interface.
18
19Related code can be found in the _Transceiver52M/device/uhd/_ directory in
20_osmo-trx.git_.
21
Pau Espin Pedrol6b50b622018-09-19 17:05:30 +020022[[backend_lms]]
Pau Espin Pedrol46560ea2018-09-20 15:03:19 +020023=== `osmo-trx-lms` for LimeSuite based Transceivers
Pau Espin Pedrold06172c2018-07-05 18:26:52 +020024
25This OsmoTRX model uses LimeSuite API and library to drive the device, that is
26configuring it and reading/writing samples from/to it.
27
28This backend was developed in order to be used together with LimeSDR-USB and
29LimeSDR-mini devices, due to to the poor results obtained with the UHD backend,
30and to simplify the stack.
31
32Related code can be found in the _Transceiver52M/device/lms/_ directory in
33_osmo-trx.git_.
34
Pau Espin Pedrol6b50b622018-09-19 17:05:30 +020035[[backend_usrp1]]
Pau Espin Pedrol46560ea2018-09-20 15:03:19 +020036=== `osmo-trx-usrp1` for libusrp based Transceivers
Pau Espin Pedrold06172c2018-07-05 18:26:52 +020037
38This OsmoTRX model uses the legacy libusrp driver provided in GNU Radio 3.4.2.
39
40As this code was dropped from GNU Radio at some point and was found very
41difficult to build, some work was done to create a standalone libusrp which can
42be nowadays found as a separate git repository together with other osmocom git
43repositories, in https://git.osmocom.org/libusrp/
44
45Related code can be found in the _Transceiver52M/device/usrp1/_ directory in
46_osmo-trx.git_.
Pau Espin Pedrol06d3ba02019-07-30 17:56:03 +020047
48The USRPDevice module is basically a driver that reads/writes packets to a USRP
49with two RFX900 daughterboards, board A is the Tx chain and board B is the Rx
50chain.
51
52The `radioInterface` module is basically an interface between the transceiver
53and the USRP. It operates the basestation clock based upon the sample count of
54received USRP samples. Packets from the USRP are queued and segmented into GSM
55bursts that are passed up to the transceiver; bursts from the transceiver are
56passed down to the USRP.
57
58The transceiver basically operates "layer 0" of the GSM stack, performing the
59modulation, detection, and demodulation of GSM bursts. It communicates with the
60GSM stack via three UDP sockets, one socket for data, one for control messages,
61and one socket to pass clocking information. The transceiver contains a priority
62queue to sort to-be-transmitted bursts, and a filler table to fill in timeslots
63that do not have bursts in the priority queue. The transceiver tries to stay
64ahead of the basestation clock, adapting its latency when underruns are reported
65by the radioInterface/USRP. Received bursts (from the radioInterface) pass
66through a simple energy detector, a RACH or midamble correlator, and a DFE-based
67demodulator.
68
69NOTE: There's a `SWLOOPBACK` #define statement, where the USRP is replaced
70with a memory buffer. In this mode, data written to the USRP is actually stored
71in a buffer, and read commands to the USRP simply pull data from this buffer.
72This was very useful in early testing, and still may be useful in testing basic
73Transceiver and radioInterface functionality.
Pau Espin Pedrolc5f623f2024-03-26 16:17:59 +010074
75
76[[backend_ipc]]
77=== `osmo-trx-ipc` Inter Process Communication backend
78
79This OsmoTRX model provides its own Inter Process Communication (IPC) interface
80to drive the radio device driver (from now on the Driver), allowing for third
81party processes to implement the lowest layer device-specific bits without being
82affected by copyleft licenses of OsmoTRX.
83
84For more information on such interface, see section <<ipc_if>>.
85
86[[fig-backend-ipc]]
87.Architecture with _osmo-trx-ipc_ and its IPC _Driver_
88[graphviz]
89----
90digraph G {
91 rankdir=LR;
92 MS0 [label="MS"];
93 MS1 [label="MS"];
94 OsmoTRX [label="osmo-trx-ipc", color=red];
95 BTS;
96
97 subgraph cluster_ipc_driver {
98 label = "IPC Driver";
99 color=red;
100 RE [label = "Radio Equipment"];
101 REC [label="Radio Equipment Controller"];
102 RE->REC;
103 }
104
105 REC->OsmoTRX [label="IPC Interface", color=red];
106
107 MS0->RE [label="Um"];
108 MS1->RE [label="Um"];
109 OsmoTRX->BTS [label="bursts over UDP"];
110
111}
112----
113
114A sample config file for this OsmoTRX model can be found in _osmo-trx.git_ https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/doc/examples/osmo-trx-ipc/osmo-trx-ipc.cfg[doc/examples/osmo-trx-ipc/osmo-trx-ipc.cfg]
115
116In the config file, the following VTY command can be used to set up the IPC UD Master Socket _osmo-trx-ipc_ will connect to at startup:
117
118.Example: _osmo-trx-ipc_ will connect to UD Master Socket /tmp/ipc_sock0 upon startup
119----
120dev-args ipc_msock=/tmp/ipc_sock0
121----
122
123==== ipc-device-test
124
125When built with `--with-ipc --with-uhd` configure options, _osmo-trx.git_ will
126build the test program called _ipc-driver-test_. This program implements the
127_Driver_ side of the osmo-trx-ipc interface (see <<ipc_if>> for more
128information) on one side, and also interacts internally with UHD (eg B210 as
129when using osmo-trx-uhd).
130
131You can use this small program as a reference to:
132
133* Test and experiment with _osmo-trx-ipc_.
134
135* Write your own IPC _Driver_ connecting to osmo-trx-ipc.
136
137[[fig-backend-ipc-device-test]]
138.Architecture with _osmo-trx-ipc_ and ipc-device-test as IPC _Driver_
139[graphviz]
140----
141digraph G {
142 rankdir=LR;
143 MS0 [label="MS"];
144 MS1 [label="MS"];
145 SDR;
146 ipc_device_test[label = "ipc-device-test", color=red];
147 OsmoTRX [label="osmo-trx-ipc", color=red];
148 BTS;
149
150 MS0->SDR [label="Um"];
151 MS1->SDR [label="Um"];
152 SDR->ipc_device_test [label="UHD"];
153 ipc_device_test->OsmoTRX [label="IPC Interface", color=red];
154 OsmoTRX->BTS [label="bursts over UDP"];
155}
156----
157
158The code for this app is found here:
159
160* https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/ipc-driver-test.h[Transceiver52M/device/ipc/ipc-driver-test.h]
161
162* https://gitea.osmocom.org/cellular-infrastructure/osmo-trx/src/branch/master/Transceiver52M/device/ipc/ipc-driver-test.c[Transceiver52M/device/ipc/ipc-driver-test.c]
163
164Those files use the server-side (_Driver_ side) code to operate the Posix Shared
165Memory region implemented in files `shm.c`, `shm.h`, `ipc_shm.c` and `ipc_shm.h`
166in the same directory.
167
168Most of the code in that same directory is deliverately released under a BSD
169license (unlike most of _osmo-trx.git_), allowing third parties to reuse/recycle
170the code on their implemented _Driver_ program no matter it being proprietary or
171under an open license. However, care must be taken with external dependencies,
172as for instance shm.c uses the talloc memory allocator, which is GPL licensed
173and hence cannot be used in a proprietary driver.