> On 6. Mar 2018, at 12:20, Pau Espin Pedrol <pes...@sysmocom.de> wrote:
Hey Neels, Pau,
> I guess you are referring to my comment in . 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).
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
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
From my point of view:
Use the test scenario configuration (maybe even the suite class).
Make the UL test reusable (and extend to SMS and Calls)
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?
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.
Need to add primitive to register a FD so lua can get an answer back.
Find a way to set SO_PASSCRED on the socket to have "mobile" reachable
by the event server as well. Could be a lua binding or we patch lua socket
Have a lua script that forwards the "on/off", "limit to cell XYZ", "Send SMS",
"Place Call", "Open Call and read data from this socket"
Missing primitives for mobile. But we need them anyway.
The middle step is in-reach, the big step will take some real time and I
could use some help (e.g. the event loop integration).
> 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.
The "SIM" card would need to be in the device so IMSI kind of belongs to the