Approach to system testing for Osmocom stack

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.

Pau Espin Pedrol pespin at sysmocom.de
Mon Aug 20 10:44:36 UTC 2018


Hi Holger

Since I wrote my last e-mail in this thread, we developed some more 
stuff for osmo-gsm-tester which may be interesting for this topic.

I recently introduced some code to be able to run TTCN3 tests using real 
HW and a motorola c213 phone running osmocom-bb, since we originally 
only run TTCN3 BTS tests using osmo-bts-virtual with virtphy, see [1] 
for more information. In order to drive all HW and software processes, I 
am using osmo-gsm-tester with specific config and testsuite which you 
can find in osmo-gsm-teser.git/ttcn/. You can find the jenkins job 
running tests with that setup in [2]. The setup is running mostly fine 
but I didn't find time yet to look at the list of tests still failing 
(which doesn't fail with the regular virt TTCN3 setup).

So, as a result, it means we now support using a osmocom-bb capable 
phone using real RF (wired) communicating against already available 
osmo-bts such as osmo-bts-sysmo, osmo-bts-trx, nanobts, etc., so no need 
to add support for osmo-bts-virt and also a way to differentiate 
networks that are not compatible (for instance, you don't want to pick a 
mobile running through virtphy and connecting it to osmo-bts-trx right?).

Current working setup for TTCN3 implies having a motorola phone 
automatically powered on when the corresponding serial device is opened 
(using [3]). So osmo-gsm-tester starts and controls the "osmocon" 
application which opens and uses the serial device. (You can find it in 
./src/osmo_gsm_tester/osmocon.py). In The TTCN3 testcase, we then 
connect TTCN3 code to the L1CTL iface provided by "osmocon", but in your 
case what you want to do I guess is connecting the "mobile" application 
to it.

So what I think it's required in your case:
* Move src/osmo_gsm_tester/modem.py to 
src/osmo_gsm_tester/modem_ofono.py (and class Modem to class ModemOfono
* To make code more easy to follow and extend, create an abstract class 
"Modem" (see class Bts in src/osmo_gsm_tester/bts.py), and make 
ModemOfono inheit from it.
* Create a new class ModemOsmocomLuaMobile (or similar) in a new file 
src/osmo_gsm_tester/modem_osmocom_mobile.py and inherit from 
modem.py:Modem. In there implement all required methods used by Modem 
interface users. To integrate it with the rest of the system you need to:
** Create a Modem "type" system, like we do for BTS (see 
resources.conf.prod how it's used), and add a method similar to 
suite.py:bts_obj() which creates a subclass based on that type, then use 
it in suite.py:modem() (similar to suite.py:bts()).
** Add any new required extra config parameters for this type of modems 
in resource.py:RESOURCES_SCHEMA
** I think to make it compatible with ofono modems, you should start 
both "mobile" and "osmocon" processes in the implementation of your 
Modem class, since the user of the modem class in the tests doesn't need 
to set up a osmocon process based on the type of modem (we do similar 
stuff with osmo-trx in bts_osmotrx.py).

I think that's mostly it. Don't hesitate to ping me here or in IRC if 
you have any question or require some help.

[1] https://osmocom.org/issues/3155
[2] 
https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_ttcn3/
[3] https://wiki.cuvoodoo.info/doku.php?id=osmotoserial

-- 
- Pau Espin Pedrol <pespin at 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



More information about the baseband-devel mailing list