Project

General

Profile

Actions

Bug #4823

closed

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

Added by fixeria over 3 years ago. Updated 9 months ago.

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

100%

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.


Related issues

Related to OsmoBTS - Bug #6049: TRX version transmits dummy FACCH instead of proper downlink BFIsResolvedjolly05/31/2023

Actions
Actions #1

Updated by fixeria over 3 years 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?

Actions #2

Updated by fixeria over 3 years 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.

Actions #3

Updated by laforge over 3 years 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.

Actions #4

Updated by fixeria over 3 years 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.

Actions #5

Updated by fixeria about 3 years ago

  • Status changed from Feedback to Stalled
Actions #6

Updated by fixeria over 2 years ago

  • Status changed from Stalled to In Progress
Actions #7

Updated by fixeria over 2 years 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.

Actions #8

Updated by fixeria over 2 years ago

  • Status changed from In Progress to Stalled

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

Actions #9

Updated by fixeria almost 2 years ago

  • Status changed from Stalled to In Progress
Actions #10

Updated by fixeria almost 2 years ago

Dummy FACCH/H scheduling was not implemented correctly, fixed in this patchset:

https://gerrit.osmocom.org/c/osmo-bts/+/27802 osmo-bts-trx: move tx_tch_common() into a separate file [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/27803 osmo-bts-trx: de-duplicate generation of BFI TCH frames [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/27804 osmo-bts-trx: prioritize FACCH in s/tx_tch_common()/tch_dl_dequeue()/s [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/27805 osmo-bts-trx: fix scheduling of dummy FACCH/H and FACCH/F [NEW]

Actions #11

Updated by fixeria almost 2 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 40 to 80

After getting some useful feedback, I decided to abandon the following patches:

https://gerrit.osmocom.org/c/osmo-bts/+/27802 osmo-bts-trx: move tx_tch_common() into a separate file
https://gerrit.osmocom.org/c/osmo-bts/+/27803 osmo-bts-trx: de-duplicate generation of BFI TCH frames

updated the old patches and submitted a new patchset:

https://gerrit.osmocom.org/c/osmo-bts/+/27804 osmo-bts-trx: prioritize FACCH in s/tx_tch_common()/tch_dl_dequeue()/s
https://gerrit.osmocom.org/c/osmo-bts/+/27835 osmo-bts-trx: tx_tchh_fn(): make handling of FACCH/H cleaner [NEW]
https://gerrit.osmocom.org/c/osmo-bts/+/27805 osmo-bts-trx: fix scheduling of dummy FACCH/H and FACCH/F
https://gerrit.osmocom.org/c/osmo-bts/+/27836 osmo-bts-trx: check if scheduling of [dummy] FACCH/H is allowed [NEW]

Actions #12

Updated by fixeria almost 2 years ago

  • % Done changed from 80 to 100

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986 BTS_Tests: fix expectations in TC_speech_no_rtp_tch[fh] [NEW]

Actions #13

Updated by falconia 10 months ago

In the classic E1-based GSM architecture the counterpart condition to OsmoBTS lacking RTP input for DL would be the E1-based BTS receiving an idle speech frame of TS 48.060 section 5.4 (further detail in section 5.5.5) in the place of a valid speech frame (section 5.1) on Abis DL. TRAUs normally don't allow this condition to happen, even in TFO, at least per the spec. In the case of TFO (the codec frame stream ultimately comes from UL of call leg A that will contain BFIs) TS 28.062 section C.3.2.1.1 tells TRAU implementors to essentially replicate the logic of the Rx DTX handler, including both ECU and comfort noise generator parts, but I am very uncertain if real TRAU implementations actually do what that spec section says. (I repeat my solicitation for someone to connect a real historical T1/E1 TRAU to OCTOI so I can experiment with it remotely.) I am so uncertain about real TRAUs implementing the rules of C.3.2.1.1 in their entirety because although they are relatively easy to implement for FR and HR, doing the same for EFR seems insanely difficult to me. Hence I wonder if perhaps real implementations relax those rules a little at least for EFR, or maybe even for all 3 codecs. My idea of "relaxed" implementation is to forward non-DTX-related (not after SID) BFIs to call leg B by inducing a deliberate BFI condition on the DL (send an idle speech frame of TS 48.060 section 5.4), and in the case of SIDs in input do what I did in just-merged I924ab21952dcf8bb03ba7ccef790474bf66fc9e5. The advantage of this approach is that it's very easy to implement and works exactly the same for all 3 non-AMR codecs.

OK, so what does the BTS part of E1-based GSM architecture do when it receives an idle speech frame (missing frame indicator) on Abis DL? The answer to this question is also what our BTS models should do when they receive empty TCH.req from l1sap - our l1sap-to-model internal interface is logically equivalent to E1 Abis. Not having any E1 BTS hw to experiment with, I'll go with my intuition, which tells me that we should transmit a bit pattern that will not cause any errors in the MS at the level of convolutional decoding, but will induce a BFI condition in the Rx DTX handler. In the case of FR, HR and EFR codecs the easiest way to do so is to transmit a speech frame with inverted CRC3 at the GSM 05.03 encoding level, and this approach is also what sysmoBTS PHY does. I have a patch in review that implements this behavior in osmo-bts-trx:

https://gerrit.osmocom.org/c/osmo-bts/+/33069

I will be updating that patch to resolve the recently arisen merge conflict and to address review suggestions from fixeria, but the principal idea remains the same.

Please note, however, that my solution addresses FR, HR and EFR codecs only. What is the correct solution for AMR? Answer: I don't know. In case you haven't already figured out, I am the kind of developer who believes in doing things right, not a quick hack, and my current thorough understanding of FR, HR and EFR codecs is a result of having spent months studying the subject and getting hands-on experience implementing codec libraries, debug tools and a network edge transcoder to G.711 PSTN. I do not currently have the cycles to study AMR to the same level of depth, and thus my stance on AMR specifics will, for now, be to not initiate any behavioral changes to any Osmocom components in AMR modes and abstain from comment on AMR-specific parts of changes proposed by other developers.

Actions #14

Updated by fixeria 9 months ago

fixeria wrote in #note-7:

[...] 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.

trxcon has meanwhile been fixed, so that it does not craft dummy TCH frames on its own, but send empty TRAFFIC.ind:

https://cgit.osmocom.org/osmocom-bb/commit/?id=fd8962e89144fb0af4b99199589d9f9768804640

I also replicated the behavior of sending invalid speech frames with inverted CRC3, like in osmo-bts:

https://cgit.osmocom.org/osmocom-bb/commit/?id=0cfd0bbe801d86e1a3cbc08b228f9ad2521ebd08

Actions #15

Updated by fixeria 9 months ago

  • Status changed from Feedback to Resolved

fixeria wrote in #note-12:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986 BTS_Tests: fix expectations in TC_speech_no_rtp_tch[fh] [NEW]

These two testcases are currently passing due to a bug in the BFI template definition. They would be passing even if the IUT would be sending dummy bursts or sending nothing at all, because they were designed to fail on receipt of a never-matching TRAFFIC.ind template. This patch fixes the problem and aligns their expectations with the current behavior of osmo-bts:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/27986 BTS_Tests: fix expectations in TC_speech_no_rtp_tch[fh]

Additionally I extended TC_speech_no_rtp_tchf to verify TCH/EFS and added some TODOs about TCH/A[FH]S:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33725 BTS_Tests: also test TCH/EFS (EFR) in TC_speech_no_rtp_tchf

The updated testcases are passing: we're getting empty TRAFFIC.ind with bad CRC but no bit errors, as expected. I think we can close this ticket and create a separate one for tracking the state of TCH/A[FH]S. Thanks for your contributions, falconia!

Actions #16

Updated by fixeria 9 months ago

  • Related to Bug #6049: TRX version transmits dummy FACCH instead of proper downlink BFIs added
Actions #17

Updated by fixeria 9 months ago

fixeria wrote in #note-15:

I think we can close this ticket and create a separate one for tracking the state of TCH/A[FH]S.

Oh, I didn't notice there was another ticket about this problem #6049. Let's then track the AMR problem there.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)