> 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 
resource?


Reply via email to