15 Jul
2017
15 Jul
'17
5:23 p.m.
Hi Harald,
that is great news. First of all, thank you for taking the time to cleanup
and merging the virt-phy. I really appreciate that.
You have a point. The virtual layer's usability would greatly increase
when it supports more than a few concurrent MSs.
So if you want to run multiple MS, it seems currently
one would have to
run multiple pairs of { virt_phy, mobile }, one pair for each MS. This
leads to a rather large set of processes, and all have to process their
own copy of the same UDP messages received on the multicast socket.
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...
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. As this decision is often done by upper layers,
that are implemented in layer2/3, the messages have to be forwarded to the
mobile app. For example, RR has to check if a paging message is for me or not.
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. 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?
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.
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.
Kind Regards,
Basti