Project

General

Profile

Actions

Bug #3260

closed

Implement libosmo-abis input for new E1 interface

Added by laforge almost 6 years ago. Updated about 4 years ago.

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

100%

Spec Reference:
Tags:
E1

Description

The libosmo-abis input drivers (so far dahdi + misdn) need to be extended to access the USB (and/or UDP based) osmocom E1 interface.

http://git.osmocom.org/libosmo-abis/tree/src/input/dahdi.c can be used as an example.

The existing drivers expect to be able to
  • open individual file descriptors (/dev for dahdi, sockets for misdn) for each time-slot
  • specify whether the want the raw bit-stream or expect the driver/hardware to do HDLC (de)framing within that timeslot

So it might make sense to have some other external process that offers this "one FD per timeslot" notion to libosmo-abis. This process would then be talking to the USB device (or exchainging UDP frames) with the E1 LIU, and do the timeslot de-mux + HDLC processing.

Another idea might be to actually integrate with DAHDI itself. This has the advantage that the E1 interface can be used with other software such as asterisk. But then, as DAHDI is an out-of-tree/mainline kernel patch, I think we'd rather keep independent of that and make sure that with our new E1 adapter, neither the Linux kernel nore DAHDI are a requirement, and we just need libusb or UDP sockets with no other dependencies.


Related issues

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
Actions #1

Updated by laforge almost 6 years ago

  • Assignee set to laforge

laforge wrote:

So it might make sense to have some other external process that offers this "one FD per timeslot" notion to libosmo-abis. This process would then be talking to the USB device (or exchainging UDP frames) with the E1 LIU, and do the timeslot de-mux + HDLC processing.

actually, this is rather important. Only if we have individual, per-timeslot interfaces (such as fd/sockets), we can have OsmoBSC attach to the signaling timeslots but OsmoMGW attach to the traffic timeslots. So this is one important argument in favor of having an external process/damon handling E1.

The overall picture then looks like this:

Actions #2

Updated by laforge almost 6 years ago

  • Tags set to E1
Actions #3

Updated by laforge almost 5 years ago

Actions #4

Updated by laforge over 4 years ago

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

Updated by laforge over 4 years ago

  • Priority changed from Normal to High
Actions #6

Updated by laforge about 4 years ago

  • Status changed from New to Resolved
  • Assignee changed from laforge to tnt
  • % Done changed from 0 to 100

tnt actually did this already with his @osmo-e1d project, including related client library and libosmo-abis integration.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)