Project

General

Profile

Feature #2760

osmo-gsm-tester: Add support for several (osmo-)trx to OsmoBtsTrx

Added by pespin about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
12/15/2017
Due date:
% Done:

0%

Spec Reference:

Description

Right now we only have 2 TRX support for OctoBTS, and we are actually not using it yet

We need to find out which is the best way to implement the API to select and use several TRX depending on the test.
See https://gerrit.osmocom.org/#/c/4674/ for related discussion. Summary: Have a generic BTS API with something like set_enabled_trx(NUM), get_enabled_trx(), which sets a enabled_trx variable which is used at conf_for_bsc() time to only pass "enabled_trx" amount of trx in trx_list. This can be configured by default too using a "enabled_trx" config option for each bts in resources.conf.

We also lack multiple TRX support in osmo-bts-trx. It should not be difficult to add support for it. We basically require to launch a new osmo-trx process (if launch_trx option is enabled) for each TRX configured.

We can then look at bts_octphy.py to see which code we can share/merge (move into OsmoBtsMainUnit) that handles several TRX. Octphy has some specific constrains so we may not be able to share everything, as it requires to set up the phys and instances in a given way depending on hw_addr.


Related issues

Related to OsmoGSMTester - Bug #2761: osmo-gsm-tester: add test case: Test 2nd trx is correctly used New 12/15/2017

History

#1 Updated by pespin about 1 month ago

  • Related to Bug #2761: osmo-gsm-tester: add test case: Test 2nd trx is correctly used added

#2 Updated by laforge about 1 month ago

On Fri, Dec 15, 2017 at 12:30:47PM +0000, pespin [REDMINE] wrote:

We also lack multiple TRX support in osmo-bts-trx.

I presume you want to say "in the osmo-gsm-tester support for osmo-bts-trx" ?

It should not be difficult to add support for it. We basically require
to launch a new osmo-trx process (if launch_trx option is enabled) for
each TRX configured.

The normal method used so far AFAIK is to run two soft-TRXs within one
osmo-trx instance. This will create two ARFCN carriers inside the
spectrum of the USRP. That's what the "-c 2" option of osmo-trx would
do. This is similar to osmo-bts-lc15 or osmo-bts-octphy where we run
two phy_instances in one phy_link.

I'm not sure if the "run one phy_instance in each phy_link of two
separate osmo-trx instances" would work without significant changes to
osmo-trx, whcih I believe is out of scope here.

#3 Updated by pespin about 1 month ago

laforge wrote:

On Fri, Dec 15, 2017 at 12:30:47PM +0000, pespin [REDMINE] wrote:

We also lack multiple TRX support in osmo-bts-trx.

I presume you want to say "in the osmo-gsm-tester support for osmo-bts-trx" ?

yes of course :-) I was writing that having osmo-gsm-tester context in mind.

The normal method used so far AFAIK is to run two soft-TRXs within one
osmo-trx instance. This will create two ARFCN carriers inside the
spectrum of the USRP. That's what the "-c 2" option of osmo-trx would
do. This is similar to osmo-bts-lc15 or osmo-bts-octphy where we run
two phy_instances in one phy_link.

I'm not sure if the "run one phy_instance in each phy_link of two
separate osmo-trx instances" would work without significant changes to
osmo-trx, whcih I believe is out of scope here.

Ah thanks for the clarification, I wrote everything from what I remembered at the time off the top of my head. Then supporting it (several phy instances per phy device) should be easier than expected then. Let's target for that one then. However, I'm not sure if we actually have any osmo-trx devices that works with more than 1 trx. AFAIK sysmocell5000 doesn't support ore than 1, and same goes for B200. The LimeSDR (not the mini one) theoretically could support 2 TRX.

#4 Updated by laforge about 1 month ago

On Fri, Dec 15, 2017 at 02:46:01PM +0000, pespin [REDMINE] wrote:

However, I'm not sure if we actually have any osmo-trx devices that
works with more than 1 trx. AFAIK sysmocell5000 doesn't support ore
than 1, and same goes for B200. The LimeSDR (not the mini one)
theoretically could support 2 TRX.

Correct for sysmoCell 5000. But for B200 and Lime:

I'm sometimes surprised where you get come up with those
assumptions/presumptions ;) This is not a rhethoric question! I'm
really curious, where you found that information, because it's wrong.
So let's try to find the source of this and fix it to avoid other people
drawing the same conclusions.

osmo-trx has had two-TRX suport on USRPs since.. I think forever. Even
OpenBTS Transceiver from which it is inherited had the feature, AFAIR. At
least the "-c" option was already present in the first commit in 2011,
so I assume it was already working back then.

Also, why would LimeSDR and LimeSDR mini be different? It's the same
transceiver chip, isn't it?

#5 Updated by pespin about 1 month ago

laforge wrote:

Correct for sysmoCell 5000. But for B200 and Lime:

I'm sometimes surprised where you get come up with those
assumptions/presumptions ;) This is not a rhethoric question! I'm
really curious, where you found that information, because it's wrong.
So let's try to find the source of this and fix it to avoid other people
drawing the same conclusions.

It's more like the opposite: I don't remember reading any information in any place stating that 2 TRX are supported, and I don't remember neither hearing about somebody operating it with more than 1 TRX, so my assumption is that it's most probably not supported, but I see I assumed wrong in this case :-)

Also, why would LimeSDR and LimeSDR mini be different? It's the same
transceiver chip, isn't it?

I recall seeing it when doing a quick look at https://www.crowdsupply.com/lime-micro/limesdr-mini (search for "Comparison Table"). It states LimeSDR has 2 TX and 2 RX channels while for LimeSDR Mini it states 1+1. Did I understand that information incorrectly?
Actually, now that I look closer at it, it seems to be that Ettus B200 supports only 1 while Ettus B210 supports 2.

#6 Updated by laforge about 1 month ago

On Fri, Dec 15, 2017 at 10:01:05PM +0000, pespin [REDMINE] wrote:

Also, why would LimeSDR and LimeSDR mini be different? It's the same
transceiver chip, isn't it?

I recall seeing it when doing a quick look at https://www.crowdsupply.com/lime-micro/limesdr-mini (search for "Comparison Table"). It states LimeSDR has 2 TX and 2 RX channels while for LimeSDR Mini it states 1+1. Did I understand that information incorrectly?
Actually, now that I look closer at it, it seems to be that Ettus B200 supports only 1 while Ettus B210 supports 2.

The count of physical connectors on a given board has absolutely no relationship to the question
of how many individual GSM RF carriers you are putting on it.

Let's say you have a 5 MHz wide transmit/receive band at the ADC/DAC of
your SDR. Within those 5 MHz you can put a number of the only 270kHz
wide GSM carriers. In theory up to 9 non-overlapping ARFCNs (i.e. with
one ARFCN space in between), but that's unrealistic/impractical for a
large number of other factors, last but not least computational
complexity.

Also available in: Atom PDF