Scaling up virtual bts tests for the BTS test - how I hold it wrong?

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/.

Pau Espin Pedrol pespin at sysmocom.de
Sun Dec 30 23:21:54 UTC 2018


Hi Holger,


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 
osmo-gsm-tester/suites/gprs/suite.conf:

   modem:
   - times: 2
     features:
     - gprs
     - voice

One can similarly do the same to request allocation of 100 sysmoBTS:

bts:
- type: osmo-bts-sysmo
   times: 100


> 
> * 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 
osmo-gsm-tester/example/scenrios/mod-bts0-*.conf

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:

[suite.conf]
resources:
   ip_address:
   - times: 4 #or as much as needed
   bts:
   - band: GSM-1800
     times: 2
   - band: GSM-900

modifiers:
   bts:
   - 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.


Regards,
Pau
-- 
- 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 mailing list