Due to the changes introduced by the phy_link API, it's not easy to set
the default DSP trace flags via a command line argument anymore. We now
rather introduce a persitent VTY configuration command, by which the
default DSP tracing configuration can be set (for each PHY).
The persistent trace flags are stored in the phy_instance, while the
current operational run-time flags are in fl1h->phy_instance.
This includes changes required for
* shared main() function accross all BTS models
* use of the new phy_link / phy_instance infrastructure as the basis
for true multi-TRX operation
by using a talloc pool, we avoid having to go back to the libc
malloc pool all the time. The msgb allocations and libortp allocations
happen quite frequently during processing and show up as one of the
high priority items in osmo-bts profiles on sysmoBTS with 14 concurrent
TCH/H calls (highest load scenario).
talloc still consumes significant CPU, this is mostly due to the
zero-initialization of all the associated buffers. Strictly speaking
we shouldn't need this, but any change there would require lots of
testing, as there might be hidden assumptions in the code?
In some percentage of cases, talloc still seems to fall back on malloc
for msgb allocations, which is currently a bit of a mystery. The pools
certainly are large enough, talloc_reprt() rarely reports more than a
few tens of kilobytes used by the msgb pool.
From 2ecbf87130
This commit adds basic support for the Litecell 1.5. Multi-TRX is not
supported yet. Instead, multiple instances of the BTS can be launched
using command line parameter -n <HW_TRX_NR> to specify if TRX 1 or
2 must be used by the bts. Note that only TRX 1 opens a connection to
the PCU. Full support for GPRS on both TRX will come at the same time
than the multi-TRX support.
The BTS manager has been adapted to match the new hardware but otherwise
it has not been improved or changed compared to the one used on the
SuperFemto/Litecell (sysmobts).
When the OML signalling link is lost, first set bts->oml_link = NULL,
then iterate over the RSL links and close them. Closing the RSL link
will cause a OML state change message to be sent, which in turn tries
to use the no-longer-existing OML link.
The code should be cleaned up further to distinguish which signalling
link was lost, and actually communicate a RSL(only) loss to OML.
But for now, it's best to simply close down all links and terminate
osmo-bts to ensure all state is properly reset and recovered.
this introduces the new phy_link / phy_instance interface, which is the
basis of clean support for all kinds of multi-trx configurations with
various BTS modules.
WARNING: This breaks configuration file compatibility. You will need to
introduce config nodes for 'phy' and 'instance', as well as the link
from the 'trx' nodes towards the phy instance.
It seems the right thing to do: Once we know a PHY link is established,
the associated OML managed objects should change their state
accordingly. However, given all the hackery we do with MO states, this
actually breaks things, rather than helping. So I'm disabling that part
for now, but this needs to be re-visited at some point.
This splits the TRX scheduler into a generic part and an osmo-bts-trx
specific part. It is the basis for re-using the scheduler from other
bts modules such as the upcoming osmo-bts-virtual.
the backend is performing the actual encoding and decoding functions,
while the generic part constsits of the TDMA structures and generating
the RTS.ind
The L1 scheduler is a generally useful component that is unfortunately
tied quite a bit into the OsmoTRX support. Let's try to separate it out
by having separate per-trx/per-ts/per-chan data structures pre-fixed
with l1sched_
Using this patch it should be one step easier to use the scheduler for
other BTS models, such as the intended upcoming virtual BTS.
During the L1SAP related changes, somehow an old version of
check_for_ciph_cmd() was re-introduced, which didn't store the N(s) as
part of the lchan. To make things worse, the old code was still present
in the sysmobts specific part, but never executed.
When the oml_link is down or not yet established, we currently lost
any OML messages that were scheduled for transmission to the BSC. Let's
prevent that by keeping a queue of OML messages, which is drained at the
time the OML link comes up again.
Use the right identifier for the timeslot and not the trx number
which would always use ts==0 on the first trx. This should fix
ciphering issues for TS>0 (e.g. SDCCH8 on TS==1)
It seems that once we start to respect the T200 values as specified by
the BSC, we run into all kinds of issues with LAPDm re-transmissions,
REJ frames, unexpected supervisory frames and the like.
The libosmogsm LAPDm T200 defaults of 1s/2s are proven to "work" (i.e.
not expose the above behavior), so let's revert to them until the root
cause of this problem is determined.
The T200 default values should be in milli-seconds (as the variable name
indicates). They are not expected to be divided by the TS 12.21 OML
dividers for T200.
This change doesn't really make a difference with OpenBSC, as the BSC
always sets its own T200 values via OML, overwriting the defaults here.
There's no need to use memcpy(), which adds the risk that the types of
source and destination are not the same (see previous commit). Iterating
over the array and assigning each element is more robust.
t200_ms is an unsigned int [7] array, while the oml_default_t200_ms was
an uint8_t[7] array, which we memcpy() to the former as default
initializer. Fix this by turning oml_default_t200_ms into unsigned int,
too.
Harald Welte
Yves Godin