Project

General

Profile

Feature #4006

TRX protocol: wind of change

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

Status:
New
Priority:
High
Assignee:
-
Target version:
-
Start date:
05/17/2019
Due date:
% Done:

0%

Spec Reference:

Description

We are using TRX protocol in OsmoBTS in order to "speak" with transceiver (e.g. OsmoTRX, FakeTRX). Basically it defines three interfaces: clock for TDMA frame clock indications, control (we agreed to call it TRXC) for transceiver management, and data (TRXD) for exchanging Rx/Tx bursts. It was first introduced in OpenBTS project, from which we forked OsmoTRX. For more information, please see: https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager.

The protocol is being used for years, and it still serves us for good. However, it is extremely inflexible. For example, there is no way to send more information about received bursts on TRXD interface, than the fixed-size header already has (TDMA frame number, timeslot number, RSSI, ToA256). On TRXC interface, which is working over UDP as the other ones, there is no way to distinguish command retransmission, which may happen due to timeout, from a regular command. There is no way to notify the L1 (i.e. OsmoBTS) about some events (e.g. device has been disconnected), no way to indicate transceiver version, and so on...

During OsmoDevCon2019 (and before too) we have been discussing the idea of introducing the new version of TRX protocol, which would allow us to solve the mentioned problems. In order to keep backwards compatibility, both L1 and transceiver would initially use the old TRX protocol, while the new version can be optionally enabled by sending a command on TRXC interface. If the transceiver does support the new protocol, it would acknowledge the command. Otherwise, the command is rejected, so L1 would continue to work in "backwards compatibility" mode.

Finally, we need to write a proper protocol description like we already have for GSUP in https://git.osmocom.org/osmo-gsm-manuals/. But before starting to work on this, let's create some kind of a wish list - what would you like to see in the new version of TRX protocol?


Checklist

  • Notifications from transceiver (e.g. device has been disconnected)
  • Info / feature negotiation (e.g. version, device type / name)
  • TRXC: the ability to distinguish command retransmissions
  • TRXD: "no burst" indication (e.g. when nothing has been detected)
  • TRXD: detected training sequence (and it's C/I weight)
  • TRXD: noise level indication
  • TRXD: facilitate further extensibility?
  • TRXC: the ability to enable / disable EDGE burst / 11-bit RACH detection

Related issues

Related to OsmoBTS - Bug #1618: AMR adaption loop doesn't use C/I thresholds, only BERNew02/23/2016

Related to OsmoTRX - Feature #3054: Extended (11-bit) RACH support in OsmoTRXStalled03/10/2018

Blocks OsmoBTS - Bug #1855: provide actual BER or C/I values from osmo-bts-trx into the PCUNew11/18/2016

Blocks OsmoBTS - Bug #3428: Too many contiguous elapsed fn, dropping...Stalled07/28/2018

History

#1 Updated by fixeria about 1 month ago

  • Blocks Bug #1855: provide actual BER or C/I values from osmo-bts-trx into the PCU added

#2 Updated by fixeria about 1 month ago

  • Related to Bug #1618: AMR adaption loop doesn't use C/I thresholds, only BER added

#3 Updated by ipse about 1 month ago

Also see discussion about the ways to extend the burst headers in the discussion of this patch: https://gerrit.osmocom.org/#/c/osmo-bts/+/13723/

#4 Updated by ipse about 1 month ago

TRXC: the ability to distinguish command retransmissions

As an idea - we can prepend the command/response packets with a counter (sequence number). This will allow not only retransmission detection but also lost commands detection (gaps in the sequence numbers).

#5 Updated by laforge 30 days ago

On Fri, May 17, 2019 at 01:14:13PM +0000, ipse [REDMINE] wrote:

TRXC: the ability to distinguish command retransmissions

As an idea - we can prepend the command/response packets with a counter (sequence number). This will allow not only retransmission detection but also lost commands detection (gaps in the sequence numbers).

This would likely break all compatibility with the existing implementations, so if you change something
as drastic as this, I would argue you could just as well move away from UDP altogether for the control
protocol. Sure, I get why it makes sense for the bursts... but using an unreliable transport for
controlling the transceiver? I don't see any advantage to that.

So if there's something incompatible new for the control side anyway, I would argue one could
just as well go for a completely new protocol. The old protocol would continue to exist in parallel for
backwards compatibility.

In any case, the important part right now is extending the burst data with
more information (training sequence, C/I value), and I suggest to focus on
implementing that before doing more radical changes.

#6 Updated by ipse 30 days ago

laforge wrote:

In any case, the important part right now is extending the burst data with
more information (training sequence, C/I value), and I suggest to focus on
implementing that before doing more radical changes.

Totally agree with this, btw. This is quite straightforward as we discussed in the Gerrit.

On Fri, May 17, 2019 at 01:14:13PM +0000, ipse [REDMINE] wrote:

TRXC: the ability to distinguish command retransmissions

As an idea - we can prepend the command/response packets with a counter (sequence number). This will allow not only retransmission detection but also lost commands detection (gaps in the sequence numbers).

This would likely break all compatibility with the existing implementations,

Well, it would be enabled only if negotiated between the OsmoTRX and OsmoBTS. Any protocol change would break compatibility so I just assume that would be enabled after a negotiation based on the "classical" protocol.

so if you change something
as drastic as this, I would argue you could just as well move away from UDP altogether for the control
protocol. Sure, I get why it makes sense for the bursts... but using an unreliable transport for
controlling the transceiver? I don't see any advantage to that.

Just curious, what do you think of here? SCTP in reliable datagram mode?

I frankly don't see issues in using UDP here - implementing retransmissions and seq.numbers is not difficult but allows us to be in control on how exactly we do the retransmissions unlike with TCP where we have to rely on the OS implementation. E.g. I don't think we want exponential back off here.

#7 Updated by fixeria 29 days ago

  • Related to Feature #3054: Extended (11-bit) RACH support in OsmoTRX added

#8 Updated by fixeria 29 days ago

  • Checklist item TRXC: the ability to enable / disable EDGE burst / 11-bit RACH detection added

#9 Updated by fixeria 22 days ago

Checklist item: TRXD: "no burst" indication (e.g. when nothing has been detected)

I just realized that having such indications would devaluate the clock interface: there will be no need to send clock indications on a separate interface if OsmoBTS receives either bursts or "no burst" indications on TRXD eight times per TDMA frame (excluding IDLE slots).

#10 Updated by fixeria 14 days ago

  • Blocks Bug #3428: Too many contiguous elapsed fn, dropping... added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)