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/.
Sebastian Stumpf sebastian.stumpf87 at googlemail.comHi 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