This library is intended to collect all generic/common funcitionality
of all Osmocom.org projects, including OpenBSC but also OsmocomBB
The library currently includes the following modules:
bitvec, comp128, gsm_utils, msgb, select, signal, statistics, talloc, timer,
tlv_parse, linuxlist
msgb allocation error debugging had to be temporarily disabled as it depends on
'debug.c' functionality which at the moment remains in OpenBSC
The way the VTY configuration sytem works is that it first registers a
BTS of type GSM_BTS_TYPE_UNKNOWN and then sets the type correctly (after
encountering the type statement). This makes sure that registering a BTS
of type UNKNOWN succeeds.
Some NM attributes are defined differently depending on
the BTS type. Having one big nm_att_tlvdef[] table for
all BTS types is no longer sufficient. This patch
* introduces 'struct gsm_bts_model' to describe a BTS model
* adds definitions of gsm_bts_model for BS-11 and nanoBTS
* changes the abis_nm_tlv_parse() function: include a bts pointer
The VTY code makes so many allocations that a full report is
simply too long to provide any useful information. So we sub-divide
it in multiple contexts, and report only one level deep at SIGURS1.
We also introduce SIGUSR2 for the full detailed VTY report.
Change the counters_store_db function to be a generic for_each
function taking a function pointer and data. Use that in bsc_hack
to store it to the DB.
This is removing the DB requirement and will allow to handle
the counter values in different ways without making the counter
list public.
I verified that the syncing is still taking place.
This is the new logging architecture, including
* support for multiuple logging targets like stderr and vty
* log levels in addition to categories/subsystems
* filtering based on imsi, i.e. only see events for one subscriber
* dynamically change log level for each category for each vty
With this commit, we can successfully hand over a channel from one cell to
another cell. We implement asynchronous intra-BSC (but inter-BTS) handover.
Changes:
* introduce new DHO log category
* extend rsl_chan_activate_lchan() with argument for HO reference
* introduce actual minimal handover decision making in handover_decision.c
* various fixes to bsc_handover_start() in handover_logic.c
We might read or write on the OML link when the BTS is
reset and will get SIGPIPE interrupt and be gone... Just
ignore the SIGPIPE we will get the "exception" on the next
run of bsc_select and kill the (old) OML link.
Share the initialization and bootstraping of the network by moving
the code to a new file and making boostrap_network and shutdown_net
external.
Cleanup the header list after the move and remove trailing whitespace.
the various constructors get called in a non-obvious, linker determined
order, which makes certain objects disappear from the talloc report.
This change moves the talloc context creation into a new talloc_ctx.c file
This means that the config file is now finally the central source of not only
the E1 configuration on the BSC, but also the E1 and GSM channel configuration
on the BTS.
Using this option, you can use two BS-11 connected to the same E1
link. The first BS-11 needs to have BPORT0 and BPORT1 objects created with E1
Line Configuration attribute "multi-drop". The second BS-11 is configured with
only BPORT0 in star configuration, and needs to have the OML signalling on TS6
instead of TS1. Also, a kernel patch providing a second virtual E1 interface
is needed.
* remove old HAVE_TRX1 definition, replace it with '-1' commandline argument
* make sure we actually configure the OML TRX attributes with a different
ARFCN than TRX0
* make sure we configure timeslot 0 of TRX1 also in TCH/F mode
This code is untested, but if you have a dual-trx BS-11, and the second TRX
is activated, you should be able to run bsc_hack with the -1 option to enable
and use the second trx. It works like this:
* TRX1 shares E1 timeslot 0 for signalling
* TRX1 RSL link uses TEI2 (TRX0 uses 1)
* TRX1 on ARFCN+2, i.e. if you have TRX0 on 122, TRX1 will be 124
Up until now, we only supported direct RTP streams between ip.access BTS.
With this commit, the user can specify '-P' to the command line to enable
a RTP/RTCP proxy inside OpenBSC. The nanoBTS will then send all their voice
data to OpenBSC, which will relay it to the respective destination BTS (which
can be the same BTS).
The default behaviour remains unchanged. Without '-P' on the command line,
RTP/RTCP is exchanged directly.
Harald Welte
Harald Welte