Recent commit (see below) changed a check to avoid weird results for msg
which had l2h=NULL, since l2len would return unexpected results there.
However, some code branches like FACCH or TCH seem to be always setting
l2h even if len=0. Hence, we must test either of the 2 scenarios (null
pointer and l2len()).
This commit fixes the following message appearing all the time during
calls:
"""
TCH/F: Prim has odd len=0 != 23
"""
Fixes: fb905b8d23
Related: SYS#5676
Related: SYS#4919
Change-Id: I43152bc8484a35cd004d3303d3a6e6efcdefa890
It could happen if for instance l1 code called trx_sched_clean() when
closing the phy, and after that some code called (erroneously)
trx_sched_set_lchan(). Let's make sure we don't allow other modules to
crash the process when using this function.
Related: SYS#4971
Change-Id: I93af7c3dcf0e34e9317eec0ee183dbf18b8d2f3b
msgb_l2len() will return nonzero values if msg->l2h is NULL.
Let's check against msg->l2h being NULL instead.
Related: SYS#5676
Related: SYS#4919
Fixes: 300e31ed13
Change-Id: I18b61fcaa858a53887191a18d560c2e929478c64
The new [bit-]fields in the RSL_IE_OSMO_TEMP_OVP_ACCH_CAP allow
more fine-grained control over the overpower feature, which
can be enabled:
* for both SACCH and FACCH,
* for SACCH only, or
* for FACCH only.
Change-Id: Iaaab675a20bbefece832d913963c8c5ae32ff80c
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
The new fields in 'struct abis_rsl_osmo_temp_ovp_acch_cap' allow:
* selectively enabling SACCH and/or FACCH,
* setting the RxQual (BER) threshold.
Both features are implemented in the follow-up commits.
Change-Id: I370c8f95fb64eceb60a9dc2eae1412f8a0df0f4e
Depends: Ia28293a12de0af71f55e701fb65c46e905dae217
Related: SYS#5319
GSM/EDGE Evolution and Performance, Section 12.3 suggests Temporary
Overpower as another solution to improve SACCH/FACCH performance in
case of bad C/I. The idea here is that you increment the DL transmit
power by 2..4dB only for FACCH/SACCH bursts, while keeping all voice
bursts at the lower (normal) level as determined by BS power control.
SACCH blocks can be recognized by the channel type, since they're
always transmitted in specific frames of a multiframe. FACCH blocks,
however, are not predictable and can substitute voice blocks at
(almost) any time. Thus we need to mark FACCH bursts as such in
the logical channel handlers (using TRX_BR_F_FACCH).
Change-Id: Ie8a626fefccf1eb07271058e5126ec106cb1abcf
Related: SYS#5319
When I introduced this branch in change [1], I was under assumption
that PDCHs never have an associated 'struct gsm_lchan'. This is
incorrect: the association actually happens during PDCH activation,
i.e. when osmo-pcu establishes connection over the PCUIF.
Enforcing attenuation of 0 dB for other channel types makes no sense.
[1] I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Change-Id: I77a839725f22be1be4a025f579c4c9ccdfb53460
There is no need to log channel activation / deactivation messages
as LOGL_NOTICE - this is a normal event requiring no attention.
Change-Id: I7765fecb7f7ec67c8f96e91c378626e21e48c71d
The BCCH carrier (sometimes called C0) of a BTS shall maintain
discontinuous Downlink transmission at full power in order to
stay 'visible' to the mobile stations. Because of that, early
versions of 3GPP TS 45.008 prohibited BS power reduction on C0.
However, in the recent 3GPP TS 45.008 there is a feature called
'BCCH carrier power reduction operation'. This is a special
mode of operation, where the variation of RF level for some
timeslots is relaxed for the purpose of energy saving.
In BCCH carrier power reduction operation, for timeslots on the
C0 carrier, except timeslots carrying BCCH/CCCH, the output power
may be lower than the output power used for timeslots carrying
BCCH/CCCH. In this case the maximum allowed difference in output
power actually transmitted by the BTS is 6 dB.
The power reduction operation can be controlled by the BSC by
sending BS POWER CONTROL on the A-bis/RSL with the Channel Number
IE set to 0x80 (RSL_CHAN_BCCH). This makes osmo-bts reduce the
transmission power on inactive timeslots of the BCCH carrier.
This is a non-standard, Osmocom specific extension, so indicate
support of this feature to the BSC in the feature vector. Also
add a VTY command to allow enabling/disabling the power reduction
locally. Add some signalling notes to the A-bis/RSL manual.
For more details, see 3GPP TS 45.008, section 7.1.
Change-Id: I3dcee6e910ccc61c5c63c728db9ea04327e2fc98
Depends: I69283b3f35988fc7a1a1dcf1a1ad3b67f08ec716
Related: SYS#4919
I introduced this regression in [1] during a massive refactoring.
Basically, I copy-pasted a chunk from trx_sched_ph_data_req(), but
forgot to change the union field. This broke voice calls, because
all TCH.req primitives would be enqueued to wrong timeslot.
Change-Id: If841e6ac40a3c6344c304ab970755d6a2d292156
Fixes: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
We already do the intereference measurements on inactive logical
channels. For the active channels we can still use the IDLE
slots, on which the UEs shall not transmit Uplink bursts.
Change-Id: Ic3030dba5eb223177298aa4e43559a93dc3d1392
Related: SYS#5313, OS#1569
Neither we expect any Uplink bursts on IDLE channels, nor we need
to send any Downlink bursts. Automatic activation of TRXC_IDLE
channels does not make sense.
Change-Id: Ifade0eab0605154196322ff20b1b3a44495f8a2e
In trx_sched_ul_burst(), treat all BURST.ind and NOPE.ind mapped
to inactive logical channels as interference. Average the RSSI
values on the fly using a sliding average with constant a=0.5.
Report averaged values for each logical channel every 104 TDMA
frames (SACCH period) by calling gsm_lchan_interf_meas_push().
Change-Id: I4686448e42a40df56c1d27a14fd0a4d43fd144a5
Related: I78b6d8beffa5228a28231b75728e7aebdd3cb23c
Related: SYS#5313, OS#1569
Thanks to [1], it's now possible to associate a human-readable
name with a rate counter group. Before this API, we had to use
weird index values for each timeslot, and with introduction
of the shadow timeslots the situation got even worse.
Change-Id: Ie872ab37661fa5d44f219f59c7daaa1033113289
Depends: [1] I0dc510783dd9ae8436dae8005a7b3330e80d36f3
Related: SYS#4895, OS#4941
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts'
is always initialized in oml_rx_set_chan_attr() during the OML
bootstrapping, so there is no need for gsm_ts_tsc() - remove it.
Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can
apply a different TSC value during the RSL CHANnel ACTIVation.
Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'.
These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS'
field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros.
Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b
Related: SYS#4895, OS#4941
We assume that it's legal to have dangling PHY instances that are
not associated with any TRX instances in the configuration file.
Obviously, such PHY instances have pinst->trx set to NULL.
The DSP based models seem to handle dangling PHY instances without
any problems, so let's ensure that we always check pinst->trx
against NULL in the osmo-bts-{trx,virtual} specific code.
Change-Id: Ib7d9cb7ae47fead723fa46454cd64bf6e88756bb
Fixes: CID#236092 "Dereference before null check"
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
Similar to what we have been doing for TCH channels, we want to make
sure all MAC blocks get to the upper layers, even if containing invalid
data (flagging it with data_len=0) so that upper layers (osmo-pcu
through PCUIF in this case) can rely on FN clock without gaps due to
Rx errors.
Related: OS#5020
Change-Id: I343c7a721dab72411edbca816c8864926bc329fb
We already have MS Power Control, which according to 3GPP 45.008
shall be implemented in the MS to minimize the transmit power in
the Uplink direction. The BS Power Control may optionally be
implemented by the network side for the same purpose.
Using Downlink signal measurements reported by the MS, the BSS
(either BSC, or BTS) may control Downlink attenuation in a way
that the transmit power remains as low as possible, or remains
in a specific range corresponding to good RxLev values on the
MS side. This change implements autonomous BS Power Control,
that can optionally be enabled by the BSC.
BS Power Control re-uses parts of the MS Power Control code,
so all parameters can be configured in the same way - via the
VTY interface or a configuration file. This basically means
that features like hysteresis and EWMA based filtering are
also available for BS Power Control.
The only difference is that RxQual values higher than 0 would
trigger the logic to reduce the current attenuation twice.
Note that one of the unit tests ('TC_rxlev_max_min') fails,
as the power step limitations for raising and lowering look
wrong to me, and the related discussion is still ongoing.
Change-Id: I5b509e71d5f668b6b8b2abf8053c27f2a7c78451
Related: SYS#4918
Sometimes the following messages appear in the logging output:
TCH/F: Prim has wrong chan_nr=0xc5 link_id=00, expecting chan_nr=0x0d link_id=00
TCH/F: Prim has wrong chan_nr=0xc2 link_id=00, expecting chan_nr=0x0a link_id=00
when a dynamic timeslot is switched from PDCH to TCH/F (or to TCH/H).
This means that the transmit queue of a timeslot still contains
PDCH frames, that were not properly cleaned on PDCH deactivation.
Let's finally do this in trx_sched_set_lchan().
Change-Id: Ic6560c660c658f36b84e7efa2f1d93e3a870962b
Related: SYS#5108, OS#4804
Trying to (de)activate logical channels that are already (de)activated
is not something that we normally expect. Treat this as error.
Change-Id: I6256280cae35b2b4d7a8ba4b3913ca69cde22611
In this function we already do check that a given timeslot is not
a PDCH slot, so checking if TRX_CHAN_FLAG_PDCH is redundant.
Change-Id: Ie73bdaf0f6bc76ed8d2e95d1fb995333bf617e7e
Both TRXC_PDTCH or TRXC_PTCCH are described in 'trx_chan_desc'
(defined as 'const'), and both have TRX_CHAN_FLAG_PDCH set. So
indeed, this condition can never be true.
Change-Id: Ie185a939b48eb859ac1c8ffa0a4f667fda0cb82b
This change facilitates the upcoming freq. hopping implementation,
in particular scheduling of dummy bursts on C0 with hopping time-
slots. One problem is that we cannot know in advance, whether to
send a dummy burst on a given timeslot unless all transceivers are
processed. For example, trx#3 may want to send a normal burst on
ARFCN of trx#0 (C0), while we have already sent a dummy burst...
Another important aspect is that we shall not be sending dummy
bursts on transceivers other than C0. Scheduling dummy bursts
from _sched_dl_burst() in the context of a single hopping timeslot
of a single transceiver leaves trx_sched_fn() no way to know
whether it's a dummy burst or something else.
Let's solve both problems by moving dummy burst scheduling logic
from _sched_dl_burst() to trx_sched_fn(). Maintain C0 slot-mask
in the inner (per-trx) loop, so that we can fill missing bursts
with dummy bursts afterwards.
Change-Id: I8c3651c27d2991079e83b8abdb7e2c3f95b97a43
Related: SYS#4868, OS#4546
Vadim Yanitskiy
Pau Espin
Eric Wild
Neels Hofmeyr