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/baseband-devel@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi Sebastian,
On Sat, Jul 15, 2017 at 05:23:33PM +0200, Sebastian Stumpf wrote:
> Your assumption is correct, currently you need indeed a pair of
> {virt_phy, mobile} for each connected MS instance. I really like the idea
> with the 1-to-n relation and I think it is worth implementing.
> Especially regarding the load
> testing usecase. Currently setting this up is probably not so fun...
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.
> I also thought about it back then, but had no concrete idea how to implement it.
> Currently, we use a multicast client socket to receive messages on the
> downlink of the virt_phy. So each virt_phy instance will receive all
> messages on the downlink, like on the "real" air interface and has to
> decide by itsself if it wants to process it or not.
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.
> > connection-oriented unix domain sockets can very well handle multiple
> > connections
>
> Now if we have only one instance of virt_phy connected to multiple instances
> of "mobile", received messages on the virt_phy still have to be broadcasted to
> all "mobile" instances somehow. So if you have multiple TCP-connections on the
> L1CTL-socket, you would still have to broadcast the messages to them.
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..
> I thought this is why we used the multicast socket, but it seems as if
> it is used at the wrong place then. Because if we only have one
> virt-phy instance, the GSMTAP_socket would not need to be a multicast
> socket, am I right?
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.
> > So if the MS-specific state (like the scheduler / L1CTL related
> > state) is properly separated from the GSMTAP side
>
> I think we need an own physical state for each connected L1CTL socket
> then. Currently the MS physical state is not properly separated from
> the GSMTAP socket state. That's true.
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 :/
> As I know, mobile can also be configured to configure multiple MS instances.
> I already tried to use this (https://github.com/osmocom/osmocom-bb/blob/master/
> src/host/virt_phy/example_configs/osmocom-bb-mobilex2.cfg), but had some
> problems with receiving and sending messages over the virt-phy. One of the MS's
> usually stalled after a time I think. Maybe this can also be used to
> have only one instance of mobile and virt-phy to simulate multiple MSs
> in the end.
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 at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)