> On 30. Dec 2018, at 23:21, Pau Espin Pedrol <[email protected]> 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
>> * 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.
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
-subs:
times: 100000
pool: <- define IMSI/MSISDN pool
-name: Foo
imsi_start: XXXX
msisdn_start: XXXX
kind: draw_at_random
times: 10k
hlr:
...
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?
holger
