Hi Sebastian, On Sat, Jul 15, 2017 at 05:23:33PM +0200, Sebastian Stumpf wrote: Well, one could always add some kind of helper program/script that takes care of starting the individual tuples of programs, allocating unix domain socket names to it, ... - but rather than investing time in that direction I think it's more elegant the other way around. Yes, this is still the right choice, and I've always argued in favor of multicast sockets. The rationals is that you can start any number of different programs and they can all participate in the simulate RF layer. correct, at least if multiple MS are listening to the same downlink BCCH/CCCH frames. Once they are in dedicated mode, their per-MS state inside virt_phy should filter out all messages that are not for the specific timeslot+subslot (translating to a chan_nr) that their virtual PHY is on. Having multicast "solve" that problem is one way to do it. And yes, the current approach has some beauty to it. It's just on the other hand from the usability point of view, having to configure different unix domain sockets for each pair of { virt_phy, mobile } seems quite clumsy. As stated above, one approach could be to have a launcher that starts both and takes care of allocating a (random) unix domain socket path. Or even have an option where the virt_phy can be fork+exec'ed from "mobile". Maybe those options are actually simpler.. You still want multicast on the GSMTAP layer as you want to have multiple BTSs, and for sure those are going to be separate OsmoBTS processes. There are multiple data structures that look like that separation was intended, but then there are unfortunately some global variables and "layering violations" that entangle them with each other :/ I'm not sure if this is the most "attractive" way of going ahead. It should actually already work right now: Each MS in "mobile" then uses a different /tmp/osmocom_l2 socket, each to a separate virt_phy. This is how it is done with two physical phones in the traditional setup. I'm not planning any immediate work here, as I'm now busy with implementing test cases in TTCN-3. My code there basically simply subscribes to the downlink multicast group and processes the GSMTAP frames to validate the scheduling of various SYSTEM INFORMATION messages, together with dynamically changing configuration over the VTY. Right now I'm looking at interfacing L1CTL from TTCN-3, so one could also establish a dedicated channel from the test cases, which is useful for topics like simulating RACH load and validation of LAPDm (by sending hand-crafted LAPDm frames, rather than using the libosmocore lapdm code). -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)