Before this patch, only virtual RF through ZeroMQ was supported.
This patch allows configuring srsUE and srsENB to use a real SDR with
UHD/SoapySDR backend connected through a physical RF network, while
still keeping compatibility to run on virtual RF ZeroMQ network, based
on the resources used (controlled by scenarios). For instance, one can
first run a suite through the phyisical RF (using 2 UHD-controlled SDRs)
and afterwards with ZeroMQ using the following default-suites.conf:
- 4g:srsenb-rftype-uhd+srsue-rftype-uhd
- 4g:srsenb-rftype-zmq+srsue-rftype-zmq
Change-Id: I7dbbe328f4c0225fe74e878bb2da13fe39ccf049
2 tests (iperf3, ping) working against a full srs{UE,ENB,EPC} network
using ZeroMQ backend for RF (so no real RF support yet, that will come
next).
Related: OS##4295, OS#4296
Change-Id: I290c0d79258a9f94f00c7ff2e1c6c5579c0e32f4
bts_osmotrx will check if target host can run the inst, and otherwise
run osmo-trx-lms already present in the system (installed by other
means). This way same class can be used both ways, since the only real
difference between the 2 scenarios is:
* copying inst vs not copying it.
* Running binary from inst vs running it from PATH.
This commit does not provide a mechanism to make sure the osmo-trx or its
dependencies are up-to-date in the target system. A solution for that
will be provided separately.
Related: SYS#4663
Change-Id: I6bd76f6d7e0cb2b6f7bdde971b6515846048a341
This reverts commit 91199a3137.
Since we now support powercycling the SC5, we don't longer need to use a
different ARFCN for it.
Change-Id: Ie8b49c556c90b4a97a73695a93ac4108660a217f
* Add powersupply related code to bts_osmotrx.py to power cycle the
board.
* Each time the board is started, we need to unlock the RF (start TRX
implementation).
Change-Id: I8a1428c1ff90c9f5b42d7ffe86a6fc763819cba2
The feature is not supported yet and it seems to be leaving osmo-trx-lms
in a zombie state preventing it to exit and blocking other tests.
Let's disable it until this feature is working properly under manual
use.
Related: OS#4151
Change-Id: Ic255481e6f1fbbf06c4576f924cf27ae80567801
Due to a bug in sysmocell-5K's TRX implementation, it may keep polluting
the air transmitting after the BTS is disconnected. This could cause
interferences with other tests. Correct fix would be to RF lock it after
test finishes (through ccli), but let's simply use a different ARFCN for
now.
Related: OS#4129
Change-Id: I6d5555aa8740b262ee92110987189c076db44f76
Force TRXDv0 when using sysmocell-5k as a TRX, since its implementation
(different than osmo-trx) doesn't support higher versions. Furthermore,
it will crash upon receival of SETFORMAT string. By forcing maximum TRXD
version to 0, osmo-bts-trx won't sent any SETFORMAT message since 0 is
the initial version to use.
Depends: osmo-bts.git I5eb1fdc002f9d7f4acf475356d8fc998dc8f6326
Related: OS#4006
Change-Id: Ic95c38d91dba354ae64c5edbfcea3fbbf34a7de3
Create a dedicated resources file for running "virtual" tests. If all
components run on the same machine we can avoid having to manage
separate network.
Change-Id: I0da1267a71dc06fd06f3cf4fc3dcfefda4bcf40b
It's very close to the osmo-bts-trx but without osmo-trx. Modify
the suite to make use of this BTS.
Change-Id: I9f5a2501eb4473ccf2287c902ee207c6a45a1bc5
nanoBTS doesn't support SDCCH8 in TS!=1 according to osmo-bsc code.
Let's use in this case TCH/H to make sure they are not used for the test
(since we require osmo-bsc to use full rate codecs for the call).
Change-Id: I37f3fe813d4074fbfe64ff3176048e7d25d470e2
osmo-trx-uhd uses these args during device search/selection process. As
those were not set until now for B200, it means when a B200 was used by
osmo-gsm-tester any UHD device could be picked up and used by UHD.
That was actually happening since inclusion of UmTRX devices in Prod
setup, when running tests against desired B200, actually the UmTRX
device was being used.
Change-Id: I696bbc800b05fdd9a68a77f363d76dcc53ef24ee
Given current bad support of most features used, gobi2k modem was
removed and an EC20 was added instead.
Change-Id: I2df38547978c7d2b1a1309f6e73b5a59413e08ff
Since the modem iface and the GGSN iface are on the same host/netns,
it's really difficult to conveniently test data plane without getting
routing loops. As a result, either GGSN or modem iface must be moved to
a different namespace. The decision after a few discussions was finally
to move modem interfaces to a different netns.
Expected setup:
* ofono is patched to avoid removing modem if it detects
through udev that its net iface was removed (due to for instance, net
iface being moved to another netns and thus not being reachable anymore
by systemd-udev process running in root netns).
* After ofono is started (and successfully configured all the modems and
detected its net ifaces through syfs/udev), script "modem-netns-setup.py
start" which creates a netns for each modem, naming it after its usb
path ID. net ifaces for that modem are moved into its netns.
* Modem is configured to use 802-3 data format, and as a result the net
iface is configured through DHCP (DHCP req only replied AFTER pdp ctx is
activated!).
* Since osmo-gsm-tester knowns the modem USB path ID (available in
resources.conf), it can run required steps (ifup, DHCP) to configure the
interface. The interface name is provided by ofono to osmo-gsm-tester.
* As a result, any process willing to transmit data through the modem
must be in the modem netns.
Related: OS#2308
Change-Id: Icb06bdfcdd37c797be95ab5addb28da2d9f6681c
IPA style dynamic timeslots (TCH/F_PDCH) support only TCH/F and thus
only full rate codecs are to be used.
On the other hand, OSMO style dynamic timeslots (TCH/F_TCH/H_PDCH) can
use both full rate and half rate, so no need to be restrictive there.
Change-Id: I0039ef60b323ed72cfe00d8fd9e9287e9c82d49f
By default, all channels are TCH/F, and as a result we cannot run half
rate codecs on it.
Since recent versions of osmo-bsc, it checks this kind of
misconfigurations and answers with an Assignment Failure:
....
20181029162133430 DMSC <0007> codec_pref.c:445 codec-support/trx config of BTS 0 does not intersect with codec-list of MSC 0
20181029162133430 DMSC <0007> osmo_bsc_main.c:887 Configuration contains mutually exclusive codec settings -- check configuration!
....
20181029162255253 DMSC <0007> osmo_bsc_bssap.c:859 Rx MSC DT1 BSSMAP ASSIGNMENT REQ
20181029162255254 DMSC <0007> osmo_bsc_bssap.c:718 No supported audio type found for channel_type = { ch_indctr=0x1, ch_rate_type=0xa, perm_spch=[ 42 21 11 01 25 05 ]
Change-Id: Ie6b37839fe363b5d1ba64c267d751221434cdedb
The host was updated to have several IP address to be able to run
several instances of osmo-trx in parallel.
Change-Id: I3595b82a5d202caec7bc48a63e28ce0331e5abb7
This way we can test too if SDCH8 channels are allocated and used
correctly in TRX1 in multiTRX setups.
Change-Id: I9d08f3d019a28cf775d70d941c5a60a7e7ca20a9
Run osmo-trx in a separate more powerful machine (i5) rather than
running in low end APU where osmo-gsm-tester runs.
Change-Id: I0479643789783d5e8a142042a65c4d53020d1e79
Pau Espin
Holger Hans Peter Freyther