Attention is currently required from: laforge, pespin.

Hello Jenkins Builder, fixeria,

I'd like you to reexamine a change. Please visit

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

to look at the new patch set (#4).

Change subject: common+trx: make uplink ECU optional ......................................................................

common+trx: make uplink ECU optional

Current osmo-bts-trx includes a provision for invoking ECUs from libosmocodec in the UL path from the channel decoder to the RTP output; no other models currently do likewise, but there is no particular reason why this ECU invokation couldn't be moved into model-independent code.

However, the approach of applying an ECU to the UL output of a BTS directly inside that BTS runs counter to standard GSM architecture; instead the places where ECUs are to be implemented in the classic architecture are as follows:

* At the decoding input of speech transcoders, be they TRAUs or network edge TCs;

* In the Rx DTX handler block of every GSM MS;

* Possibly in the downlink path of TRAUs (the component preparing the DL frame stream going to a BTS PHY) in the case of TFO.

In the RTP-based RAN environment, the following two scenarios are most relevant:

1) In a call with only one GSM leg (the other leg is in the outside world), the best possible ECU would be one that is absorbed into the Rx DTX handler block at the decoding input of the network edge transcoder.

2) In a TrFO call from one GSM MS to another, the best approach is for the network to not apply any ECUs at all, and let all bad frame handling take place in the receiving MS on each end of the call.

In neither scenario is there anything to be gained from applying an ECU at the point of UL RTP output from the BTS - therefore, having one unconditionally included in a BTS with no way to disable it is bad. Provide a vty option to enable or disable BTS-internal application of an ECU to UL RTP output.

To avoid upsetting existing users, the default is left unchanged: the built-in ECU *is* applied to the uplink. However, given that this current default is counter to standard GSM architecture, it may be worth considering changing it in the future.

Related: OS#6027 Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e --- M include/osmo-bts/bts.h M src/common/vty.c M src/osmo-bts-trx/l1_if.c M tests/osmo-bts.vty 4 files changed, 93 insertions(+), 3 deletions(-)

git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/10/32110/4