Project

General

Profile

Actions

Feature #2547

closed

Add E1/T1 endpoint type to osmo-mgw

Added by laforge over 6 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
05/06/2020
Due date:
05/06/2020
% Done:

100%

Spec Reference:
Tags:
E1

Description

Contrary to OsmoNITB, OsmoBSC has no user plane / voice handling inside it. Rather, all media/voice handling is done inside osmo-mgw.

We will not be able to support classic E1/T1 BTSs from OsmoBSC unless we're able to support E1/T1 endpoints in osmo-mgw. So let's implement them. We'll at minimum need endpoint types for 16kbit sub-slots with TRAU frames (voice calls).

TBD is the details on how the signaling is handled. We could possibly open signaling slots directly from the BSC (via libosmo-abis/e1_input), or we could have osmo-mgw open those slots and convert the HDLC payload / LAPD into something that can be transported over IP to osmo-bsc. This is related but a separate ticket.


Related issues

Related to OsmoBSC - Feature #2548: Add support for E1/T1 based BTSs to OsmoBSCResolveddexter10/06/2017

Actions
Related to E1/T1 Hardware Interface (including icE1usb) - Feature #3965: ICE40 based USB E1 adapterResolvedtnt04/30/2019

Actions
Related to OsmoMGW - Feature #2659: prepare osmo-mgw architecture for other endpoint typesResolveddexter11/18/2017

Actions
Related to OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20Resolvedtnt04/27/2020

Actions
Follows OsmoMGW - Feature #4535: Develop "E1/Abis generator"In Progresslaforge05/05/2020

Actions
Actions #1

Updated by laforge over 6 years ago

  • Related to Feature #2548: Add support for E1/T1 based BTSs to OsmoBSC added
Actions #2

Updated by laforge over 6 years ago

  • Priority changed from Normal to Low
Actions #3

Updated by laforge almost 6 years ago

  • Priority changed from Low to High
Actions #4

Updated by laforge almost 6 years ago

  • Tags set to E1
Actions #5

Updated by laforge almost 5 years ago

Actions #6

Updated by laforge over 4 years ago

  • Related to Feature #2659: prepare osmo-mgw architecture for other endpoint types added
Actions #7

Updated by laforge over 4 years ago

Actions #8

Updated by laforge almost 4 years ago

  • Related to Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20 added
Actions #9

Updated by laforge almost 4 years ago

Actions #10

Updated by laforge almost 4 years ago

  • Status changed from New to Stalled
  • Assignee changed from laforge to dexter

dexter is scheduled to work on this. However, in order to do this without having to bring up a whole network with E1 BTS, phones, etc. in his home office, we will first develop an "E1 generator". This will then provide a E1 line with TRAU frames for the different voice codecs via libosmo-abis, so that osmo-mgw can be developed against this, without any external dependencies. See #4535 for details.

Should that E1 generator take more time, some architectural changes and preparation work can happen within osmo-mgw already meanwhile.

Actions #11

Updated by laforge almost 4 years ago

  • Due date set to 05/06/2020
  • Start date changed from 10/06/2017 to 05/06/2020
  • Follows Feature #4535: Develop "E1/Abis generator" added
Actions #12

Updated by dexter almost 4 years ago

For E1, I need to know if the following makes sense:

The spec suggests the following for the selection of an E1 (digital) endpoint:
ds/<unit-type1>-<unit #>/<unit-type2>-<unit #>/.../<channel #>

I understand this recommendation like this:
ds/e1-0/s-2/su-1/0 => digital-trunk/e1-card number 0/timeslot 1/subslot 0/channel 0

For the "channel" I am not sure. As far as I know the E1 timeslots are assigned to the air interface timeslot in a fixed way. Basically one E1 subslot maps on one UM timeslot. Now I am not sure how half-rate channels would end up on the E1. Where does the demuxing take place (libosmo-abis)? Does my endpoint addressing model make sense?

Actions #13

Updated by dexter almost 4 years ago

  • Status changed from Stalled to In Progress
  • % Done changed from 0 to 10

The E1 implementation requires some refactoring of the existing osmo-mgw features (see also #2547). However while doing that there is also much focus on the E1 support. The implementation is now at a point where one can configure an E1 trunk and do a CRCX on its endpoint. In order to test this I have created a short TTCN3 test that creates a connection on the endpoint.

Actions #14

Updated by dexter over 3 years ago

  • % Done changed from 10 to 30

The patches that introduce the interlocking of the E1 endpoints are now in review. I have also implemented a TTCN3 test (not in review yet) that tries to select overlapping endpoints, so it is impossible now to select an invalid combination of E1 endpoints (should never happen anyway when everything is correctly configured!). The interlocking works entirely on endpoint names, so no additional (redundant) struct members are required. This is intentional and the string processing required to do this is affordable.

As an intermediate step we will now focus on using the E1 endpoints with osmo-bsc to see if the signalling works ok before we try it on a real BTS.

Actions #15

Updated by dexter over 3 years ago

I worked myself through the osmo-bsc code and I have now bent the lchan_rtp_fsm in a way that it does MGCP requests with E1 endpoint names. The endpoint names reflect a 16k subslot and the numbers match whatever is configured in osmo-bsc.cfg.

However, I noticed that there is a big problem. From what I can see now it is not possible to do handover with an E1 endpoint since it is not possible to alter the connection that points to the E1 side. A handover to a different E1 BTS means that the voice data becomes present on a different location in the trunk. The MGW must follow that. The only way to do this is to delete the E1 endpoint of the old BTS and do a CRCX to the endpoint of the new BTS, but then the port number on the MGW side changes and we are not able to communicate that back to the MSC. (I believe on sccp-lite things are even more problematic.)

We could deal with the problem by using two endpoints. One virtual endpoint with two connections as we already familiar with and one E1 endpoint. On the virtual endpoint, one connection will point to the MSC side and one will point to the E1 endpoint. When we then do a handover, we delete the E1 endpoint, CRCX the new one and then we reconfigure the connection on the virtual endpoint.

I also noticed a minor problem with the endpoint names. Apparantly also digital trunk endpoints require the @mgw at the end. This is not so clear in the spec but a little below I find example that have that. I will fix this.

Actions #16

Updated by laforge over 3 years ago

On Thu, Jun 25, 2020 at 07:13:22PM +0000, dexter [REDMINE] wrote:

I worked myself through the osmo-bsc code and I have now bent the lchan_rtp_fsm in a way that it does MGCP requests with E1 endpoint names. The endpoint names reflect a 16k subslot and the numbers match whatever is configured in osmo-bsc.cfg.

great.

However, I noticed that there is a big problem. From what I can see now it is not possible to do handover with an E1 endpoint since it is not possible to alter the connection that points to the E1 side.

I think we can live without handover support at least for a first implementation.

A handover to a different E1 BTS means that the voice data becomes present on a different location in the trunk. The MGW must follow that. The only way to do this is to delete the E1 endpoint of the old BTS and do a CRCX to the endpoint of the new BTS, but then the port number on the MGW side changes and we are not able to communicate that back to the MSC. (I believe on sccp-lite things are even more problematic.)

I think there is BSSMAP INTERNAL HANDOVER REQUIRED, which can be sent to
the MSC in order to communicate new codec + IP/Port. The MSC can then
either ACCEPT or REJECT that.

So if one wants hand-over support (I think we skip it for now), one can
a) use those BSSMAP INTRNAL HANDOVER messages, or
b) find a mechanism how to reuse the same port on the new E1 endpoint
c) use another MGW rtp endpoint (in series to the E1 endpoint)

btw: It may very well be the case that you hand over from an E1 BTS to
an IP BTS, too. But as stated, let's postpone that for now, I think.

The 'a' is required anyway (if we don't implement it already) if the codec changes during any intra-BSC
handover.

I also noticed a minor problem with the endpoint names. Apparantly also digital trunk endpoints require the @mgw at the end. This is not so clear in the spec but a little below I find example that have that. I will fix this.

There is always a host/domain name field in the endpoints. I think it primarily serves the ability to distinguish several media gateways to scale out.

Actions #17

Updated by neels over 3 years ago

On Thu, Jun 25, 2020 at 07:13:22PM +0000, dexter [REDMINE] wrote:

Issue #2547 has been updated by dexter.

I worked myself through the osmo-bsc code and I have now bent the lchan_rtp_fsm in a way that it does MGCP requests with E1 endpoint names. The endpoint names reflect a 16k subslot and the numbers match whatever is configured in osmo-bsc.cfg.

However, I noticed that there is a big problem. From what I can see now it is not possible to do handover with an E1 endpoint since it is not possible to alter the connection that points to the E1 side. A handover to a different E1 BTS means that the voice data becomes present on a different location in the trunk. The MGW must follow that. The only way to do this is to delete the E1 endpoint of the old BTS and do a CRCX to the endpoint of the new BTS, but then the port number on the MGW side changes and we are not able to communicate that back to the MSC. (I believe on sccp-lite things are even more problematic.)

I see that we're fine with not implementing these things now, but here are my
ideas about the general setup:

The lchan_rtp_fsm also does not yet support setting up RTP for a Channel Mode
Modify (if we keep an lchan but add voice capability later), so there we
currently allocate a new lchan in the BSC instead of re-using the current one
(even if the lchan would be capable). So it would be good at some point to
think about the lchan_rtp_fsm design in general. Shouldn't be too hard.

Also related is 48.008 3.1.5c: BSS Internal Handover with MSC support, which
includes the MSC in the handover -- which we don't support yet, but that could
tell the MSC about a changed RTP address.

We could deal with the problem by using two endpoints.

I think we also mentioned at some point that an MGW could fairly easily detect
whether it would be sending RTP back to its own RTP address, and then we could
chain two endpoints which the MGW could internally shortcut directly without
actually sending RTP packets back to itself via loopback. The BSC would merely
need to set up another rtpbridge endpoint in-between to connect to the E1.

I also noticed a minor problem with the endpoint names. Apparantly also digital trunk endpoints require the @mgw at the end. This is not so clear in the spec but a little below I find example that have that. I will fix this.

Related: at some point I added the capability to accept a different string
(e.g. "msc" or "@bsc") or to not care about what string follows the . But I
didn't add capability to completely drop the '@'. See 'mgcp' / 'domain' cfg.

Actions #18

Updated by laforge over 3 years ago

On Fri, Jun 26, 2020 at 12:45:33PM +0000, neels [REDMINE] wrote:

The BSC would merely need to set up another rtpbridge endpoint in-between to connect to the E1.

yes, it's possible - but really ugly, IMHO. So let's not go there.

Actions #19

Updated by dexter over 3 years ago

  • % Done changed from 30 to 40

So far I am currently at the point where I integrate the E1 support offered by libosmoabis. I start with the i460 mux. This is a bit tricky because the E1 initialization must happen at the first CRCX and torn down when the endpoint is released (DLCX). I have the feeling that mgcp_endp.c needs some refactoring after the integration is done but I will move a head without tearing everything apart as I think refactoring it makes most sense when E1 support is done as then I can see very well what is E1 specific and what is not.

Actions #20

Updated by dexter over 3 years ago

So far I am currently at the point where I integrate the E1 support offered by libosmoabis. I start with the i460 mux. This is a bit tricky because the E1 initialization must happen at the first CRCX and torn down when the endpoint is released (DLCX). I have the feeling that mgcp_endp.c needs some refactoring after the integration is done but I will move a head without tearing everything apart as I think refactoring it makes most sense when E1 support is done as then I can see very well what is E1 specific and what is not.

https://gerrit.osmocom.org/c/osmo-mgw/+/18898 endp: add E1 endpoint interlocking
https://gerrit.osmocom.org/c/osmo-mgw/+/19074 endp: require domain name also for E1 endpoints
https://gerrit.osmocom.org/c/osmo-mgw/+/19075 mgcp_client: add function to generate e1-endpoint names
https://gerrit.osmocom.org/c/osmo-mgw/+/19118 mgcp_endp: use define constant to define max number of E1 subslots
https://gerrit.osmocom.org/c/osmo-mgw/+/19119 mgcp_trunk: remove double check
https://gerrit.osmocom.org/c/osmo-mgw/+/19121 mgcp_vty: refactor endpoint number configuration

Actions #21

Updated by dexter over 3 years ago

  • % Done changed from 40 to 80

The integration of the i460 mux and the libosmoabis E1 backend is now at a point where it can be tested with real hardware.

The current state can be found on branch: pmaier/mgw

When testing locally with TTCN3 and osmo-e1d, ttcn3 and any own scrits. The RTP streams look good in wireshark, however I can not get any sound with gapk.

Actions #22

Updated by dexter over 3 years ago

  • % Done changed from 80 to 90

The E1 support in osmo-mgw now works fine now. I have tested it with EFR and FR. The patch is now up for review:

https://gerrit.osmocom.org/c/osmo-mgw/+/19524 mgcp_e1: finish E1 support, add E1 support from libosmoabis

Actions #23

Updated by dexter over 3 years ago

I have addressed some remaining problems with the codec / sync-pattern selection today. It is necessary to be able to change the sync pattern on the fly. Especially when using AMR codecs the different rates seem to use different sync patterns. I have added a patch to libosmo-abis to be able to change the sync pattern on the fly:

https://gerrit.osmocom.org/c/libosmo-abis/+/19547

The patch is also on libosmoabis.git on branch pmaier/mgw.

For osmo-mgw a recent branch can be found under pmaier/mgw2. The trau frame type and / sync pattern is now determined more efficient. Also some other minor problems, which were pointed out in the review are now fixed. However, There are still some things to do so the gerrit is not up to date yet.

Actions #24

Updated by dexter over 3 years ago

All relevant patches are merged. However, while investigating the problem with the TTCN3 tests I came across a few minor things so I have added some new patches, but those are all not relevant for making the TTCN3 tests pass.

The config file shipped with the docker container did not have the trunk configured. This is now fixed:
https://gerrit.osmocom.org/c/docker-playground/+/19712 osmo-mgw.cfg: fix config file + add E1 trunk

But there are still problems. At the moment the E1 line is configured as ipa, this is not correct, it should be rather e1d, but it seems that libosmo-abis in the docker container is not built with option --enable-e1d. Also we would need to have osmo-e1d running. For testing we could in theory permanently loop a file with audio data on one timeslot. Then we could have a TTCN3 test that receives that data. I already have such a test (halfway finished, does not pass), I used it for offline testing during development.

Actions #25

Updated by laforge over 3 years ago

dexter wrote:

But there are still problems. At the moment the E1 line is configured as ipa, this is not correct, it should be rather e1d, but it seems that libosmo-abis in the docker container is not built with option --enable-e1d. See https://gerrit.osmocom.org/c/libosmo-abis/+/19799

The container is using the debian packages, so the libosmo-abis package simply needs to be built with that support enabled.

Also we would need to have osmo-e1d running.

feel free to do so.

Actions #26

Updated by dexter over 3 years ago

  • Status changed from In Progress to Stalled

I had a look at this again now. As I can see #19799 is reverted. I guess that means that we can not have e1d enabled? There is no way to enable it selectively for the ttcn3-mgw-test only?

Actions #27

Updated by laforge over 3 years ago

On Thu, Sep 03, 2020 at 12:51:06PM +0000, dexter [REDMINE] wrote:

I had a look at this again now. As I can see #19799 is reverted. I guess that means that we can not have e1d enabled? There is no way to enable it selectively for the ttcn3-mgw-test only?

The proper solution is to move the IPA code out of libosmo-abis. Historically that made sense,
as the IPA multiplex was first encountered in Abis. But then it was also present in SCCPlite,
we started using it for GSUP, and most recently for RSPRO in osmo-remsim.

This now means that virtually all osmocom projects depend on libosmo-abis, while all they want
is the IPA abstraction.

Adding osmo-e1d support to libosmo-abis creates another dependency, and I rally do not want
to have to exlpain to an osmo-remsim user why he needs to install an E1 interface driver
if he wants to have remote sim functionality.

So my plan was to see if we can untangle this somehow without spending two weeks of time on it,
and then re-enable the dependency of libosmo-abis to osmo-e1d once nobody (except osmo-mgw
and osmo-bsc) depend on libosmo-abis anymore.

Actions #28

Updated by dexter over 3 years ago

The remaining problem is that we can not execute all e1 related TTCN3 test properly in jenkins. However, the E1 endpoint is added, we could close the task and create a new one that addresses the testing issues.

Actions #29

Updated by dexter over 3 years ago

  • Status changed from Stalled to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)