6 Mar
2018
6 Mar
'18
1:20 p.m.
Hi,
I guess you are referring to my comment in [1]. You can reuse suite and
resources management utilities already present in osmo-gsm-tester. The
easiest way to do that would be to create a new implementation for class
Modem which would start a mobile process underneath. Then in suite()
when requesting a modem add a function to allocate class ModemOfono or
ModemOsmoMobile based on config type, similar to how it is done for
different bts (see example/resources.conf and src/osmo_gsm_tester/suite.py).
Then, you have your resources files with 300 modems:
modem:
- label: mobile_xyz
type: osmo-mobile
auth_algo: 'comp128v1'
ciphers: [a5_0, a5_1]
features: ['sms', 'voice', 'ussd', 'gprs']
times: 300
Then create a suite with a suite.conf containing your scenario (see
suites/aoip_sms/suite.conf):
resources:
ip_address:
- times: 6 # msc, bsc, hlr, stp, mgw*2
bts:
- times: 1
modem:
- times: 300
features:
- sms
Then, create a test which manages all those (see
suites/aoip_sms/mo_mt_sms.py):
#!/usr/bin/env python3
from osmo_gsm_tester.testenv import *
while True:
modems = []
try: # we could add a suite.get_num_resources(type='modem') API instead
m = suite.modem()
modems.append(m)
except NoResourceExn:
break;
# Then do here whatever you like to do with them, like register them, etc.
I think that CDF functions and IMSI generation and alike are really
attach to the test and they are really not resources, so no need to
"configure" them. This topic matches with your other mail thread too.
We already talked with Neels about providing a set of functionality
helpers and repeating code used in tests, in order to keep tests small
and easy to follow. My bet here would be to have code like CDF functions
which is not used internally by osmo-gsm-tester classes into this kind
of library (which can be imported like from osmo_gsm_tester.testenv
import *). Same goes for IMSI generation, then use
modem.set_imsi(generated_imsi) or whatever before calling
modem.connect(). If you want to avoid IMSI collision between consecutive
tests, then add it to osmo-gsm-tester resource.py (see next_lac() for
instance).
About using virtphy, trxcon and all these stuff, we have the problem
that the ARFCN config is still not completely arranged and implemented.
I arrived to some good proposal after several patch revision with Neels,
which can be found in [2], but still missing the actual implementation.
The idea I have in mind would be to add an extra attribute to arfcn
resources called "group" which allows to have separate groups of arfcn,
for instance phy-air vs virt, but also phy-dn1 vs phy-dn2 in case we
have several non colliding distributions networks (Distributed network =
MS and BTS connected through wires). Then each resource playing with
arfcn should have the attribute "arfcn-group: xyz" to know to which
arfcn medium is it connected. This will be used by the algorithm in [2]
to manage arfcn correctly or error if the combination specificed in the
scenario is not possible (for instance explicitly requesting a phy BTS
but only having virtphy MS).
We could Add DistributionNetwork class if needed, which could be
accessed and started from the different objects using them, like ms.dn()
or bts.dn().
[1] https://gerrit.osmocom.org/#/c/6919/
[2] https://osmocom.org/issues/2230
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte