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:
- 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):
  - times: 6 # msc, bsc, hlr, stp, mgw*2
  - times: 1
  - times: 300
    - 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()
 except NoResourceExn:
# 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 <pes...@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

Reply via email to