VirtPHY and many OsmocomBB "mobile" instances

Harald Welte laforge at gnumonks.org
Fri Jul 14 21:54:38 UTC 2017


Hi Sebastian and team,

I've been thinking a bit on how to implement many concurrent OsmocomBB
instances in a setup where we use Sebastian's OsmocomBB virt_phy and
osmo-bts-virtual.

The point of having virtual mobile phones is that you can easily
simulate many.  Many more than you can easily physically manage, so I'm
thinking definitely of hundreds and preferably thousands of MSs.  This
way we can easily simulate load on BTSs, use up all channels, get in
overload situations where we have to reject immediate assignments, etc.

Right now, the data structures in virt_phy are a bit convoluted, and
there is no clear separation between the state of the actual GSMTAP
socket and the MS-specific state attached to one given L1CTL connection.

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.

connection-oriented unix domain sockets can very well handle multiple
connections (similar to a single TCP server being able to acccept many
incoming connections).  So if the MS-specific state (like the scheduler
/ L1CTL related state) is properly separated from the GSMTAP side, any
number of "mobile" programs (or other L1CTL users) could actually
connect to the same virt_phy program and share it.

Do you think this is worth it?  I would really like the idea of just
having to start one program, and not having to configure each "mobile"
instance with a different l1sap socket name, manage to close the
processes vice-versa, etc.

Theoretically one could stay in the current 1:1 model, but I somehow
find 1:N more appealing.

Regards,
	Harald
-- 
- 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)


More information about the baseband-devel mailing list