osmo-gsm-tester[master]: bts: Allow setting amounf of TRX and timeslot in cfg and fro...

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/gerrit-log@lists.osmocom.org/.

Pau Espin Pedrol gerrit-no-reply at lists.osmocom.org
Tue May 8 13:49:01 UTC 2018


Patch Set 1:

> sorry, I still don't get it. A practical example?
 > 
 > BTS Foo has 2 trx. Its resources say it has 2 trx. Done?

What do you mean by "has" in here? It can provide up to 2 TRX (max_trx=2) or it configures+enables 2 TRX (num_trx=2)? num_trx is the amount of TRX which are going to be configured+enabled. So by default it's 1. Any test willing to do stuff with more than 1 TRX can programatically request to configure+enable more.

num_trx is not expected to be used by scenarios/suites. It's more like the default amount value to use if the test doesn't request a specific amount of TRX.

 > 
 > If I configure a scenario to require two TRX, how would it ever
 > pick by accident a BTS that has one TRX, if num_trx is 1 and I
 > requested 2?

For HW selection/filtering, what you'd actually want to match against max_trx, which is the maximum supported TRX (to make sure you can enable and use them). But anyway that's one of the problematics on trying to match using all these dictionaries, it's a bit limited. You cannot match for something lesser-equal or greater-equal to a value. I mean, if you require 2 TRX for a test, and you have a BTS with max_trx=3, asking for a BTS with max_trx=2 won't return the match.

So probably the best here if you want to test stuff with more than 1 TRX is to simply use a scenario to match against a specific class of BTS which supports more than 1 TRX.

Another solution would be to have a "supported_trx" attribute which would be a list with all the possible values that the num_trx could have, ie. for max_trx=3 -> supported_trx: [1,2,3]. Then we could match it.

max_trx helps mostly at runtime to easily crosscheck that you aren't picking a wrong BTS (one which doesn't support that many TRX). It's also a way to easily remind how many TRX a BTS supports.

 > 
 > What would be a situation where num_trx != max_trx?

an octphy BTS supports 2 TRX (actually 4, but not in our current license/verified setup). That means it has max_trx=2, because it is known to work with up to 2 TRX.

For most tests, we don't need 2 TRX, thus we don't need to require a specific num_trx, which means num_trx=1 will be used. That's fine, as octphy has max_trx=2.

However, let's say we pick up a sysmo bts, which supports only 1 TRX (max_trx=1). Imagine I want to run a test which actually requires 2 TRX (programatically does: bts.set_num_trx(2)). osmo-gsm-tester will stop straighway giving you a clear message that you are doing something wrong, since you are trying to run a test which attempts to use 2 TRX with a BTS which only supports 1.

-- 
To view, visit https://gerrit.osmocom.org/8061
To unsubscribe, visit https://gerrit.osmocom.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I7f46eaf7a16f03268653299c93600c0443f691ac
Gerrit-PatchSet: 1
Gerrit-Project: osmo-gsm-tester
Gerrit-Branch: master
Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-HasComments: No



More information about the gerrit-log mailing list