|Age||Commit message (Collapse)||Author||Files||Lines|
Instead of statically specifying a band for a BTS to use, declare a list
of supported bands for each BTS.
At the time of BTS object creation, ask the BTS for band support and try
to dynamically reserve an ARFCN resource which is compatible with any of
the bands supported by the BTS. All this happens transparently to the
Still, the test may want to use a specific band / arfcn. In this case, a
test can use suite.reserve_arfcn(band, arfcn) to reserve a specific
band/arfcn and pass that to the BTS at creation time, which will then
use that one instead of trying to find a suitable one.
It is left as future work to support BTs with multiple TRX, in which
case several arfcn must be reserved. It should not be that difficult,
mostly using "times: X" where X is the amount of trx, changing the API
to use a list of arfcns and the configure() methods of the BTS.
The idea behind this attribute is similar to the Features one in ofono:
To provide an easy-to-use list of features that a modem supports.
In osmo-gsm-tester this feature list can be used to create scenarios to
act as a filter for modems. For instance, if an sms related feature must
be tested, then a modem supporting sms features is required. This way
only modems supporting that feature are going to be selected for that
test when that scenario is used.
We provide our own list instead of dynamically using it for two reasons:
- Accessing the list from ofono means powering on + online the modem,
which requires using the modem before resource resolution is done.
- ofono may state that it has support for feature X, but it still
doesn't have all features required by osmo-gsm-tester or there is a bug
in some part of the feature which prevents it from being used for a
This parameter is contains a list of supported encryption ciphers by the
modem or bts setting it. It is so far not directly/automatically used
inside osmo-gsm-tester code, but can be useful to create scenarios for
tests that require specific ciphering modes.
For instance, aoip_encryption suite contains tests that require a BTS and
a modem that supports a5 0 and a5 1, otherwise tests will fail.
... instead of using the one from from osmo vty directly.
This way we avoid having multiple word attribute value and we can skip
using quotes in the conf files.
Before this commit, only max_power_red was specified and it could only
be used as a defaults and could not be set per object. Together with
nominal_power, it can be useful to be able to set them to different
values for different objects, as for example different osmo-bts-trx
objects can require different values.
This suite aims testing different authentication and encryption setups.
Algorithm to use to generate response for the challenge during
authentication time is hardcoded in the sim card and cannot be easily
changed. Thus specify in the config of each modem the algorithm used by
the SIM Card. This attribute is used add subscriber_add() time, when the
IMSI, KI and algorithm to use in the MSC to authenticate a given
subscriber is stored in the database. This way we can easily set up
a specific algorithm for each SimCard/Modem, in case different SimCards
are configured with different algorithms.
This can be used to specificially test different algorithms too. For
instance, let's imagine we have 2 simcards, one configured to use comp128v1
and another one with xor, and we create a test which ckecks that XOR is
algo is working fine. We don't want to accidentally select the modem
with comp128v1 in this case. Thus we can use this attribute to create a
scenario file matching 'auth_algo: xor' to ensure always the correct
modem is picked.
This way we can run tests with a specific instance of an osmo-bts-trx,
for instance we may want to run some tests with an Ettus B200 and also
with a sysmoCell 5000.
We may want to support running a device which runs its own TRX
(osmo-trx or different implementation). Furthermore, this TRX may be
available in some specific hwardare rather than on the main unit.
This makes it easy to configure OsmoBtsTrx to launch it's own
osmo-trx or not. In case it is launched, all IPs are configured correctly
to ensure connection can be established.
Before this commit, osmo-trx was binding to 127.0.0.1. Now we can
support multiple osmo-trx being launched on the main unit.
No need to run it for several BTS as the focus here is testing the core
network and interoperation with different BTS is already tested with the
sms suite. This way we avoid lossing extra time running the default
This seems to be the default address used to communicate via SSH with the
sysmoBTS. Whichever process ends up getting this address sees all of the
SSH in its pcap (for the AoIP build it tends to be OsmoHLR).
We could filter properly, but actually also just take this address out of
the pool for allocation to server processes.
The upcoming BSC+MSC+HLR+MGCPGW style will need four IP addresses. I found six
already configured on the main unit, so adding all of them to our
A NITB is a BSC + MSC, and if a BTS talks to a NITB, it talks to the BSC part
of the NITB. Hence it makes more sense to name certain things 'bsc' instead of
'nitb', to prepare for a separate BSC process appearing soon.
I would like to use the IP addresses also for OsmoBSC processes, so it is more
than clear now that 'nitb_iface' was the wrong naming choice.
The only distinction we may need in the future is public versus loopback
interface. To add that, we may add a trait to the 'ip_address' resource
- addr: 10.42.42.1
- addr: 127.0.0.1
This way we can substitute public vs loopback addresses flexibly (e.g. using
In the example config and the jenkins scripts, use paths below common parent
1. example: put the state dir in /var/tmp/osmo-gsm-tester/state, instead of in
the config dir like /etc/osmo-gsm-tester.
2. contrib scripts: place trials in /var/tmp/osmo-gsm-tester/trials, and to
move into place atomically, use /var/tmp/osmo-gsm-tester/.prep-trials as
The OsmoGSMTester manual is currently also being updated to setup these paths,
with /var/tmp/osmo-gsm-tester owned by a common group and having group-sticky
as well has group-writable access rules.
Let's opt for the oldest/simplest case by default.
/suites will be the definitive GSM tests collection where everyone should contribute.
Since we're using /example on our current osmo-gsm-tester setup actually as-is,
change paths.conf to point at ../suites.
Also drop the env file and tweak the README.txt