Project

General

Profile

Bug #4823

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

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

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

0%

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.

History

#1 Updated by fixeria about 1 month 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 about 1 month 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 about 1 month 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)