| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
TS 08.58 requires that BTS-autonomous MS power control is _not_ used,
if only the MS Power IE is present in a channel activation. Rather, in
order to enable the BTS-autonomous power control loop, the MS Power
Parameters must be included.
So far we were always enabling MS power control, even in the absence of
the MS Power parmeters IE. This is fixed now. This meanas you will
need a correspondingly new OsmoBSC/OsmoNITB that sends this IE, or you
loose MS (uplink) power control altogether.
The content of the MS Power Parameters IE is parsed, but the threshold
values not used yet at this point.
|
|
|
|
API revision 5.1 allows us to pass a version number for the rx/tx
calibration and the DSP/FPGA will inform us about clock errors.
|
|
[hfreyther: Accept the mixing of whitespace to ease future
merges]
|
|
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.
|
|
|
|
In some situations, a PHY might send us a primitive for a logical
channel that is not (or no longer) active. Passing such primitives
higher up the stack is asking for trouble. Specifically, LAPDm
instances cannot accept messages once their instance has been released.
We introduce two new helper functions: get_lchan_by_chan_nr() as well as
get_active_lchan_by_chan_nr(). The former just centralizes the look-up
of the lchan by timeslot number and sub-slot number. The latter also
checks to ensure the lchan is active, which is used for PH-DATA / PH-RTS
primitives. To the contrary, MPH primitives generally don't require the
cahnnel to be active for processing.
|
|
we shouldn't consider the presence of a valid measurement result
as something NOTICEable
|
|
|
|
The way we recycle the msgb with a l1sap header when transforming a
PH-DATA.req L1SAP primitive into a PHY/L1 primitive was flawed in
several ways:
1) the way the L1SAP header was stored in the buffer didn't provide
sufficient tailroom for the L1 primitive
2) the alignment of the data in L1SAP is at a 32bit bounadry, but not
in the L1 primitive, causing unaligned accesses.
|
|
This was introduced in openbsc.git a2bbc5ec0e6481bb5b65da7bdbde03a424437af4
|
|
probably a git merge artefact of some sort...
|
|
OpenBSC introduced a naming change in
615ed46a6ab25f71a7ab0d8201d33b4dbf8fc5b0 but osmo-bts fixes were only
about osmo-bts-sysmo, not osmo-bts-trx. This updates osmo-bts-trx
accordingly.
|
|
This also ensures that a missing ortp library dependency is discovered
at configure time already
|
|
This reverts commit 94a05abb98fcb1a5002f327888635f3af860c9a9.
The tests don't work well with subdir-objects, so we have to live with
the warnings meanwhile until somebody finds time to find the magic spell
to solve the autotools quest.
|
|
|
|
automake: warning: possible forward-incompatibility.
automake: At least a source file is in a subdirectory, but the 'subdir-objects'
automake: automake option hasn't been enabled. For now, the corresponding output
automake: object file(s) will be placed in the top-level directory. However,
automake: this behaviour will change in future Automake versions: they will
automake: unconditionally cause object files to be placed in the same subdirectory
automake: of the corresponding sources.
automake: You are advised to start using 'subdir-objects' option throughout your
automake: project, to avoid future incompatibilities.
|
|
|
|
|
|
|
|
Use the bts_modes for all the types. As there are two instances
know. One for the ms and one for the bts.
Manual compile fix and not tested on HW
|
|
|
|
This somehow got lost during the latest rebase.
|
|
|
|
|
|
We've added logging calls to the bursts processing. Add logging facility
initializatoin to the test code.
|
|
Not really a bug, as we're smart about it down the stream, but it's better to
be strict here as well.
|
|
osmo-trx never supported separate power control for trx's, but now it started
to be more strict about it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A known issue with this code is that BER is not updated for lost TCH frames,
because osmo-trx doesn't send any indication for them and we don't have
a callback to handle this.
Otherwise the code seem to work fine.
|
|
3GPP TS 05.03 "Channel coding" specifies the puncturing matrix (1,0,1)
for class 1 information bits and tail bits valued u(0) to u(103) for a
maximum puncturing index of 311. The puncturing index 313 exceeds the
maximum index and causes osmo_conv_get_output_length() to output the
improper length of 210 instead of 211.
Signed-off-by: Thomas Tsou <tom@tsou.cc>
|
|
If frame number is out of range (>= 2715648), the scheduler's process
would end up in an infinite loop. This is because the loop would schedule
bursts until the indicated frame number is reached, which would not be
possible.
The openbts, calypso-bts and osmo-trx might send out out of range clock
indications every 3.5 hour.
|
|
|
|
|
|
|
|
|
|
RTS (ready-to-send) must be issued in advance, so BTS core and especially
osmo-pcu can provide downlink data frames early enough. In some cases PCU
might provide frames too late, so they must be dropped. If PCU provides
frames too late, due to high system load, this "RTS advance" setting must
be increased.
|
|
|
|
Since automake 1.13 INCLUDES is depricated and causes a warning
Inspired from similar patches by Alexander Huemer for other osmocom
projects.
|
|
|
|
Instead of limiting the number of TRX at VTY to the actual number of
supported TRX, VTY allows to configure any possible number of TRX. If a
TRX is configured, which is not supported by BTS model, an error message is
returned, which states that the given TRX is not supported.
|
|
|
|
|
|
|
|
This is required, so the transceiver transmits no power.
|
