After a lot of work[1] the gsm tester can finally:
* Start a virtual bts
* Mobile/virtphy processes
* Complete LUs for 10 MS.
The next step (besides having a proper test verdict) is scaling this beyond
what a simple physical set-up can provide. Let's go to 100+ BTS and 10k
subscribers but somehow I am still holding it wrongly and would like to have
feedback to see how to evolve the gsm tester.
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)
* 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.
* 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.
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.
* 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.
* 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.
* Configure these capacities from the outside. Changing from 1 to 256 BTS
should be a single line (or even a parameter change).
Any idea or comment on how to achieve this?
cheers
holger
[1] Hindsight is 20/20 and the difficulty was not adding scripting to mobile
but getting the GSM tester to spawn the network and we are unfortunately not
done yet.
