> On 6. Mar 2018, at 12:20, Pau Espin Pedrol <pes...@sysmocom.de> wrote:
> Hi,

Hey Neels, Pau,

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

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.

From my point of view:

Middle step:

 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 

Reply via email to