Scaling up virtual bts tests for the BTS test - how I hold it wrong?
Pau Espin Pedrol
pespin at sysmocom.de
Sun Dec 30 23:21:54 UTC 2018
On 12/30/18 4:26 PM, Holger Freyther wrote:
> What do I need to change to scale this up and how to externally parameterize it?
> * suite.conf:
> Add one line per virtual bts to reserve (I would prefer to specify type+num)
You can already do that, by using the "times" attribute for each object
in suite.conf. See for instance what's done in
- times: 2
One can similarly do the same to request allocation of 100 sysmoBTS:
- type: osmo-bts-sysmo
> * resources.prod.conf:
> Add more Virtual BTS. I started to pick IPs from 127.0.1.0/24 as it avoids having to configure special IPs.
I'd like to be able to specifcy pools of objects in resources.conf so we
don't need to add 1 line per object there. In the case of IP addresses,
specifying a subnet range and let osmo-gsm-tester to expand that into a
set of objects at runtime.
> * register_default_mass.py:
> I need to somehow know how many BTS (and NITBs) were reserved. Or in the long run the topology of how to connect M BTS to N BSCs? Currently I can run until I get an exception but that is not desirable.
Yeah for now the way to do it is to ask for one until you get the
specific exception thrown when there's no more objects of that type or
matching the specifications. Fine for me to add more APIs to fetch this
kind of information more easily.
> What's missing:
> * High-level API of the SuiteRun to get me the toplogy of the network. It seems undesirable in the specific suite to discover how many BTSs were reserved in suite.conf or what the topology is.
See my last text above.
> * ARFCN usage. Besides the redundancy all my BTS currently have the same ARFCN. There should be an easy way to configure an band+arfcn pool.
There's a task for that, see https://osmocom.org/issues/2230.
Unfortunately the algorithm to allocate ARFCN from available ones is a
bit complex (lots of restrictions) and wasn't really required so far, so
it's not yet implemented.
As a workaround, you may want to add a modifier for ARFCN, similar to
what is already done for other variables in
So you could specify manually a different ARFCN for each bts (number of
elements in object modifiers must match number of elements in the
resources in suite.conf). Let's say you want 3 BTS with 3 differnet
arfcn, 2 of them in 1800 band and 1 in 900 band:
- times: 4 #or as much as needed
- band: GSM-1800
- band: GSM-900
- arfcn: 868
- arfcn: 870
- arfcn: 124 # or whatever is valid for GSM900
* Band attribute should actually be reworked to be a list of supported
bands for that BTS, then each BTS in resources.conf have a list with all
bands supported by that BTS.
* I don't think arfcn modifier is there yet, but not sure now. Grep for
"modifier" in suite.py and resource.py to see how it is implemented.
> * IMSI/MSISDN pooling. I would like to specify pools of IMSI/MSISDN pairs (and size) and then draw from it. I needs these to program into the mobile, NITB/HLR/AuC and for client to client SMS transfers.
See my comments regarding IP addr pools. Fine for me, but I'm not sure
if its needed in this case, since there's already methods to allocate
sequentially incrementing MSISDN and IMSI.
> * Configure these capacities from the outside. Changing from 1 to 256 BTS should be a single line (or even a parameter change).
Unfortunately these kind of capacities are so far fixed by the
suite.conf. If you want to do tests with different numbers, you can
manually change the "times" attribute in there, or put a big number and
only use a subset of them when running the test in the suite.
- Pau Espin Pedrol <pespin at sysmocom.de> http://www.sysmocom.de/
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
More information about the baseband-devel