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
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
There's no need to express TOA as a float:
* We receive it as signed 16bit integer in units 1/256 symbol periods
* We pass it to L1SAP as signed integer in 1/4 symbol periods
So turn it into an int16_t with 1/256 symbol period accuracy throughout
the code to avoid both float arithmetic as well as loosing any precision.
Change-Id: Idce4178e0b1f7e940ebc22b3e2f340fcd544d4ec
There are use cases for the multiframe scheduler tables outside the
context of the entire scheduler. Let's prepare for that.
Related: OS#2978
Change-Id: I6a501e66c47809ae3cdc55bef2cb6390ee0096b1
For proper measurement processing of RX{LEV,QUAL}-SUB, we will
need this information.
Related: OS#2978
Change-Id: I768fde62452a74dce471ebf946e56eb1e4de1abc
Existing interfaces are coded with the implicit expectation of using
a burst sequence length of 148, which is constant with GSM and GPRS.
That changes with EGPRS, where the burst length may be 444 due to
the use of 8-PSK instead of GMSK modulation.
Setup the interface to accept and return a length value with the
burst sequence. This allows 444 length bit vectors to/from the
EGPRS decoder/encoder. Length is explicitly used as a identifier for
8-PSK vs. GMSK modulated sequences.
Change-Id: I90b46b46b11b6ce280e7f8232d5a2fccec2d4f18
Signed-off-by: Tom Tsou <tom.tsou@ettus.com>
Vadim Yanitskiy
Harald Welte