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 (#5).
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/bts.c
M src/common/vty.c
M src/osmo-bts-trx/l1_if.c
M tests/osmo-bts.vty
5 files changed, 103 insertions(+), 3 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/10/32110/5
--
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/32110
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I0acca9c6d7da966a623287563e0789db9e0fae8e
Gerrit-Change-Number: 32110
Gerrit-PatchSet: 5
Gerrit-Owner: falconia <[email protected]>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <[email protected]>
Gerrit-CC: laforge <[email protected]>
Gerrit-CC: pespin <[email protected]>
Gerrit-Attention: laforge <[email protected]>
Gerrit-Attention: pespin <[email protected]>
Gerrit-MessageType: newpatchset
