Project

General

Profile

Actions

Feature #2548

closed

Add support for E1/T1 based BTSs to OsmoBSC

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

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

100%

Spec Reference:
Tags:
E1

Description

Contrary to OsmoNITB, OsmoBSC never was able to talk to E1/T1 based BTSs so far.

See #2547 for handling TRAU frames in osmo-mgw to get them converted to/from RTP for AoIP.

This ticket is more about the signaling side. It's TBD on the details 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.

Once this has been implemented + tested, we have a fully-functional replacement for OsmoNITB, even for legacy E1/T1 BTSs.


Related issues

Related to OsmoMGW - Feature #2547: Add E1/T1 endpoint type to osmo-mgwResolveddexter05/06/202005/06/2020

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

Actions
Related to OsmoBSC - Feature #2389: re-add siemens MRPCI message, dropped during MSCSPLITResolvedlaforge07/24/2017

Actions
Actions #1

Updated by laforge over 6 years ago

  • Related to Feature #2547: Add E1/T1 endpoint type to osmo-mgw 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 almost 5 years ago

  • Related to Feature #2389: re-add siemens MRPCI message, dropped during MSCSPLIT added
Actions #7

Updated by laforge over 4 years ago

Actions #8

Updated by laforge over 3 years ago

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

I've done some investigation here. My original fear was that the BSC might be trying to open all the TRAU timeslots on the E1 interface, which would then collide with OsmoMGW opening those slots.

But it seems this was already done correctly when moving from OsmoNITB ot OsmoBSC.
  • osmo-nitb will open all E1 timeslots that are mentioned in e1 line 0 timeslot 1 ... statements, whether for OML/RSL or for individual timeslots
  • osmo-bsc will only open the E1 timeslots carrying singaling, but not those used for TRAU traffic

The reason is found in the e1_reconfig_ts() function, which for the old NITB case contains:


        if (ts_is_tch(ts)) {
                e1_ts = &line->ts[e1_link->e1_ts-1];
                e1inp_ts_config_trau(e1_ts, line, subch_cb);
                subch_demux_activate(&e1_ts->trau.demux, e1_link->e1_ts_ss);
        }

but this section has been removed from osmo-bsc's implementation of e1_reconfig_ts().

Hence, at least on a timeslot level, the BSC and the MGW should not clash with each other. The BSC will only open signaling, and the MGW should only open traffic timeslots.

The E1 line numbering and driver configuration would have to match on both of them, though. This means the section like

e1_input
 e1_line 0 driver e1d
 e1_line 0 port 0

has to be identical in both osmo-bsc and omso-mgw in order to have a common understanding what physical E1 circuit 'line 0' maps to.

Actions #9

Updated by laforge over 3 years ago

  • Assignee changed from laforge to dexter

assigning to dexter. I think everything on the Abis signalling side is working for all known supported BTS models now, the remainign part of this ticket (inside the BSC) is the handlign of E1 slots via MGCP to OsmoMGW.

Actions #10

Updated by laforge over 3 years ago

  • % Done changed from 10 to 60
Actions #11

Updated by dexter over 3 years ago

  • % Done changed from 60 to 80

Technically osmo-bsc is now ready to use the E1 endpoints on osmo-mgw. However, handover would not work yet. The problem is described/discussed in #2547.

osmo-bsc will use the line number that is configured in osmo-bsc.cfg as trunk number. At the moment osmo-mgw only accepts trunk numbers starting at 1. However, this limitiation is dropped with the following patch: https://gerrit.osmocom.org/c/osmo-mgw/+/19563, once we merge this, osmo-mgw will also accept trunk numbers that start at 0.

Actions #12

Updated by laforge over 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

dexter wrote:

Technically osmo-bsc is now ready to use the E1 endpoints on osmo-mgw. However, handover would not work yet. The problem is described/discussed in #2547.

I think we should add a separate "handover for E1" feature request ticket for that.

osmo-bsc will use the line number that is configured in osmo-bsc.cfg as trunk number. At the moment osmo-mgw only accepts trunk numbers starting at 1. However, this limitiation is dropped with the following patch: https://gerrit.osmocom.org/c/osmo-mgw/+/19563, once we merge this, osmo-mgw will also accept trunk numbers that start at 0.

that patch has been merged now. Resolving this issue.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)