Project

General

Profile

Actions

Bug #4364

open

osmo-bts-trx configured with 2 TRX and osmo-trx with 1 TRX -> bad behavior

Added by pespin about 4 years ago. Updated over 3 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
01/14/2020
Due date:
% Done:

0%

Spec Reference:

Description

Configure osmo-bsc + osmo-bts-trx to run with 2 TRX, and osmo-trx to run with only one TRX (chan 0).

Current behavior: the network runs fine (of course only using TRX0) and osmo-bts is lots of times per second printing the error message:

20200114161445605 DTRX <000b> trx_if.c:1110 phy0.1: send() failed on TRXD with rc=-1 (Connection refused)

So there seems to be several flaws here:
  • If that log line is printed, it means the TRX1 is seen as ON (trx_if_powered(l1h) is returning true), but it's not since osmo-trx doesn't use it, so it shouldn't be on
  • Upon that failure, osmo-bts-trx should either: A) continue running but tell BSC over OML that the TRX is down, or B) stop the process (exit).
Actions #1

Updated by pespin almost 4 years ago

The second point on the task description has already been fixed since a while ago (bts exits now). I still need to look at what's the current status for the first point.

Actions #2

Updated by fixeria almost 4 years ago

If that log line is printed, it means the TRX1 is seen as ON (trx_if_powered(l1h) is returning true), but it's not since osmo-trx doesn't use it, so it shouldn't be on

Ah, there is an interesting detail. In a multi-trx setup POWERON/POWEROFF commands are sent only to the first transceiver (TRX0), not to all TRX1..N. That's why osmo-bts-trx thinks that your second transceiver is powered on. There's basically no way to know on the BTS side how many transceivers are actually enabled in osmo-trx. But still... osmo-bts-trx sends RXTUNE/TXTUNE and SETSLOT commands to each transceiver individually, and obviously it would not get any response for TRX1..N in your case.

Actions #3

Updated by fixeria almost 4 years ago

Upon that failure, osmo-bts-trx should either: A) continue running but tell BSC over OML that the TRX is down

I think A) is the correct approach. This is what the A-bis specifications require us to do.

Actions #4

Updated by pespin over 3 years ago

I started by sanitizing the code by using an FSM. From there, we can start adding states or query state of other TRXs:
https://gerrit.osmocom.org/c/osmo-bts/+/19167 bts-trx: introduce TRX provisioning FSM

We can now more easily for instance have a "trx_if_powered()" well implemented really per trx and not per phy_link.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)