Change in osmo-bts[master]: common/scheduler.c: track TDMA frame loss per logical channels

[Vadim Yanitskiy]

Vadim Yanitskiy has uploaded a new patch set (#2). ( https://gerrit.osmocom.org/10309 )

Change subject: common/scheduler.c: track TDMA frame loss per logical channels
......................................................................

common/scheduler.c: track TDMA frame loss per logical channels

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
---
M include/osmo-bts/scheduler.h
M src/common/scheduler.c
2 files changed, 133 insertions(+), 65 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/09/10309/2
-- 
To view, visit https://gerrit.osmocom.org/10309
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Gerrit-Change-Number: 10309
Gerrit-PatchSet: 2
Gerrit-Owner: Vadim Yanitskiy <axilirator at gmail.com>
Gerrit-CC: Jenkins Builder
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20180802/b3eae4ca/attachment.htm>