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
It seems for not yet clear reasons the MS require some time after the
PDCH channels have been activated again to use them reliably. If no
sleep is used between call hangup and gprs activate pdp ctx, the MS
fails to activate the pdp ctx due to QMI error respone to the "Start
network" requested.
Related: OS#2582
Change-Id: I73b51c31309ac4c28c64ed7eb7c8c649e535aa22
2nd TRX arfcn is changed in defaults.conf because multi_arfcn requires
them to be alocated in steps of 4 starting from TRX0.
It is not enabled by default yet on B200 (it must use it to support
several TRX) because current host running osmo-gsm-tester is not
performant enough and cannot keep up with timers due to multi-arfcn CPU
overhead.
Change-Id: I096df82ad1f4cbb41dfbd6a78466a845f34be385
When first suites were added, osmo-nitb was used. Then new tests using
regular split components were added with "aoip_" prefix. At some point
it was clear that osmo-nitb was being deprecated so new tests for split
components were added without any prefix, as they are expected to be the
default one. Since most current and future development is going to be done
for split components, as well as new tests added, it makes sense to move
the few old testsuites using osmo-nitb to have all "nitb_" prefix, while
keeping the split component tests without prefix as it's the regular
network topology.
Change-Id: Idea2e053d337548e0e9b1b47441dbb262124f909
* This commit is a preparation for future commits to add support for
different osmo-trx devices and backends like osmo-trx-lms.
* Drop deprecated osmo-trx-* cmd line params and use VTY cfg to set them.
* As number of osmo-trx related osmo-gsm-tester attributes grow, group
them togther in an "osmo_trx" dictionary.
Change-Id: I77d29413c9e3b600b796627ba366f80c3281b7e1
Since latest release firmware, we have been unable to start up octobts
correctly. As it's annoying having all those tests failing all the time,
let's disable them in nightly builds until we have a working OctoBTS
setup working again.
Change-Id: I828723193564b3a91aeac0c163c7c8c6b7e4058c
Currently only 2 nanoBTS in the 900 band are attached together as a
multiTRX setup. We thus set num_trx to 2 and set channel allocator
descending to force the BTS to use the 2nd TRX when allocating channels.
Change-Id: I12e1bcb047c4efac5693cf725739e0ce2e0532ee
Now that we support modifiers in scenario files, we don't need to
duplicate tests and testsuites to dynamically set trx configuration at
run time. It can be done more easily with scenario modifiers.
Change-Id: I80c441bb5b98d5d2e95d4c6ae1efab3e5f3c40d9
Before this patch, scenarios were only used to select resources with
specific attributes. This commit introduces "modifiers" in scenarios,
which allows setting or modifing config attributes of resources once
they have been reserved. This way same test can be run selecting same
resources but modifying its configuration, allowing for instance running
different number of TRX, different timeslot configuration, etc.
Modifiers are described by placing a "modifiers" dictionary in any
scenario file, similar to the current "resources" one used to select
requird resources. The "modifiers" dictionary is overlaid on top of the
"resources" one resulting from combining all the "resources" dictionary
of all scenario files.
Change-Id: If8c422c67d9a971d9ce2c72594f55cde2db7550d
num_trx is left for now by default to 1, but it has been tested to work
properly (current tests pass and both trx are configured) with
num_trx=2.
Change-Id: Ib3962f824a804e2aa582601475a8514c6cb0d8e7
nanobts IP addresses are assigned through DHCP, and are not local to the
main unit. Let's use another subset for this DHCP pool as we usually use
.50ish for static local IP addresses.
Change-Id: Ibdb0dd97a490aaa555a7bf53cf43cc5a5533a012
The num_trx attribute for a given BTS states the number of TRX to be
used by that BTS. If more than num_trx are configured in trx_list in the
cfg file, then only up to num_trx are taken into account. If a num_trx
value higher than max_trx is specified throuygh config file or at
runtime by the test, an exception is raised explaining the issue.
The num/max_trx attributes are overlayed along the config levels
(generic -> bsc_bts -> specific bts-type -> specific resource object).
This way we can specify a long list of trx+timeslot config in the
generic config (bsc_bts), and tune for each model and specific BTS which
is the desired default number of TRX, as well as the maximum supported
per type.
Change-Id: I7f46eaf7a16f03268653299c93600c0443f691ac
Pau Espin