MS driver: GSM tester config integration

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/OpenBSC@lists.osmocom.org/.

Pau Espin Pedrol pespin at sysmocom.de
Wed Mar 7 17:22:42 UTC 2018


Hi Holger,

> thanks to both of you for the detailed responses. I like the idea, it
> solves the coordination between setting up the core network and the
> phones. The approach looks generally feasible and I wish we had this
> idea earlier.
> 
> Unfortunately I had only planned to do LUA bindings, the orchestration
> was already an extra and I blew all my time in trying to make asyncio
> work and the scaling/concurrency issues with python. My intention with
> the original mail was to find a middle step. Better integration but
> not full.
> 

I know some of the concepts in osmo-gsm-tester are quite complex to 
grasp (lots of specific stuff like scenarios, resources, etc.), and some 
of the required stuff is still missing (like better poll loop, managing 
arfcns, etc. we have tasks created for them). As it's quite a bit amount 
of work and it was not your primary focus, I don't expect to have 
everything done in one step. Merging it as a separate env then slowly 
moving it into osmo-gsm-tester seems fine for me.
Personally I was also lacking a better understanding on how mobile 
operates and the resulting work of the lua bindings, as I didn't play 
with it yet. Seeing your patches helped me a lot understanding better 
what is there and where can we go from this first step.

> 
> Middle step:
> 
>   Use the test scenario configuration (maybe even the suite class).
> 
>   Make the UL test reusable (and extend to SMS and Calls)

What do you mean with reusable here? Can you explain it a bit more? Do 
you mean being able to use other Modem implementations? I agree with that.

> 
> 
> Big step (as proposed):
> 
>   The "scheduling"/slow start is not like any of the existing tests (there
>   are conceptual difference of fail/pass handling when launching 10k procs)
> 
>   The event loops need to be integrated. Not sure how to integrate this with
>   glib loop for glib-dbus?

I think the best would be having our own loop, which then also polls 
glib loop in the process. As far as I remember glib provides APIs to get 
poll notifications (via fd?) in case an event from them is triggered. If 
I recall correctly EFL libs have APIs to do that for apps which want to 
run efl+glib at the same time.Probably Qt guys do the same.

Other possibility would be to have our own loop which is internally 
implemented using glib one.

Having a better loop was not a hard requirement until now because we 
were fine without fine-grained time lapses and just active polling every 
0.1 seconds, but I'd really like having a better loop.

I'll try to find some time in next days to have a look at improving the 
current event loop.

> 
>   A base class for a MS (or ME) without being ofono specific and simple enough.
>   Currently the lua JSON code is only from MS->Test. 

I can help you with that, given that you provide all the lua specific parts.


> The "SIM" card would need to be in the device so IMSI kind of belongs to the resource?

An IMSI belongs to the resource, but the generator itself can be used in 
different tests. The IMSI field in the Modem resource is there for 
historical reasons (for instance if you'd like to force a specific IMSI 
by default), but we should rework ModemOfono to get the IMSI from 
ofono/dbus instead, since we are finally not using the IMSI to identify 
the modems but its sysfs path.

-- 
- 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 OpenBSC mailing list