Together with previous counter L1SCHED_TS_CTR_DL_LATE, it allows
understanding which dl blocks are really lost (never queued) and which
were simply queued too late.
Change-Id: I456d0cfbef1e03b147ce7d968a3ec42dd728fe74
Old _shared one comes from time where we shared header with other
componenets. It's no longer the case sine a logn time ago.
The gsm_data_shared.h is only being included by gsm_data.h nowadays, so
let's simply merge it to simplify header dependency and struct
definitions.
Similarly, gsm_data_shared.c is renamed to gsm_data.c
Change-Id: Id60e7582e3a32dbc5e3531b87b2b49f07aee734d
We should always expect the msgb queue to be ordered by FN, so there's
no use in continue traversing the queue after we found a later primitive
than the one at current time, since next onews will be even more in the
future.
Change-Id: If57fc3d89a74e6cbc79fce80dae7bf4f77e9364d
According to 3GPP TS 08.58, section 9.3.4, BS Power IE indicates
the transmission power attenuation on a particular channel:
+--------------+---------+-----------------+
| Reserved (3) | FPC (1) | Power level (4) |
+--------------+---------+-----------------+
so let's change handling of this IE as follows:
- s/bs_power/bs_power_red/g, so it reflects 'reduction';
- store power attenuation value in dB, not in 2 db steps;
- get rid of ms_power_ctrl.bts_tx_pwr, it's always 0 anyway;
- fix rsl_tx_meas_res(): use lchan->bs_power_red;
- always check if FPC (Fast Power Control) flag is set;
- we don't support it, so reject messages containing it;
- fix rsl_rx_chan_activ(): properly apply the bitmask.
Change-Id: I16cc50dfca102030380a06e16c234d5f6698f38f
For those osmo-bts-trx specific logical channels with a generic
logical channel state associated, let's finally apply the BS Power
reduction (attenuation) value that was received from the BSC.
Change-Id: Ib692ff1a75a80fceccb481839c8514d4b2a547b9
This change simplifies access to generic logical channel state
(struct gsm_lchan) from osmo-bts-trx specific state (struct
l1sched_chan_state), so there is no need to look it up using
get_lchan_by_chan_nr() on receipt of each Uplink burst.
Change-Id: Ic4378020f980845b962f71b9e4b7faea738bc174
This change is similar to what we did for Uplink bursts:
- group all Downlink burst parameters into a single structure,
- allocate it once and pass a pointer to lchan handlers,
- pass a pointer to trx_if_send_burst().
Given that the structure is allocated and (zero-)initialized in
trx_sched_fn(), we can get rid of some memset() calls in lchan
handlers and thus improve the overall performance a bit.
Change-Id: If3014e69746559963569b77561dbf7b163c68ffa
It's easier to maintain the logical channel handlers in separate
files, rather than in a huge one (scheduler_trx.c, ~2k lines).
Change-Id: Ie5663fd90596b4800a4546675a323250bbb24c80
Since we are returning the pointer, it should always be grabbing a
reference (find doesn't do it).
In practice it's not much important since it is always created and not
found.
Change-Id: Ib84636663be2df33d497131c780b010b57f17e32
If for whatever reason (eg fn-advance too small) there's no burst
available for a PDCH TS where EGPRS is enabled, a dummy burst of size GSM_BURST_LEN
would be selected in _sched_dl_burst(), but the nbits length would still be set to
EGPRS_BURST_LEN above by func() pointer (tx_pdtch_fn()).
As a result, trx_if_send_burst() would later read EGPRS_BURST_LEN from the
dummy burst of size GSM_BURST_LEN.
The issue was found by ASan. See OS#4606 for more info.
Fixes: OS#4606
Change-Id: Iba6ccceed5c0f1db810259768678f174d39cbf8b
it was perceived that sometimes based on order of events (OML attr setup
and timing of RSL connections, etc.), the NOMTXPOWER for TRX!=0 can come
after the RSP POWERON, and hence the target power level for TRX!=0 is
not done correcty. This can be seen by running any test using the
ttcn3-bts setup of docker-playgrounds.git.
Change-Id: I2ec8dba61393be6edfab9e7e478e096e2d0933ad
The nominal transmit power is still only configurable manually from
osmo-bts-trx VTY interface. Support to retrieve the nominal power
from osmo-trx will come later.
Change-Id: Ia7c353e4c199e0fc3bcab55c45a4abda2c66d2c1
It's not something useful to see unless someone's really debugging that
part, and it shows up quite frequently.
Change-Id: I3c0dee36c7d34e6b1341b517ce3bcd1b275e69c1
Looking at GSMTAP during handover, I've noticed many packets on
RACH looking pretty much like false positives, all with RA=0x00.
I correlated GSMTAP traces with TRXD traces, and figured out
that they all are triggered by NOPE indications from osmo-trx.
Since a NOPE.ind carries no valid burst, all its bits are set to
zero. Funny enough, this sequence is still decoded just fine as
a valid RACH, so that's why we see it on GSMTAP. Later on it
gets rejected by L1SAP due to bad RSSI, ToA, and/or C/I ratio.
The is a side effect of [1]. In order to ensure proper Uplink
measurement reporting during handover, including the time
before the handover RACH is received, let's treat and handle
NOPE indications as Normal Bursts.
[1] Ice45d5986610d9bcef2a7e41f0a395ec779e3928
Change-Id: Ic69f3bc2b776a23374c28a6884080a54bc16ef5f
Related: OS#4592
It was a very bad idea to mix "public" BTS features, that are
reported to the BSC via OML, and those features, that are used
locally (and exclusively) in osmo-bts.
Why? At least because we already have the BTS feature manipulation
API in libosmocore, that is used by osmo-bsc, but for some reason
not by osmo-bts. New features added to libosmocore would clash
with the existing "internal" ones like BTS_FEAT_MS_PWR_CTRL_DSP.
So what this change does can be described as follows:
- remove duplicate definition of the "public" features,
- use libosmocore's API for the "public" features,
- separate both "internal" and "public" features:
- the "public" features continue to live in bitvec,
- the "internal" features become flags,
- s/BTS_FEAT/BTS_INTERNAL_FLAG/g.
Change-Id: Icf792d02323bb73e3b8d46384c7890cb1eb4731e
EGPRS support, in particular MCS channel coding, was introduced
to osmo-bts-trx years ago, but we still report that it's not
supported. Let's stop confusing BSC, and set this feature too.
Change-Id: Iaf92764d266e12efd2350967deffae50fbbb3b9e
An additional octet is only needed if total number of features
cannot be devided by 8 without the remainder. Fix this.
Change-Id: Ie501e5a635493830e0597f7b2fa287b6448e660d
This makes use of the newly-introduced lapdm_channel_init3() API,
which provides the user (BTS in this case) to provide a human-readable
string identifier for each LAPDm channel. This identifier is
subsequently used in all related log lines to provide context.
This means we will now get context information about which specific
SAPI in which sub-channel (ACCH/DCCH) on which lchan/ts/trx/bts a given
message originated from.
Example:
DLLAPD <0011> lapd_core.c:829 ((bts=0,trx=0,ts=0,ss=0)[DCCH][0]) SABM(E) received in state LAPD_STATE_IDLE
Change-Id: I17e3d4797ec71e31d0775330ae36d2e1fd70423f
Depends: libosmocore.git Ie6742843fff809edffcac24c4dce4edf66bc71be
Related: OS#1938
This is not the right place to ship configuration examples for
other projects, and definitely not for abandoned ones.
Change-Id: Ib165b16f948126df8023bb42ad5d6d4b2fc11e6a
- get rid of gsm_lchan::mr_bts_lv, it's never used anyway,
- check IE length in amr_parse_mr_conf() before parsing,
- check return code of amr_parse_mr_conf().
Change-Id: Ibfd5845ea429945b352dd14421e86562998d65ca
Pau Espin
Vadim Yanitskiy
Harald Welte