Project

General

Profile

Bug #3510

Make sure the ECU (Error Concealment Unit) is working correctly

Added by fixeria over 1 year ago. Updated 7 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
08/29/2018
Due date:
% Done:

0%

Spec Reference:

Description

In 69d0d506775c82eb2bde66fe748100a94a3173a0 "osmo-bts-trx: perform error concealment for FR frames",
the ECU (Error Concealment Unit) was introduced. In short, if one (or more) speech frame is lost,
one may experience some unpleasant audio effects. The ECU is used to avoid such effects.

While working on audio support in OsmocomBB, I have discovered that the libosmocoding API
actually produces decoded speech frames in RTP format, and I guess the ECU implementation
may expect speech frames in canonical format.

I think it makes sense to:

  • clarify, which frame format is expected by the libosmocodec's ECU FR implementation?
    • add some comments there (I couldn't find any);
  • manually test with a regular phone (by dripping TCH bursts somehow);
  • add some TTCN-3 testing coverage;

History

#1 Updated by laforge about 1 year ago

  • Assignee set to tnt

#2 Updated by tnt 7 months ago

The RTP order and "canonical order" are the same (and different from the order "on-the-air" where bits are priority shuffled).
Only difference is the "marker" in the first 4 bits, but we never use the canonical format anywhere.

The ECU takes a frame in RTP payload format for sure and AFAICT it works and it has a test included in libosmocore.

#3 Updated by tnt 7 months ago

fixeria I submitted https://gerrit.osmocom.org/c/libosmocore/+/14051 to improve the documentation.

Other than that, AFAICT the ECU works "fine" (i.e. as I understand GSM 06.11)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)