MS driver: GSM tester config integration

Pau Espin Pedrol pespin at
Tue Mar 6 12:20:11 UTC 2018


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/

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 
   - times: 6 # msc, bsc, hlr, stp, mgw*2
   - times: 1
   - times: 300
     - sms

Then, create a test which manages all those (see 
#!/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 (see next_lac() for 

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().


- Pau Espin Pedrol <pespin at>
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

More information about the baseband-devel mailing list