Initial user manual for osmo-e1d

Still quite incomplete, but significantly better than nothing.

Change-Id: I42f8da1990092b5a3d8c63fde33e49978ad83281
Harald Welte 1 month ago committed by laforge
parent 533cf1e4d7
commit 03d9c3215c
  1. 44
  2. 1
  3. 14
  4. 72
  5. 85
  6. 105
  7. 25
  8. 68
  9. 31
  10. 43

@ -75,6 +75,49 @@ then
# Generate manuals
[Generate manual PDFs [default=no]],
[osmo_ac_build_manuals=$enableval], [osmo_ac_build_manuals="no"])
AM_CONDITIONAL([BUILD_MANUALS], [test x"$osmo_ac_build_manuals" = x"yes"])
AC_ARG_VAR(OSMO_GSM_MANUALS_DIR, [path to common osmo-gsm-manuals files, overriding pkg-config and "../osmo-gsm-manuals"
if test x"$osmo_ac_build_manuals" = x"yes"
# Find OSMO_GSM_MANUALS_DIR (env, pkg-conf, fallback)
if test -n "$OSMO_GSM_MANUALS_DIR"; then
echo "checking for OSMO_GSM_MANUALS_DIR... $OSMO_GSM_MANUALS_DIR (from env)"
OSMO_GSM_MANUALS_DIR="$($PKG_CONFIG osmo-gsm-manuals --variable=osmogsmmanualsdir 2>/dev/null)"
if test -n "$OSMO_GSM_MANUALS_DIR"; then
echo "checking for OSMO_GSM_MANUALS_DIR... $OSMO_GSM_MANUALS_DIR (from pkg-conf)"
echo "checking for OSMO_GSM_MANUALS_DIR... $OSMO_GSM_MANUALS_DIR (fallback)"
if ! test -d "$OSMO_GSM_MANUALS_DIR"; then
AC_MSG_ERROR("OSMO_GSM_MANUALS_DIR does not exist! Install osmo-gsm-manuals or set OSMO_GSM_MANUALS_DIR.")
# Find and run check-depends
if ! test -x "$CHECK_DEPENDS"; then
if ! $CHECK_DEPENDS; then
AC_MSG_ERROR("missing dependencies for --enable-manuals")
# Put in Makefile with absolute path
[Include the VTY/CTRL tests in make check [default=no]]),
@ -118,6 +161,7 @@ AC_OUTPUT(

@ -1,3 +1,4 @@
examples \
manuals \

@ -0,0 +1,14 @@
osmoe1d-usermanual.adoc \
osmoe1d-usermanual-docinfo.xml \
chapters \
ASCIIDOC = osmoe1d-usermanual.adoc
ASCIIDOC_DEPS = $(srcdir)/chapters/*.adoc
include $(OSMO_GSM_MANUALS_DIR)/build/
include $(OSMO_GSM_MANUALS_DIR)/build/

@ -0,0 +1,72 @@
== Client Interface
This chapter documents the _Client interface_ which is used by
application programs wanting to send and/or receive data on the E1
circuits served by `osmo-e1d`.
The interface is based on a `unix domain socket` and works in the
following way:
* `osmo-e1d` implements the server side of a unix domain socket
* the application program acts as a client program establishing a socket
connection to the e1d unix domain socket
* the application program preforms operations such as opening of a
specific E1 timeslot on a spcific line/interface.
* `osmo-e1d` passes a file descriptor from the daemon to the client
* the client application can read/write data from/to the E1 timeslot via
this file descriptor
This architecture was chosen to allow for the _one file descriptor per
timeslot_ paradigm that is known from other drivers, such as DAHDI.
Each timeslot of each line on each interface can theoretically be opened
by a different program. This permits for example control/user plane
splits like a signaling gateway + media gateway implemented as separate
When opening a timeslot, the client specifies the _mode_.
* In _RAW mode_, the transparent 64kBps bit-stream is passed over the
per-timeslot file descriptor. This is mostly used for B-channels /
user traffic.
* In _HDLC-FCS mode_, a (software) HDLC processor is instantiated. It
performs flag sequence detection/generation and bit-stuffing. This is
mostly used for D-channels / signalling.
Details about the messaging on the unix domain socket can be found in
the definitions contained in the `include/osmocom/e1d/proto.h` header
file, as well as the doxygen API documentation generated from it.
=== `libosmo-e1d` client library
To simplify interfacing `osmo-e1d` from an application, there is a
companion library called `libosmo-e1d`.
It contains functions implementing the above-mentioned client interface
protocol and prevents the application developer from having to implement
the low-level bits of this interface.
The library is licensed under GNU LGPL-3.0-or-later, which is a weak
copyleft license that permits using the library from non-open-source /
proprietary applications.
The library offers the following functions:
* initialization / teardown
** `osmo_e1dp_client_create()`
** `osmo_e1dp_client_destroy()`
* information querying
** `osmo_e1dp_client_intf_query()`
** `osmo_e1dp_client_line_query()`
** `osmo_e1dp_client_ts_query()`
* configuration
** `osmo_e1dp_client_line_config()`
* opening of timeslots
** `osmo_e1dp_client_ts_open()`
** `osmo_e1dp_client_ts_open_force()`
Details about those functions can be found in the definitions contained
in the `include/osmocom/e1d/proto_clnt.h` header file.

@ -0,0 +1,85 @@
== E1 drivers
`osmo-e1d` was primarily developed for the icE1usb hardware, but also
supports some other drivers by now.
=== The `usb` driver for icE1usb and e1-tracer
The `usb` driver implements the USB interface first implemented by the
`icE1usb` hardware.
For more information on the `icEusb`, please see its related user
manual, published at
Each `icEusb` device implements one E1 interface with up to two E1
lines. Note that supporting two E1 lines is only supported on very few
select USB host controllers. In most cases, your USB host controller
will only permit using one of the two lines.
==== Configuration
`osmo-e1d` will automatically detect any supported USB devices when
starting up. It will dynamically allocate E1 interface and E1 line
numbers to those USB devices. However, the order is not guaranteed and
particularly in case you have multiple devices, it is strongly
recommended to use _static configuration_.
In this static configuration, you would have a block like
.Example configuration snippet for an icE1usb
interface 2 icE1usb
usb-serial dc697407e7881531
This way you reserve/allocate the E1 interface number 2 for the icE1usb
with serial number dc697407e7881531. The Serial number is unique and
stored in the iSerial string of the USB device descriptor. You can for
example use `lsusb -v -d 1d50: | grep iSerial` to obtain it, or check
the `dmesg` kernel log after plugging in a device.
==== Using the `usb` driver with `e1-tracer`
The same driver has been slightly extended to also support the passive,
bi-directional `e1-tracer` hardware. The configuration and use is
identical to the use with the `icE1usb`, with the notable difference
that a passive tracer can obviously only receive data from E1, but not
transmit. The two directions of a E1 circuit are represented as two
lines in `osmo-e1d`.
=== The `vpair` driver for virtual E1 circuits
Sometimes it is useful to be able to interface multiple E1-using
applications without a real E1 circuit or any hardware whatsoever.
This can be used in automatic / virtualized software testing, but also
in case a legacy application is migrate away from real physical E1
==== Configuration
The configuration of the `vpair` driver is relatively simple. It
consists of a single `virtual-e1-pair` command.
.Example configuration snippet for a virtual E1 pair with one E1 line
virtual-e1-pair 1
The above example will create a virtual pair of E1 interfaces, each
of those interface with one E1 line.
.Log output of the example configuration for 1 virtual pair
intf_line.c:184 (I0) Created
intf_line.c:285 (I0:L0) Created
intf_line.c:184 (I1) Created
intf_line.c:285 (I1:L0) Created
You can subsequently use the Lines just like you would use physical E1
lines. Any data you transmit on one line will be received on the other
line, and vice versa.

@ -0,0 +1,105 @@
== Overview
=== About this manual
This manual should help you getting started with the `osmo-e1d` software.
It will cover aspects of configuring and running `osmo-e1d` as well as some
introduction about its internal architecture and external interfaces.
=== About `osmo-e1d`
`osmo-e1d` is a driver (implemented as userspace daemon) for a variety of hardware
related to the E1 (TDM) interface, such as
* the `icEusb` USB attached E1 interface
* the `e1-tracer` USB attached passive E1 tracer
=== Credits
`osmo-e1d` was originally developed in 2019 by Sylvain Munaut alongside
the icE1usb project. It subsequently got improved and extended by Harald
=== Architecture
`osmo-e1d` is a driver system for E1 circuits, which are sometimes also called
primary rate (PRI). It typically sits between an E1 hardware interface beneath
it and application software above it.
.How osmo-e1d fits in the overall system architecture
digraph G{
//rankdir = LR;
Application -> loa;
pipe -> e1d [style=dashed];
loa -> e1d;
e1d -> HW;
e1d -> vpair;
HW -> BTS;
Application [label="Application\nosmo-nitb / osmo-bsc"];
pipe [label="osmo-e1d-pipe\nfor testing", style=dashed];
e1d [label="osmo-e1d", color=red];
loa [label="libosmo-abis\ne1_input"];
HW [label="E1 Hardware"];
vpair [label="Virtual E1 pair"];
Contrary to older E1 drivers such as DAHDI or mISDN, `osmo-e1d` runs entirely in userspace,
without a need for kernel drivers. This is obviously less computationally efficient,
but has other advantages, such as working on unmodified Linux kernels / operating systems,
and with a lower risk of software bugs affecting overall system
stability. Particularly at low E1 port density and modern hardware, the
lower efficiency is not expected to make a big difference.
==== E1 Interfaces
In `osmo-e1d` language, an _E1 Interface_ is some kind of underlying hardware that contains one or more
_Lines_. Interfaces are numbered from 0..N and are often abbreviated e.g. as `I0` for Interface 0.
==== E1 Lines
In `osmo-e1d` language, an _E1 Line_ represents one single E1 circuit within an _E1 Interface_.
=== Hardware support
`osmo-e1d` currently supports the following hardware:
* Osmocom icE1usb
* Osmocom e1-tracer
* Virtual pair of E1 circuits
==== icE1usb
The Osmocom icE1usb is an OSHW implementation of a USB-attached hardware
interface for up to two E1 circuits (lines).
For more information on the Osmocom icE1usb, see
* data sheet:
* project wiki:
* user manual:
* product page:
==== e1-tracer
The Osmocom e1-tracer is an OSHW implementation of a passive,
high-impedance bi-directional E1 tap/tracer/sniffer. It can be used to
capture traffic on an unmodified E1 interface.
For more information on the Osmocom e1-tracer, see
* project wiki:
* user manual:
==== vpair
The osmo-e1d _vpair_ is not actual hardware, but a virtual pair of E1
interfaces. It can be used to test E1-using applications without
involving a hardware E1 circuit.

@ -0,0 +1,25 @@
== Running osmo-e1d
The `osmo-e1d` executable offers the following command-line arguments:
*osmo-e1d* [-h] [-d 'DBGMASK'] [-c 'CONFIGFILE']
*-h, --help*::
Print a short help message about the supported options.
*-V, --version*::
Print the version of osmo-e1d.
*-d, --debug 'DBGMASK','DBGLEVELS'*::
Set the log subsystems and levels for logging to stderr. This
has mostly been superseded by VTY-based logging configuration,
see <<logging>> for further information.
*-c, --config-file 'CONFIGFILE'*::
Specify the file and path name of the configuration file to be
used. If none is specified, use `osmo-bsc.cfg` in the current
working directory.

@ -0,0 +1,68 @@
== OCTOI TDMoIP mode
Instead of providing a programmatic client interface (<<client>>) enabling
external applications timeslot-granular access to the data of a E1 line,
`osmo-e1d` also supports an entirely separate mode of operation:
_TDMoIP using the OCTOI (Osmocom Community TDMoIP) protocol_.
In this mode of operation, osmo-e1d acts as interface between an E1 line
and a remote system over UDP/IP. This allows you to transparently pass
an E1 line over an IP network such as the Internet.
`osmo-e1d` can operate either as client or as server for the OCTOI protocol.
=== osmo-e1d as OCTOI client
Below is an example configuration snippet for operating as an OCTOI client.
.Configuration snippet for operating as an OCTOI client
interface 0 icE1usb
usb-serial dc697407e7881531
line 0
mode e1oip <1>
octoi-client 10013 <2>
local-bind 3333 <3>
account foobar <4>
mode ice1usb
ice1usb serial-number dc697407e7881531 <5>
ice1usb line-number 0
<1> we specify that Interface 0 Line 0 (I0:L0) of the icE1usb device with serial number dc697407e7881531 shall
be used in `e1oip` mode.
<2> we instantiate an OCTOI client to the remote IP / UDP port 10013
<3> we specify to bind locally to INADDR_ANY and local UDP port 3333
<4> we specify the account/user name to tell the server is `foobar`
<5> we specify that this OCTOI client instance shall use the icE1usb device with the given serial number. This
must match the serial number used above when configuring the icE1usb line mode.
There can of course be any number of E1 interfaces/lines and clients; the example just shows one for clarity.
=== osmo-e1d as OCTOI server
Below is an example configuration snippet for operating as an OCTOI server.
.Configuration snippet for operating as an OCTOI server
interface 0 icE1usb
usb-serial dc697407e7881531
line 0
mode e1oip <1>
local-bind 10013 <2>
account foobar <3>
mode ice1usb
ice1usb serial-number dc697407e7881531 <4>
ice1usb line-number 0
<1> we specify that Interface 0 Line 0 (I0:L0) of the icE1usb device with serial number dc697407e7881531 shall
be used in `e1oip` mode.
<2> we bind the OCTOI server to UDP port 9999 of INADDR_ANY
<3> we specify a user account `foobar`
<4> we connect the user account `foobar` to the icE1usb serial number / line number specified above
There can of course be any number of E1 interfaces/lines and user accounts; the example just shows one for

@ -0,0 +1,31 @@
<orgname>sysmocom - s.f.m.c. GmbH</orgname>
<jobtitle>Managing Director</jobtitle>
<holder>sysmocom - s.f.m.c. GmbH</holder>
Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License,
Version 1.3 or any later version published by the Free Software
Foundation; with the Invariant Sections being just 'Foreword',
'Acknowledgements' and 'Preface', with no Front-Cover Texts,
and no Back-Cover Texts. A copy of the license is included in
the section entitled "GNU Free Documentation License".

@ -0,0 +1,43 @@
osmo-e1d User Manual
Harald Welte <>