Feature #6463


E1: Investigate the correct transform from RTP to DL

Added by falconia about 2 months ago. Updated about 1 month ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:
TS 28.062 section C.


What is the correct way to transform an incoming RTP stream (that may have missing frames and/or BFIs) into a stream of TRAU-DL frames toward an E1 BTS in which either a good speech frame or a good SID must appear in every 20 ms position without fail? The official answer is given in TS 28.062 section C. - however, implementing a transform that fulfills the demands of that section would be quite difficult, especially for EFR. Furthermore, given the vague language used in the spec, reading like a wishlist without any guidance on how to actually do it algorithmically, it would be very interesting to know what the real historical TRAU implementations actually do or did here.

In OsmoBTS we solved the equivalent problem by cheating a little, transmitting induced BFI conditions on the radio DL instead of doing the onerous C3211 transform. However, we were able to take that course in OsmoBTS because we have sufficiently direct control over the BTS PHY and can make it transmit our desired form of induced BFI, even on the proprietary DSP PHY of sysmoBTS. In the case of an E1-interfaced proprietary BTS, it is not immediately obvious whether the same approach is possible or not: it may or may not be.

In order to obtain more definitive answers to these open questions, we will need to perform a series of experiments with a real historical TRAU and a real E1 BTS, to determine experimentally what the TRAU puts out on Abis DL during TFO (given inputs of BFI, valid and invalid SID, etc), and how the BTS reacts if the DL input to it deviates from the "pristine" form assumed in the specs.

This ticket is to track the necessary investigations, with the goal of arriving at a set of answers as to what we need to do in OsmoMGW RTP-to-E1 path.

Actions #1

Updated by falconia about 2 months ago

One of the key items required for this investigation is a historical TRAU, specifically one that supports TFO. Toward that end, I have a set of Nokia TCSM2 parts on order from shields-e (the vendor recommended by laforge) from which I hope to put together a minimal functional system. (TCSM is Transcoder and Submultiplexer, Nokia's term for the bank of TRAUs that sits between the MSC and the BSC, connected with E1s to each of those; TCSM2 is the specific generation of Nokia TCSM which I currently seek to bring to life.) Naturally, this project is facing huge uncertainties, but as of today it is the most promising avenue toward the goal of getting a TRAU for experimentation.

Actions #2

Updated by falconia about 1 month ago

Good news: the Nokia TRAU I got does support TFO, thus once I get it fully hooked up on A and Ater, we'll able to experiment with it and see how it implements the logic of TS 28.062 section C.


Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)