Project

General

Profile

Bug #4823

osmo-bts-trx sends dummy bursts (instead of BFI) in the absence of RTP frames

Added by fixeria 12 months ago. Updated 2 months ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
10/21/2020
Due date:
% Done:

40%

Spec Reference:

Description

While working on TC_meas_res_speech_{tchf,tchh,tchh_toa256} as a part of #4799, I noticed that osmo-bts-trx logs the following:

DL1P INFO sched_lchan_tchf.c:539 001477/01/21/49/41 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.
DL1P INFO sched_lchan_tchf.c:539 001482/01/00/03/46 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.
DL1P INFO sched_lchan_tchf.c:539 001486/01/04/07/50 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.
DL1P INFO sched_lchan_tchf.c:539 001490/01/08/11/02 (bts=0,trx=0,ts=1) TCH/F: No TCH or FACCH prim for transmit.

and transmits dummy bursts on active TCH channels. This of course causes decoding errors on the MS side (trxcon):

20201019024408686 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1788 for TCH/F
20201019024408704 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1792 for TCH/F
20201019024408727 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1797 for TCH/F
20201019024408746 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1801 for TCH/F
20201019024408764 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1805 for TCH/F
20201019024408787 DSCHD ERROR sched_lchan_tchf.c:127 Received bad TCH frame ending at fn=1810 for TCH/F

I would expect the BTS to send Bad Frame Indications instead. Imagine a situation when for some reason one or more MT RTP frames get lost during a voice call. On the MS side this would look like an RF failure.

Associated revisions

Revision 2308b582 (diff)
Added by fixeria 4 months ago

trxcon/scheduler: unify and enrich decoding error messages

Regarding the removal of burst_mask2str() from the TCH/H handler,
it does not make sense to print it because the mask is already
shifted and an earlier logging should already contain this info.

Change-Id: I42d20e2da73c21ca366dd246244cd716c8ccb459
Related: OS#4823

Revision c485901d (diff)
Added by fixeria about 2 months ago

osmo-bts-trx: send dummy FACCH in the absense of RTP frames

If for whatever reason the transmit queue of a TCH/{F,H} contains
neither speech frames nor signalling blocks, osmo-bts-trx would
currently transmit garbage. Of course, this causes decoding
errors at the MS side.

Ideally, we should employ an ECU (Error Concealment Unit) for the
given codec in use. However, a simpler solution is to transmit
dummy LAPDm frames over FACCH. This is what e.g. nanoBTS does.

Change-Id: I868afecbcb6890f40c8f146e3ce00e836b794dd3
Related: OS#4823

History

#1 Updated by fixeria 12 months ago

I would expect the BTS to send Bad Frame Indications instead.

Alternatively, a) the BTS may send dummy FACCH frames ('0303012B2B2B...'O), so the MS would substitute them with BFIs itself; or b) we can run additional ECU instance for the Downlink path (we already have it on the Uplink direction), so the missing frames would not cause unpleasant sound effects.

laforge what do you think?

#2 Updated by fixeria 12 months ago

  • Status changed from New to Feedback

I've submitted two TTCN-3 test cases demonstrating the problem:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/20810 BTS_Tests: introduce TC_speech_no_rtp_{tchf,tchh}

At least for now, we can verify that whatever is sent by the BTS can be decoded on the MS side without CRC errors.

#3 Updated by laforge 12 months ago

On Tue, Oct 20, 2020 at 08:08:51PM +0000, fixeria [REDMINE] wrote:

Alternatively, a) the BTS may send dummy FACCH frames ('0303012B2B2B...'O), so the MS would substitute them with BFIs itself; or b) we can run additional ECU instance for the Downlink path (we already have it on the Uplink direction), so the missing frames would not cause unpleasant sound effects.

  • FACCH sounds like a hack
  • ECU instance or actively sending BFI makes more sense, IMHO

Would be interesting so see what proprietary BTSs do in these situations. For Abis/IP,
that would be nanoBTS. But the same situation can of coruse happen in Abis/E1 with classic
BTS: Some TRAU Frames can also be missing in downlink, and the BTS still must be transmitting
something on the downlink.

#4 Updated by fixeria 10 months ago

Would be interesting so see what proprietary BTSs do in these situations. For Abis/IP, that would be nanoBTS.

A quick experiment shows that nanoBTS is sending a dummy FACCH frame in all cases, except when AMR is in use.
In the later case I see some speech frames that all look like BFIs, not sure though.

#5 Updated by fixeria 8 months ago

  • Status changed from Feedback to Stalled

#6 Updated by fixeria 4 months ago

  • Status changed from Stalled to In Progress

#7 Updated by fixeria 4 months ago

  • % Done changed from 0 to 40

Here is a quick and simple solution (better than nothing):

https://gerrit.osmocom.org/c/osmo-bts/+/24846 osmo-bts-trx: send dummy FACCH in the absense of RTP frames [NEW]

Unfortunately, this is not enough to make BTS_Tests.TC_speech_no_rtp_{tchf,tchh} happy. The problem is that trxcon generates Bad Frame Indications in place of frames stolen by FACCH, and the test logic interprets this as decoding errors. So we still need to fix trxcon and/or the test expectations.

#8 Updated by fixeria 2 months ago

  • Status changed from In Progress to Stalled

As was requested during code review, I updated the commit message.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)