Change in osmo-bts[master]: osmo-bts-trx/scheduler: implement baseband frequency hopping

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

fixeria gerrit-no-reply at lists.osmocom.org
Sun Aug 2 14:28:12 UTC 2020


Hello Jenkins Builder, 

I'd like you to reexamine a change. Please visit

    https://gerrit.osmocom.org/c/osmo-bts/+/19030

to look at the new patch set (#5).

Change subject: osmo-bts-trx/scheduler: implement baseband frequency hopping
......................................................................

osmo-bts-trx/scheduler: implement baseband frequency hopping

The idea behind the baseband frequency hopping is quite simple: we
have several RF carriers (transceivers) transmitting and receiving
on fixed frequencies (just like in a regular multi-trx setup), and
an additional burst routing layer between the schedulear and the
transceiver interface (TRXD over UDP).

Speaking in terms of the proposed implementation:

  - on Downlink, dlfh_route_br() calculates the ARFCN corresponding
    to the current TDMA frame number according to the hopping sequence
    parametets, and picks the transceiver with matching ARFCN;

  - on Uplink, ulfh_route_bi() iterates over the transceiver list of
    of the BTS, calculating hopping ARFCNs for equivalent timeslots,
    and picks the one with ARFCN matching the received burst.

In order to avoid frequent transceiver lookups on the Downlink path,
dlfh_route_br() maintains a "cache" in the timeslot state structure.
Unfortunately, this "cache" seems to be useless on the Uplink path,
so ulfh_route_bi() always needs to lookup the matching transceiver
for each burst received over the TRXD interface.

It may also happen that the scheduler will be unable to route an
Uplink or Downlink burst, e.g. due to inconsistent / incorrect
hopping sequence parameters received from the BSC, or in case
if a transceiver gets RF-locked by the BTS operator.

Such events are logged as "FATAL" and aditionally signalled by the
following osmo-bts-trx specific rate counters:

  - trx_sched:dl_fh_no_carrier (Downlink), and
  - trx_sched:ul_fh_no_carrier (Uplink).

Change-Id: I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Related: SYS#4868, OS#4546
---
M include/osmo-bts/gsm_data.h
M include/osmo-bts/scheduler.h
M src/osmo-bts-trx/l1_if.h
M src/osmo-bts-trx/main.c
M src/osmo-bts-trx/scheduler_trx.c
M src/osmo-bts-trx/trx_if.c
6 files changed, 117 insertions(+), 4 deletions(-)


  git pull ssh://gerrit.osmocom.org:29418/osmo-bts refs/changes/30/19030/5
-- 
To view, visit https://gerrit.osmocom.org/c/osmo-bts/+/19030
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: I68f4ae09fd0789ad0d8f1c1e17e17dfc4de8e462
Gerrit-Change-Number: 19030
Gerrit-PatchSet: 5
Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy at sysmocom.de>
Gerrit-CC: laforge <laforge at osmocom.org>
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-MessageType: newpatchset
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200802/346bfa79/attachment.htm>


More information about the gerrit-log mailing list