Project

General

Profile

Feature #2547

Add E1/T1 endpoint type to osmo-mgw

Added by laforge almost 3 years ago. Updated 5 days ago.

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

40%

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 OsmoBSCIn Progress10/06/2017

Related to E1/T1 Hardware Interface - Feature #3965: ICE40 based USB E1 adapterIn Progress04/30/2019

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

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

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

History

#1 Updated by laforge almost 3 years ago

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

#2 Updated by laforge over 2 years ago

  • Priority changed from Normal to Low

#3 Updated by laforge about 2 years ago

  • Priority changed from Low to High

#4 Updated by laforge about 2 years ago

  • Tags set to E1

#5 Updated by laforge about 1 year ago

#6 Updated by laforge 12 months ago

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

#7 Updated by laforge 10 months ago

#8 Updated by laforge 3 months ago

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

#9 Updated by laforge 3 months ago

#10 Updated by laforge 2 months 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.

#11 Updated by laforge 2 months 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

#12 Updated by dexter about 2 months 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?

#13 Updated by dexter 27 days 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.

#14 Updated by dexter 20 days 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.

#15 Updated by dexter 17 days 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.

#16 Updated by laforge 16 days 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.

#17 Updated by neels 16 days 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.

#18 Updated by laforge 16 days 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.

#19 Updated by dexter 6 days 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.

#20 Updated by dexter 5 days 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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)