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

Holger Freyther holger at
Thu Jan 3 11:01:39 UTC 2019

> On 30. Dec 2018, at 23:21, Pau Espin Pedrol <pespin at> wrote:
> Hi Holger,

Hey Pau,

thank you for the instant response!

> One can similarly do the same to request allocation of 100 sysmoBTS:
> bts:
> - type: osmo-bts-sysmo
>  times: 100

ah great! That's a good interim solution.

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

+1. Do you have a timeline or open issue for it? Besides the IP pool I have needs for a combined IMSI/MSISDN pool

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

There are two parts to this. The first is convenience API but to me the more important is topology. I would like to build the network based on the suite.conf and in the python code. As a first proposal (but we require a lot more thinking) what about something like:

hlr:                             <- define a HLR. Multiple might be possible
   times: 100000
   pool:                          <- define IMSI/MSISDN pool
     -name: Foo
      imsi_start: XXXX
      msisdn_start: XXXX
      kind: draw_at_random
      times: 10k

msc:                           <- MSCs connecting to it? High level or scope to HLR?
    type: nitb
    bsc:                       <- BSCs connecting to (void if NITB is used)
     times: 5
     -bts:                     <- BTSs
       type: 		       <- ...

virtual_mobiles:	       <- borrowing from the HLRs?       

What we can't do with the above is simulate movements of subscribers (but we can't do that easily right now and can review it if that becomes a genuine requirement). We currently need to hardcode number of hlrs to one but that seems reasonable.

One benefit is that the same test would work for both NITB and BSC/MSC.

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

> 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:

I will give it a try. Please be aware that ARFCNs do not uniquely identify a band.

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

I am thinking of a xpath like command line parameter

--suite_override=hlr[0].bts[all].type=osmo-bts-virtual --suite_override=hlr[0].bts.times=100

what do you think?


More information about the baseband-devel mailing list