Cellular Network Infrastructure » OsmoMGW

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.

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?

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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 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.