27 Sep
2011
27 Sep
'11
8:47 a.m.
Hi,
After some private discussion with Harald, I'd like to propose one new
library to abstract the network interface that is used to communicate
two elements that are part of one GSM network (no matter if it's on
the A-bis interface, A interface, ...).
This new library, whose proposed name can be "libosmo-net", would
initially support:
- E1 interfaces.
- Ethernet + IPA TCP/IP.
- rs232 (as required by bs11 its config interface).
This support is included in libosmo-abis, so my idea is to extract
this code from it and leave in libosmo-abis only the specific A-bis
bits.
The libosmo-net library would be extensible, so we can add new
interfaces to it (new E1 cards supported, new protocols over BSD
sockets, and so on).
The interface provided to the client of the library will be homogeneous
for all supported interfaces (at least, as much as we can).
The new library will provide:
* a constructor/destructor to create/release some network interface of
* a given supported type.
* a call-back for receiving incoming messages that will take the
actual msgb.
* one function for sending signalling messages.
As well as many helper functions in this regard.
Therefore, libosmo-abis will require this new libosmo-net library
after all is done.
For the A interface, I'd propose some hypothetical libosmo-a library
that will contain the specific A interface protocols.
Let me know what you think.
28 Sep
28 Sep
8:02 p.m.
Hi Pablo,
On Tue, Sep 27, 2011 at 02:47:12PM +0200, Pablo Neira Ayuso wrote:
This new library, whose proposed name can be
"libosmo-net", would
initially support:
- E1 interfaces.
- Ethernet + IPA TCP/IP.
- rs232 (as required by bs11 its config interface).
This support is included in libosmo-abis, so my idea is to extract
this code from it and leave in libosmo-abis only the specific A-bis
bits.
I'm not sure if such a split is practical. What exactly woould remain
A-bis specific? The TRAU frame handling for voice channels?
For the A interface, I'd propose some hypothetical
libosmo-a library
that will contain the specific A interface protocols.
Once again I'm not entirely convinced that this is neccessarry. We
already have libosmo-sccp for the SCCP parsing routines, and the
BSSAP/BSSMAP layer is handled in osmo-bsc directly. So I don't really
see what would be left over as A-specific parts.
In order to stop further proliferation of small library fragments, I
would rather suggest to include any (if at all) remaining A-bis and A
related parts in the same libosmo-net.
btw: I'm still trying to come up with a better name. libosmo-signalling
is wrong as it will also deal with voice/trau/rtp. libosmo-interface
maybe? Also not a quite obvious naming. libosmo-netif as a compromise?
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
29 Sep
29 Sep
8:33 a.m.
Hi Harald,
On Thu, Sep 29, 2011 at 09:02:03AM +0900, Harald Welte wrote:
OK, we can put all in the same library.
In order to re-use the existing networking interfaces in any GSM
interface, I'm thinking about extracting some code from the e1input
infrastructure and provide some generic API to create, destroy, write
and read data, something like:
#define OSMO_NETIF_T_NONE 0
#define OSMO_NETIF_T_DAHDI 1
#define OSMO_NETIF_T_MSISDN 2
#define OSMO_NETIF_T_IPA 3
#define OSMO_NETIF_T_RS232 4
#define OSMO_NETIF_T_WHATSOEVER 5
struct osmo_netif *osmo_netif_open(int type, ...);
int osmo_netif_close(struct osmo_netif *if);
int osmo_netif_read(struct osmo_netif *if, ...);
int osmo_netif_enqueue(struct osmo_netif *if, ...);
int osmo_netif_write(struct osmo_netif *if, ...);
This would allow to open one net interface of some type, and use it
to receive and to send information over it, no matter in it's on the
A-bis, A, ... GSM interface.
My preliminary planning could be:
1) Rip code from libosmo-abis (input drivers) to implement this new
API in libosmo-netif.
2) Port openbsc to use this new API in the A interface.
3) Finally, put libosmo-abis into libosmo-netif. After that, we can
consider libosmo-abis obsolete.
Following this approach, we can support several network interfaces in
the A interface soon. Then, we can spend time to supersede libosmo-abis.
Or you consider that the e1input infrastructure is already flexible
enough to support the A interface with relatively minor changes? I'm
not sure.
On Tue, Sep 27, 2011 at 02:47:12PM +0200, Pablo Neira
Ayuso wrote:
And other signalling bits, but yes, it would be fairly small library.
This new library, whose proposed name can be
"libosmo-net", would
initially support:
- E1 interfaces.
- Ethernet + IPA TCP/IP.
- rs232 (as required by bs11 its config interface).
This support is included in libosmo-abis, so my idea is to extract
this code from it and leave in libosmo-abis only the specific A-bis
bits.
I'm not sure if such a split is practical. What exactly woould remain
A-bis specific? The TRAU frame handling for voice channels? For the A
interface, I'd propose some hypothetical libosmo-a library
that will contain the specific A interface protocols.
Once again I'm not entirely convinced that this is neccessarry. We
already have libosmo-sccp for the SCCP parsing routines, and the
BSSAP/BSSMAP layer is handled in osmo-bsc directly. So I don't really
see what would be left over as A-specific parts.
In order to stop further proliferation of small library fragments, I
would rather suggest to include any (if at all) remaining A-bis and A
related parts in the same libosmo-net. btw: I'm still trying to come up with a better
name. libosmo-signalling
is wrong as it will also deal with voice/trau/rtp. libosmo-interface
maybe? Also not a quite obvious naming. libosmo-netif as a compromise?
libosmo-netif sounds fine to me.
30 Sep
30 Sep
4:47 a.m.
Hi Pablo,
On Thu, Sep 29, 2011 at 02:33:28PM +0200, Pablo Neira Ayuso wrote:
In order to re-use the existing networking interfaces
in any GSM
interface, I'm thinking about extracting some code from the e1input
infrastructure and provide some generic API to create, destroy, write
and read data, something like:
#define OSMO_NETIF_T_NONE 0
#define OSMO_NETIF_T_DAHDI 1
#define OSMO_NETIF_T_MSISDN 2
#define OSMO_NETIF_T_IPA 3
#define OSMO_NETIF_T_RS232 4
#define OSMO_NETIF_T_WHATSOEVER 5
struct osmo_netif *osmo_netif_open(int type, ...);
I think this should probably be a _reconfig() function, i.e. something
that can process incremental changes to the configuration. It is very
likely that the BSC process runs for a long time, and the E1 timeslot
configuration / or other signallign configuration changes during
runtime. So an initial "open" is not really sufficient.
The _reconfig() calls could be triggered every time we "exit" from the
VTY node that configures the like or signalling-link.
I also think that the _open() / _reconfig() call could be device type
specific, i.e. something like
struct osmo_netif *osmo_netif_open_dahdi(...);
struct osmo_netif *osmo_netif_open_ipa(...);
...
as the parameters will probably be _very_ device type specific, it might
not make sense to put all of it in one large union of structures.
Also, I expect almost all users to use VTY for configuration, so we
should have library-internal VTY support where we could have something
like this for the VTY parsing inside the library:
% a real circuit A-bis line on E1 (BS-11, Ericsson RBS, ..)
line AbisLine0
description Foobar
driver dahdi
[driver-specific parameters]
% a real circuit A line on E1
line ALine0
description ...
driver misdn
[driver-specific parameters]
% a virtual A line over IPA
line Aline1
description ...
driver ipa-client
ipa-client remote-ip A.B.C.D
ipa-client remote-port <0-65535>
ipa-client unit-id 1234 0
ipa-client authot-ken AbCdEf
% a virtual A-bis line with IPA protocol like nanoBTS
line AbisSrvOML0
description Foobaz
driver ipa-server
ipa-client local-ip A.B.C.D
ipa-client local-port 3003
% a virtual A-bis line with IPA protocol like nanoBTS
line AbisSrvRSL0
description Foobaz
driver ipa-server
ipa-client local-ip A.B.C.D
ipa-client local-port 3002
signalling-link ALine0/0
description MyMscLink
timeslot 1 sub-slot full
encapsulation mtp
[mtp-specific parameters]
signalling-link AbisLine1/0
description MyBtsLink
e1_timeslot 1 sub-slot full
encapsulation lapd
and then something like this (for the BSC):
bsc
a-interface signalling-link ALine0/0
% A BS-11
bts 0
oml tei 25
oml signalling-link Line1/0
trx 0
rsl tei 0
rsl signalling-link Line1/0
% an ip.access nanoBTS
bts 1
oml tei 255 % IPA stream ID
oml line AbisSrvOML0
oml ipa unit-id 1800 0
trx 0
rsl tei 0 % IPA stream ID
rsl line AbisSrvRSL0
rsl ipa unit-id 1800 0
1) Rip code from libosmo-abis (input drivers) to
implement this new
API in libosmo-netif.
2) Port openbsc to use this new API in the A interface.
3) Finally, put libosmo-abis into libosmo-netif. After that, we can
consider libosmo-abis obsolete.
I think the existing libosmo-abis API might very well disappear, OpenBSC
should use the netif library directly even for Abis
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
5042
days inactive
5045
days old
3 comments
2 participants
participants (2)
-
Harald Welte -
Pablo Neira Ayuso