Project

General

Profile

Bug #3260

Implement libosmo-abis input for new E1 interface

Added by laforge about 1 year ago. Updated 5 days ago.

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

0%

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 - Feature #3965: ICE40 based USB E1 adapterIn Progress04/30/2019

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

History

#1 Updated by laforge about 1 year 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:

#2 Updated by laforge about 1 year ago

  • Tags set to E1

#3 Updated by laforge 3 months ago

#4 Updated by laforge 5 days ago

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

#5 Updated by laforge 5 days ago

  • Priority changed from Normal to High

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)