Project

General

Profile

Feature #2548

Add support for E1/T1 based BTSs to OsmoBSC

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

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

10%

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-mgwIn Progress05/06/202005/06/2020

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

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

History

#1 Updated by laforge almost 3 years ago

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

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

#7 Updated by laforge 10 months ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)