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.
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
Hi Harald,
On Thu, Sep 29, 2011 at 09:02:03AM +0900, Harald Welte wrote:
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?
And other signalling bits, but yes, it would be fairly small library.
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.
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.
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.
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
- Rip code from libosmo-abis (input drivers) to implement this new API in libosmo-netif.
- Port openbsc to use this new API in the A interface.
- 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 -
Pablo Neira Ayuso