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
bts.h refers to struct gsm_bts object, but we still had a bunch of stuff
in bulky gsm_data.* from old days. Let's move stuff where it belongs to
start clean up of gsm_data.
Change-Id: I0a4219e3f64f625ee8b364bf408b8d2bcc8085c5
According to 3GPP 45.002, section 5.2.4, a frequency correction
burst is basically a sequence of zeros. Since br->burst is already
zero-initialized, there is no need to maintain and memcpy() another
sequence of zeros into it. Just set the length.
Change-Id: Ic4f6d550010da5caf4bc471ff1e184c9fab30c6d
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
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
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
Currently we do not detect any of the DTX frames (SID_FIRST, SID_UPDATE
etc.) Detecting and tagging those frames as is_sub is important for
measurement processing. Also the RTP marker bit must be set on each
ONSET frame.
- Add detection of DTX frames
- Tag DTX frames as is_sub and set frame type to AMR_SID
- Set RTP marker bit when ONSET frames are received
Change-Id: I5afe730fff2fa3199a5913b0de4f5c7b23a39f31
Depends: libosmocore I2bbdb39ea20461ca08b2e6f1a33532cb55cd5195
Related: OS#2978
When a NOPE indication is received from the TRX normally a separate
handler (.nope_fn) is called. It turned out that calling the Uplink
handler (.ul_fn) on NOPE indications is the usual case, so let's
remove the .nope_fn member and call the Uplink handler directly.
Since a NOPE.ind comes without burst bits, the Uplink handlers must
check bi->burst_len to avoid uninitialized memory access. For some
logical channels (in particular RACH, PDTCH/U, and PTCCH/U) it does
not make sense to call the Uplink handler, so we ignore them.
Change-Id: Ice45d5986610d9bcef2a7e41f0a395ec779e3928
Related: OS#4461
Without using the NOPE indication it might happen that we get
into the following situation:
* bursts 0,1,2 of a given block are received
* burst 3 is lost on the radio interface, OsmoTRX sends NOPE
* osmo-bts-trx doesn't pass the NOPE the the rx_tch*_fn()
* we never detect the end of the block, never perform decoding
and even if the burst could be fully decoded, we loose the block
Related: OS#4661
Related: OS#2975
Change-Id: Idfc5c9a23db808c5f87ef5646c7e1d1cd3127371
Without using the NOPE indication it might happen that we get
into the following situation:
* bursts 0,1,2 of a given block are received
* burst 3 is lost on the radio interface, OsmoTRX sends NOPE
* osmo-bts-trx doesn't pass the NOPE the the rx_tch*_fn()
* we never detect the end of the block, never perform decoding
and even if the burst could be fully decoded, we loose the block
For voice, it can lead to lost RTP frames in uplink, which is also
problematic.
Let's deal with burst_len=0 in rx_tch*_fn() and use it as nope_fn.
Closes: OS#4661
Related: OS#2975
Change-Id: I0fbf4617daf24bd8aecfd9cfe1efd66cf73a277a
The MPH INFO MEAS IND indication, which contains the uplink measurement
data is sent in parallel to the PH DATA and TCH indications as a
separate indications. This makes the overall uplink measurement data
processing unnecessarly complex. So lets put the data that is relevant
for measurement into the PH DATA and TCH indications directly.
This change only affects osmo-bts-trx at the moment. In order to keep
the upper layers (l1sap.c) compatible we add an autodection to switch
between separate measurement indications and included measurement data.
Related: OS#2977
Depends: libosmocore I2c34b02d329f9df190c5035c396403ca0a4f9c42
Change-Id: I710d0b7cf193afa8515807836ee69b8b7db84a84
osmo-bts currently does not generate a measurement report in case the
SACCH of the related traffic channel is lost. This is a problem because
the moment when reception gets bad measurmenet reporting is crucial to
carry out handover decisions effectively.
The presence of a SACCH block controls the conclusion of the measurement
interval and the sending of the RSL measurement report. The latter one
not only requires a measurmenet indication, it also requires a fully
intact SACCH block.
Lets use the NOPE / IDLE indications from V1 of the TRXD protocol to
ensure a SACCH block is always reported up to l1sap.c. In cases where
the SACCH is bad, trigger the sending of the RSL measurement report
manually without attaching the measurmenet data from the MS (which we do
not have in this case)
Related: OS#2975
Depends: osmo-ttcn3-hacks Ib2f511991349ab15e02db9c5e45f0df3645835a4
Change-Id: Idfa8ef94e8cf131ff234dac8f93f337051663ae2
Each logical channel can now optionally have an additional handler,
that will be called when a NOPE / IDLE indication is received from
the transceiver. The aim of that handler is to keep the logical
channel state updated in case if one or more Uplink bursts are lost.
Change-Id: I71c552f44c25e56e9779d8b8ef5d4de9f8475637
Related: OS#3428
According to 3GPP TS 45.010, section 5.6.2, for packet-switched
channels the BTS shall monitor the delay of the Access Bursts
sent by the MS on PTCCH and respond with timing advance values
for all MS performing the procedure on that PDCH.
According to 3GPP TS 45.002, section 3.3.4.2, PTCCH (Packet Timing
advance control channel) is a packet dedicated channel, that is
used for continuous Timing Advance control (mentioned above).
There are two sub-types of that logical channel:
- PTCCH/U (Uplink): used to transmit random Access Bursts
to allow estimation of the Timing Advance for one MS in
packet transfer mode.
- PTCCH/D (Downlink): used by the network to transmit
Timing Advance updates for several MS.
As per 3GPP TS 45.003, section 5.2, the coding scheme used for
PTCCH/U is the same as for PRACH as specified in subclause 5.3,
while the coding scheme used for PTCCH/D is the same as for
CS-1 as specified in subclause 5.1.1.
The way we used to handle both PTCCH/U and PTCCH/D is absolutely
wrong - they have nothing to do with xCCH coding. Instead, we
need to use tx_pdtch_fn() for Downlink and rx_rach_fn() for Uplink.
In l1sap_ph_rach_ind() we need to check if an Access Burst was
received on PTCCH/U and forward it to OsmoPCU with proper SAPI
value (PCU_IF_SAPI_PTCCH). To be able to specify a SAPI, a new
parameter is introduced to pcu_tx_rach_ind().
Change-Id: I232e5f514fbad2c51daaa59ff516004aba97c8a3
Related: OS#4102
Otherwise using "logging level set-all info" makes it impossible to see
anything in VTY due to tons of those two lines appearing.
Change-Id: I9c7500c1e56db0c4dcb474f93c882a9c7c004d55
This change needs to be done in order avoid adding more and more
arguments to the UL logical channel handlers (such as rx_rach_fn).
Since we have different versions of the TRXD header, and may have
other burst-based PHYs in the future, some fields of an Uplink
burst indication have conditional presence.
Change-Id: Iae6b78bafa4b86d0c681684de47320d641d3f7c0
Related: OS#4006, OS#1855
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
Let's avoid fancy alignment in the description of logical channels
for the benefits of having better readability, the ability to add
more comments and fields without making it look ugly.
Get rid of value-string array 'trx_chan_type_names', since each
logical channel has its name defined in 'trx_chan_desc'.
Get rid of field 'chan' of 'trx_lchan_desc' structure since it's
not used anywhere, and not actually needed because the position
of each lchan description is defined by its TRXC_* type.
Replace both 'pdch' and 'auto_active' fields with more generic
bitmask field called 'flags', and define the following flags:
- TRX_CHAN_FLAG_AUTO_ACTIVE,
- TRX_CHAN_FLAG_PDCH.
Use RSL channel mode #defines from libosmogsm instead of having
hard-coded numbers. This increases readability.
As a bonus, let's add a human readable description to each lchan
definition, so it can be printed in the VTY some day.
Change-Id: I9d5d49ec569f133d37b8164b22607d4700474315
Backported from: I2fc61e1cdca4690a34e2861b9ee3b7c64ea64843
I7ab4958801b3422973b67ff0452b90afa8a3f501
This change modifies the logic of TDMA frame loss tracking. To
be more precise, the tracking logic was moved from per timeslot
level to per logical channel level, what makes OsmoBTS more
accurate in its measurements.
But before getting into details, it's important to clarify some
things about the Uplink burst processing in transceiver (OsmoTRX).
If an Uplink burst is detected, OsmoTRX demodulates it and sends
to OsmoBTS. If nothing is detected on a particular timeslot,
OsmoTRX will do nothing. In other words, it will not
notify OsmoBTS about this.
Meanwhile, there are usually a few logical channels mapped to a
single TDMA timeslot. Let's use SDCCH8 channel configuration as
an example (simplified layout):
/* SDCCH/8 (ss=0), subscriber A (active) */
{ TRXC_SDCCH8_0, bid=0 },
{ TRXC_SDCCH8_0, bid=1 },
{ TRXC_SDCCH8_0, bid=2 },
{ TRXC_SDCCH8_0, bid=3 }, // <-- last_fn=X
/* SDCCH/8 (ss=1), subscriber B (inactive) */
{ TRXC_SDCCH8_1, bid=0 },
{ TRXC_SDCCH8_1, bid=1 },
{ TRXC_SDCCH8_1, bid=2 },
{ TRXC_SDCCH8_1, bid=3 },
/* SDCCH/8 (ss=2), subscriber C (active) */
{ TRXC_SDCCH8_2, bid=0 }, // <-- current_fn=X+5
{ TRXC_SDCCH8_2, bid=1 },
{ TRXC_SDCCH8_2, bid=2 },
{ TRXC_SDCCH8_2, bid=3 },
SDCCH8 has 8 sub-slots, so up to 8 subscribers can use a single
timeslot. Let's imagine there are three subscribers: A, B, and C.
Both A and C are active subscribers, i.e. they are continuously
transmitting UL bursts, while B is not using ss=1 anymore.
The original way of TDMA frame loss tracking was the following:
- when an UL burst is received, store it's frame number in
the timeslot state structure (last_fn);
- when the next UL burst is received on same timeslot, compute
how many frames elapsed since the last_fn;
- if elapsed = (current_fn - last_fn) is lower than 10, then
iterate from (last_fn + 1) until the current_fn and send
dummy zero-filled bursts to the higher layers;
- otherwise (elapsed > 10), process the current burst,
and do nothing :/
According to our example, subscriber A is sending 4 bursts, then
nobody is sending anything, and then subscriber C is sending
4 bursts. So, there is a 4 frames long gap between the both
transmissions, which is being substituted by dummy bursts. But,
as the logical channel on ss=1 is not active, they are dropped.
This is not that scary, but the current algorithm produces lots
of false-positives, and moreover is not able to track real frame
drops in longer periods (i.e. >10). So, tracking the frame loss
per individual logical channels makes much more sense.
Let's finally drop this hackish 'while (42) { ... }', and track
the amount of lost / received TDMA frames (bursts) individually
per logical channels. Let's also use the multiframe period as
the loss detection period, instead of hardcoded 10. And finally,
let's print more informative debug messages.
Also, it makes sense to use the amount of lost / received bursts
during the calculation of the measurement reports, instead of
sending dummy bursts, but let's do this separately.
Change-Id: I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: OS#3428
It's very confusing if some log messages log chan_nr as decimal, while
most log it as hexadecimal. Let's standardize on hex everywhere.
Change-Id: Ia6566d5bbee8124fb7c689c962ce34d714208503
This patch adds scheduler support for the channel combinations that
substitute SDCCH index 2 for a CBCH in either a SDCCH/8 or SDCCH/4.
Change-Id: Icc15603079a1709ec094f400a9bcf0008211890f
Closes: OS#1617
Each logical channel (e.g. SACCH, SDCCH, etc.) has a counter of
lost L2 frames. Let's use a bit better name for it, and correct
its description in the 'l1sched_chan_state' struct definition.
Change-Id: I92ef95f6b3f647170cfd434a970701406b0a7c82
Vadim Yanitskiy
Neels Hofmeyr
Pau Espin
Philipp Maier
Harald Welte
Martin Hauke