osmo-bts/src/osmo-bts-trx/scheduler_trx.c

697 lines
22 KiB
C
Raw Normal View History

/* Scheduler worker functions for OsmoBTS-TRX */
/* (C) 2013 by Andreas Eversberg <jolly@eversberg.eu>
* (C) 2015 by Alexander Chemeris <Alexander.Chemeris@fairwaves.co>
* (C) 2015-2017 by Harald Welte <laforge@gnumonks.org>
* (C) 2020-2021 by sysmocom - s.m.f.c. GmbH <info@sysmocom.de>
*
* All Rights Reserved
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU Affero General Public License as published by
* the Free Software Foundation; either version 3 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU Affero General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*
*/
#include <stdlib.h>
#include <unistd.h>
osmo-bts-trx: distinguish 11-bit Access Bursts by synch. sequence Thanks to both TC_rach_content and TC_rach_count TTCN-3 test cases, it was discovered that there are possible collisions when trying to decode a regular 8-bit Access Burst as an 11-bit one. This is exactly what we are doing in rx_rach_fn(): - calling gsm0503_rach_ext_decode_ber() first, - if it failed, falling-back to gsm0503_rach_decode_ber(). With default BSIC=63, the following 8-bit RA values are being misinterpreted as 11-bit Access Bursts: Successfully decoded 8-bit (0x00) RACH as 11-bit (0x0000): bsic=0x3f Successfully decoded 8-bit (0xbe) RACH as 11-bit (0x0388): bsic=0x3f Successfully decoded 8-bit (0xcf) RACH as 11-bit (0x0036): bsic=0x3f According to 3GPP TS 05.02, section 5.2.7, there are two alternative synch. (training) sequences for Access Bursts: TS1 & TS2. By default, TS0 synch. sequence is used, unless explicitly stated otherwise (see 3GPP TS 04.60). According to 3GPP TS 04.60, section 11.2.5a, the EGPRS capability can be indicated by the MS using one of the alternative training sequences (i.e. TS1 or TS2) and the 11-bit RACH coding scheme. In other words, knowing the synch. sequence of a received Access Burst would allow to decide whether it's extended (11-bit) or a regular (8-bit) one. As a result, we would avoid possible collisions and save some CPU power. Unfortunately, due to the limitations of the current TRXD protocol, there is no easy way to expose such information from the transceiver. A proper solution would be to extend the TRX protocol, but for now, let's do the synch. sequence detection in rx_rach_fn(). As soon as the TRX protocol is extended with info about the synch. sequence, this code would serve for the backwards-compatibility. This change makes the both TC_rach_content and TC_rach_count happy, as well as the new TC_pcu_ext_rach_content() test case aimed to verify extended (11-bit) Access Burst decoding. Related (TTCN-3) I8fe156aeac9de3dc1e71a4950821d4942ba9a253 Change-Id: Ibb6d27c6589965c8b59a6d2598a7c43fd860f284 Related: OS#1854
2019-04-20 22:50:35 +00:00
#include <limits.h>
#include <errno.h>
#include <stdint.h>
#include <ctype.h>
#include <inttypes.h>
#include <sys/timerfd.h>
#include <osmocom/core/msgb.h>
#include <osmocom/core/talloc.h>
#include <osmocom/core/timer_compat.h>
#include <osmocom/core/bits.h>
#include <osmocom/gsm/a5.h>
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
2020-06-15 10:22:39 +00:00
#include <osmocom/gsm/gsm0502.h>
#include <osmo-bts/gsm_data.h>
#include <osmo-bts/logging.h>
#include <osmo-bts/rsl.h>
#include <osmo-bts/bts.h>
#include <osmo-bts/l1sap.h>
#include <osmo-bts/scheduler.h>
#include <osmo-bts/scheduler_backend.h>
#include <osmo-bts/pcu_if.h>
#include "l1_if.h"
#include "trx_if.h"
#include "btsconfig.h"
#ifdef HAVE_SYSTEMTAP
/* include the generated probes header and put markers in code */
#include "probes.h"
#define TRACE(probe) probe
#define TRACE_ENABLED(probe) probe ## _ENABLED()
#else
/* Wrap the probe to allow it to be removed when no systemtap available */
#define TRACE(probe)
#define TRACE_ENABLED(probe) (0)
#endif /* HAVE_SYSTEMTAP */
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
2020-06-15 10:22:39 +00:00
#define SCHED_FH_PARAMS_FMT "hsn=%u, maio=%u, ma_len=%u"
#define SCHED_FH_PARAMS_VALS(ts) \
(ts)->hopping.hsn, (ts)->hopping.maio, (ts)->hopping.arfcn_num
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
2020-06-15 10:22:39 +00:00
static void lchan_report_interf_meas(const struct gsm_lchan *lchan)
{
const struct gsm_bts_trx_ts *ts = lchan->ts;
const struct l1sched_ts *l1ts = ts->priv;
enum trx_chan_type dcch, acch;
int interf_avg;
/* We're not interested in active CS channels */
if (lchan->state == LCHAN_S_ACTIVE) {
if (lchan->type != GSM_LCHAN_PDTCH)
return;
}
switch (lchan->type) {
case GSM_LCHAN_SDCCH:
if (ts->pchan == GSM_PCHAN_CCCH_SDCCH4 ||
ts->pchan == GSM_PCHAN_CCCH_SDCCH4_CBCH) {
dcch = TRXC_SDCCH4_0 + lchan->nr;
acch = TRXC_SACCH4_0 + lchan->nr;
} else { /* SDCCH/8 otherwise */
dcch = TRXC_SDCCH8_0 + lchan->nr;
acch = TRXC_SACCH8_0 + lchan->nr;
}
break;
case GSM_LCHAN_TCH_F:
dcch = TRXC_TCHF;
acch = TRXC_SACCHTF;
break;
case GSM_LCHAN_TCH_H:
dcch = TRXC_TCHH_0 + lchan->nr;
acch = TRXC_SACCHTH_0 + lchan->nr;
break;
case GSM_LCHAN_PDTCH:
/* We use idle TDMA frames on PDCH */
dcch = TRXC_IDLE;
acch = TRXC_IDLE;
break;
default:
/* Skip other lchan types */
return;
}
OSMO_ASSERT(dcch < ARRAY_SIZE(l1ts->chan_state));
OSMO_ASSERT(acch < ARRAY_SIZE(l1ts->chan_state));
interf_avg = (l1ts->chan_state[dcch].meas.interf_avg +
l1ts->chan_state[acch].meas.interf_avg) / 2;
gsm_lchan_interf_meas_push((struct gsm_lchan *) lchan, interf_avg);
}
static void bts_report_interf_meas(const struct gsm_bts *bts,
const uint32_t fn)
{
const struct gsm_bts_trx *trx;
unsigned int tn, ln;
llist_for_each_entry(trx, &bts->trx_list, list) {
for (tn = 0; tn < ARRAY_SIZE(trx->ts); tn++) {
const struct gsm_bts_trx_ts *ts = &trx->ts[tn];
for (ln = 0; ln < ARRAY_SIZE(ts->lchan); ln++)
lchan_report_interf_meas(&ts->lchan[ln]);
}
}
}
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
2020-06-15 10:22:39 +00:00
/* Find a route (PHY instance) for a given Downlink burst request */
static struct phy_instance *dlfh_route_br(const struct trx_dl_burst_req *br,
struct gsm_bts_trx_ts *ts)
{
const struct gsm_bts_trx *trx;
struct gsm_time time;
uint16_t idx;
gsm_fn2gsmtime(&time, br->fn);
/* Check the "cache" first, so we eliminate frequent lookups */
idx = gsm0502_hop_seq_gen(&time, SCHED_FH_PARAMS_VALS(ts), NULL);
if (ts->fh_trx_list[idx] != NULL)
return ts->fh_trx_list[idx]->pinst;
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
2020-06-15 10:22:39 +00:00
/* The "cache" may not be filled yet, lookup the transceiver */
llist_for_each_entry(trx, &ts->trx->bts->trx_list, list) {
if (trx->arfcn == ts->hopping.arfcn_list[idx]) {
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
2020-06-15 10:22:39 +00:00
ts->fh_trx_list[idx] = trx;
return trx->pinst;
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
2020-06-15 10:22:39 +00:00
}
}
LOGPTRX(ts->trx, DL1C, LOGL_FATAL, "Failed to find the transceiver (RF carrier) "
"for a Downlink burst (fn=%u, tn=%u, " SCHED_FH_PARAMS_FMT ")\n",
br->fn, br->tn, SCHED_FH_PARAMS_VALS(ts));
struct bts_trx_priv *priv = (struct bts_trx_priv *) ts->trx->bts->model_priv;
rate_ctr_inc(rate_ctr_group_get_ctr(priv->ctrs, BTSTRX_CTR_SCHED_DL_FH_NO_CARRIER));
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
2020-06-15 10:22:39 +00:00
return NULL;
}
static void bts_sched_init_buffers(struct gsm_bts *bts, const uint32_t fn)
{
struct gsm_bts_trx *trx;
uint8_t tn;
llist_for_each_entry(trx, &bts->trx_list, list) {
struct phy_instance *pinst = trx->pinst;
const struct phy_link *plink = pinst->phy_link;
/* Advance frame number, so the PHY has more time to process bursts */
const uint32_t sched_fn = GSM_TDMA_FN_SUM(fn, plink->u.osmotrx.clock_advance);
for (tn = 0; tn < ARRAY_SIZE(trx->ts); tn++) {
struct trx_dl_burst_req *br = &pinst->u.osmotrx.br[tn];
*br = (struct trx_dl_burst_req) {
.trx_num = trx->nr,
.fn = sched_fn,
.tn = tn,
};
}
}
/* Initialize all timeslots on C0/TRX0 with dummy burst */
for (tn = 0; tn < ARRAY_SIZE(trx->ts); tn++) {
struct phy_instance *pinst = bts->c0->pinst;
struct trx_dl_burst_req *br = &pinst->u.osmotrx.br[tn];
osmo-bts-trx: implement BCCH carrier power reduction mode 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
2021-06-25 17:16:06 +00:00
const struct gsm_bts_trx_ts *ts = &bts->c0->ts[tn];
memcpy(br->burst, _sched_dummy_burst, GSM_BURST_LEN);
br->burst_len = GSM_BURST_LEN;
osmo-bts-trx: implement BCCH carrier power reduction mode 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
2021-06-25 17:16:06 +00:00
/* BCCH carrier power reduction for this timeslot */
br->att = ts->c0_power_red_db;
}
}
static void bts_sched_flush_buffers(struct gsm_bts *bts)
{
const struct gsm_bts_trx *trx;
unsigned int tn;
llist_for_each_entry(trx, &bts->trx_list, list) {
const struct phy_instance *pinst = trx->pinst;
struct trx_l1h *l1h = pinst->u.osmotrx.hdl;
for (tn = 0; tn < TRX_NR_TS; tn++) {
const struct trx_dl_burst_req *br;
br = &pinst->u.osmotrx.br[tn];
if (!br->burst_len)
continue;
trx_if_send_burst(l1h, br);
}
/* Batch all timeslots into a single TRXD PDU */
trx_if_send_burst(l1h, NULL);
}
}
/* schedule one frame for a shadow timeslot, merge bursts */
static void _sched_dl_shadow_burst(const struct gsm_bts_trx_ts *ts,
struct trx_dl_burst_req *br)
{
struct l1sched_ts *l1ts = ts->priv;
/* For the shadow timeslots, physical channel type can be either
* GSM_PCHAN_TCH_{F,H} or GSM_PCHAN_NONE. Even if the primary
* timeslot is a dynamic timeslot, it's always a concrete value. */
if (ts->pchan == GSM_PCHAN_NONE)
return;
struct trx_dl_burst_req sbr = {
.trx_num = br->trx_num,
.fn = br->fn,
.tn = br->tn,
};
_sched_dl_burst(l1ts, &sbr);
if (br->burst_len != 0 && sbr.burst_len != 0) { /* Both present */
memcpy(br->burst + GSM_BURST_LEN, sbr.burst, GSM_BURST_LEN);
br->burst_len = 2 * GSM_BURST_LEN;
br->mod = TRX_MOD_T_AQPSK;
/* FIXME: SCPIR is hard-coded to 0 */
} else if (br->burst_len == 0) {
/* No primary burst, send shadow burst alone */
memcpy(br, &sbr, sizeof(sbr));
} else if (sbr.burst_len == 0) {
/* No shadow burst, send primary burst alone */
return;
}
}
/* schedule all frames of all TRX for given FN */
static void bts_sched_fn(struct gsm_bts *bts, const uint32_t fn)
{
struct gsm_bts_trx *trx;
unsigned int tn;
/* Report interference measurements */
if (fn % 104 == 0) /* SACCH period */
bts_report_interf_meas(bts, fn);
/* send time indication */
l1if_mph_time_ind(bts, fn);
/* Initialize Downlink burst buffers */
bts_sched_init_buffers(bts, fn);
/* Populate Downlink burst buffers for each TRX/TS */
llist_for_each_entry(trx, &bts->trx_list, list) {
const struct phy_link *plink = trx->pinst->phy_link;
struct trx_l1h *l1h = trx->pinst->u.osmotrx.hdl;
/* we don't schedule, if power is off */
if (!trx_if_powered(l1h))
continue;
/* process every TS of TRX */
[VAMOS] Re-organize osmo-bts-trx specific structures 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
2021-05-07 13:47:57 +00:00
for (tn = 0; tn < ARRAY_SIZE(trx->ts); tn++) {
struct phy_instance *pinst = trx->pinst;
struct gsm_bts_trx_ts *ts = &trx->ts[tn];
struct l1sched_ts *l1ts = ts->priv;
struct trx_dl_burst_req *br;
/* ready-to-send */
TRACE(OSMO_BTS_TRX_DL_RTS_START(trx->nr, tn, fn));
_sched_rts(l1ts, GSM_TDMA_FN_SUM(fn, plink->u.osmotrx.clock_advance
+ plink->u.osmotrx.rts_advance));
TRACE(OSMO_BTS_TRX_DL_RTS_DONE(trx->nr, tn, fn));
/* pre-initialized buffer for the Downlink burst */
br = &pinst->u.osmotrx.br[tn];
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
2020-06-15 10:22:39 +00:00
/* resolve PHY instance if freq. hopping is enabled */
if (ts->hopping.enabled) {
pinst = dlfh_route_br(br, ts);
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
2020-06-15 10:22:39 +00:00
if (pinst == NULL)
continue;
/* simply use a different buffer */
br = &pinst->u.osmotrx.br[tn];
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
2020-06-15 10:22:39 +00:00
}
/* get burst for the primary timeslot */
_sched_dl_burst(l1ts, br);
/* get burst for the shadow timeslot */
_sched_dl_shadow_burst(ts->vamos.peer, br);
}
}
/* Send everything to the PHY */
bts_sched_flush_buffers(bts);
}
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
2020-06-15 10:22:39 +00:00
/* Find a route (TRX instance) for a given Uplink burst indication */
static struct gsm_bts_trx *ulfh_route_bi(const struct trx_ul_burst_ind *bi,
const struct gsm_bts_trx *src_trx)
{
struct gsm_bts_trx *trx;
struct gsm_time time;
uint16_t arfcn;
gsm_fn2gsmtime(&time, bi->fn);
llist_for_each_entry(trx, &src_trx->bts->trx_list, list) {
const struct gsm_bts_trx_ts *ts = &trx->ts[bi->tn];
if (!ts->hopping.enabled)
continue;
arfcn = gsm0502_hop_seq_gen(&time, SCHED_FH_PARAMS_VALS(ts), ts->hopping.arfcn_list);
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
2020-06-15 10:22:39 +00:00
if (src_trx->arfcn == arfcn)
return trx;
}
LOGPTRX(src_trx, DL1C, LOGL_DEBUG, "Failed to find the transceiver (RF carrier) "
"for an Uplink burst (fn=%u, tn=%u, " SCHED_FH_PARAMS_FMT ")\n",
bi->fn, bi->tn, SCHED_FH_PARAMS_VALS(&src_trx->ts[bi->tn]));
struct bts_trx_priv *priv = (struct bts_trx_priv *) src_trx->bts->model_priv;
rate_ctr_inc(rate_ctr_group_get_ctr(priv->ctrs, BTSTRX_CTR_SCHED_UL_FH_NO_CARRIER));
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
2020-06-15 10:22:39 +00:00
return NULL;
}
/* Route a given Uplink burst indication to the scheduler depending on freq. hopping state */
[VAMOS] Re-organize osmo-bts-trx specific structures 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
2021-05-07 13:47:57 +00:00
int trx_sched_route_burst_ind(const struct gsm_bts_trx *trx, struct trx_ul_burst_ind *bi)
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
2020-06-15 10:22:39 +00:00
{
/* no frequency hopping => nothing to do */
[VAMOS] Re-organize osmo-bts-trx specific structures 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
2021-05-07 13:47:57 +00:00
if (!trx->ts[bi->tn].hopping.enabled)
return trx_sched_ul_burst(trx->ts[bi->tn].priv, bi);
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
2020-06-15 10:22:39 +00:00
[VAMOS] Re-organize osmo-bts-trx specific structures 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
2021-05-07 13:47:57 +00:00
trx = ulfh_route_bi(bi, trx);
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
2020-06-15 10:22:39 +00:00
if (trx == NULL)
return -ENODEV;
[VAMOS] Re-organize osmo-bts-trx specific structures 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
2021-05-07 13:47:57 +00:00
return trx_sched_ul_burst(trx->ts[bi->tn].priv, bi);
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
2020-06-15 10:22:39 +00:00
}
/*! maximum number of 'missed' frame periods we can tolerate of OS doesn't schedule us*/
#define MAX_FN_SKEW 50
/*! maximum number of frame periods we can tolerate without TRX Clock Indication*/
#define TRX_LOSS_FRAMES 400
/*! compute the number of micro-seconds difference elapsed between \a last and \a now */
static inline int64_t compute_elapsed_us(const struct timespec *last, const struct timespec *now)
{
struct timespec elapsed;
timespecsub(now, last, &elapsed);
return (int64_t)(elapsed.tv_sec * 1000000) + (elapsed.tv_nsec / 1000);
}
/*! compute the number of frame number intervals elapsed between \a last and \a now */
static inline int compute_elapsed_fn(const uint32_t last, const uint32_t now)
{
int elapsed_fn = GSM_TDMA_FN_SUB(now, last);
if (elapsed_fn >= 135774)
elapsed_fn -= GSM_TDMA_HYPERFRAME;
return elapsed_fn;
}
/*! normalise given 'struct timespec', i.e. carry nanoseconds into seconds */
static inline void normalize_timespec(struct timespec *ts)
{
ts->tv_sec += ts->tv_nsec / 1000000000;
ts->tv_nsec = ts->tv_nsec % 1000000000;
}
/*! this is the timerfd-callback firing for every FN to be processed */
static int trx_fn_timer_cb(struct osmo_fd *ofd, unsigned int what)
{
struct gsm_bts *bts = ofd->data;
struct bts_trx_priv *bts_trx = (struct bts_trx_priv *)bts->model_priv;
struct osmo_trx_clock_state *tcs = &bts_trx->clk_s;
struct timespec tv_now;
uint64_t expire_count;
int64_t elapsed_us, error_us;
int rc, i;
if (!(what & OSMO_FD_READ))
return 0;
/* read from timerfd: number of expirations of periodic timer */
rc = read(ofd->fd, (void *) &expire_count, sizeof(expire_count));
if (rc < 0 && errno == EAGAIN)
return 0;
OSMO_ASSERT(rc == sizeof(expire_count));
if (expire_count > 1) {
LOGP(DL1C, LOGL_NOTICE, "FN timer expire_count=%"PRIu64": We missed %"PRIu64" timers\n",
expire_count, expire_count - 1);
rate_ctr_add(rate_ctr_group_get_ctr(bts_trx->ctrs, BTSTRX_CTR_SCHED_DL_MISS_FN), expire_count - 1);
}
/* check if transceiver is still alive */
if (tcs->fn_without_clock_ind++ == TRX_LOSS_FRAMES) {
LOGP(DL1C, LOGL_NOTICE, "No more clock from transceiver\n");
goto no_clock;
}
/* compute actual elapsed time and resulting OS scheduling error */
clock_gettime(CLOCK_MONOTONIC, &tv_now);
elapsed_us = compute_elapsed_us(&tcs->last_fn_timer.tv, &tv_now);
error_us = elapsed_us - GSM_TDMA_FN_DURATION_uS;
#ifdef DEBUG_CLOCK
printf("%s(): %09ld, elapsed_us=%05" PRId64 ", error_us=%-d: fn=%d\n", __func__,
tv_now.tv_nsec, elapsed_us, error_us, tcs->last_fn_timer.fn+1);
#endif
tcs->last_fn_timer.tv = tv_now;
/* if someone played with clock, or if the process stalled */
if (elapsed_us > GSM_TDMA_FN_DURATION_uS * MAX_FN_SKEW || elapsed_us < 0) {
LOGP(DL1C, LOGL_ERROR, "PC clock skew: elapsed_us=%" PRId64 ", error_us=%" PRId64 "\n",
elapsed_us, error_us);
goto no_clock;
}
/* call bts_sched_fn() for all expired FN */
for (i = 0; i < expire_count; i++)
bts_sched_fn(bts, GSM_TDMA_FN_INC(tcs->last_fn_timer.fn));
return 0;
no_clock:
osmo_timerfd_disable(&tcs->fn_timer_ofd);
bts_shutdown(bts, "No clock from osmo-trx");
return -1;
}
/*! \brief This is the cb of the initial timer set upon start. On timeout, it
* means it wasn't replaced and hence no CLOCK IND was received. */
static int trx_start_noclockind_to_cb(struct osmo_fd *ofd, unsigned int what)
{
struct gsm_bts *bts = ofd->data;
struct bts_trx_priv *bts_trx = (struct bts_trx_priv *)bts->model_priv;
struct osmo_trx_clock_state *tcs = &bts_trx->clk_s;
osmo_fd_close(&tcs->fn_timer_ofd); /* Avoid being called again */
bts_shutdown(bts, "No clock since TRX was started");
return -1;
}
/*! \brief PHY informs us clock indications should start to be received */
int trx_sched_clock_started(struct gsm_bts *bts)
{
struct bts_trx_priv *bts_trx = (struct bts_trx_priv *)bts->model_priv;
struct osmo_trx_clock_state *tcs = &bts_trx->clk_s;
const struct timespec it_val = {3, 0};
const struct timespec it_intval = {0, 0};
LOGP(DL1C, LOGL_NOTICE, "GSM clock started, waiting for clock indications\n");
osmo_fd_close(&tcs->fn_timer_ofd);
memset(tcs, 0, sizeof(*tcs));
tcs->fn_timer_ofd.fd = -1;
/* Set up timeout to shutdown BTS if no clock ind is received in a few
* seconds. Upon clock ind receival, fn_timer_ofd will be reused and
* timeout won't trigger.
*/
osmo_timerfd_setup(&tcs->fn_timer_ofd, trx_start_noclockind_to_cb, bts);
osmo_timerfd_schedule(&tcs->fn_timer_ofd, &it_val, &it_intval);
return 0;
}
/*! \brief PHY informs us no more clock indications should be received anymore */
int trx_sched_clock_stopped(struct gsm_bts *bts)
{
struct bts_trx_priv *bts_trx = (struct bts_trx_priv *)bts->model_priv;
struct osmo_trx_clock_state *tcs = &bts_trx->clk_s;
LOGP(DL1C, LOGL_NOTICE, "GSM clock stopped\n");
osmo_fd_close(&tcs->fn_timer_ofd);
return 0;
}
/*! reset clock with current fn and schedule it. Called when trx becomes
* available or when max clock skew is reached */
static int trx_setup_clock(struct gsm_bts *bts, struct osmo_trx_clock_state *tcs,
struct timespec *tv_now, const struct timespec *interval, uint32_t fn)
{
/* schedule first FN clock timer */
osmo_timerfd_setup(&tcs->fn_timer_ofd, trx_fn_timer_cb, bts);
osmo_timerfd_schedule(&tcs->fn_timer_ofd, NULL, interval);
tcs->last_fn_timer.fn = fn;
tcs->last_fn_timer.tv = *tv_now;
/* call trx scheduler function for new 'last' FN */
bts_sched_fn(bts, tcs->last_fn_timer.fn);
return 0;
}
/*! called every time we receive a clock indication from TRX */
int trx_sched_clock(struct gsm_bts *bts, uint32_t fn)
{
struct bts_trx_priv *bts_trx = (struct bts_trx_priv *)bts->model_priv;
struct osmo_trx_clock_state *tcs = &bts_trx->clk_s;
struct timespec tv_now;
int elapsed_fn;
int64_t elapsed_us, elapsed_us_since_clk, elapsed_fn_since_clk, error_us_since_clk;
unsigned int fn_caught_up = 0;
const struct timespec interval = { .tv_sec = 0, .tv_nsec = GSM_TDMA_FN_DURATION_nS };
/* reset lost counter */
tcs->fn_without_clock_ind = 0;
clock_gettime(CLOCK_MONOTONIC, &tv_now);
/* calculate elapsed time +fn since last timer */
elapsed_us = compute_elapsed_us(&tcs->last_fn_timer.tv, &tv_now);
elapsed_fn = compute_elapsed_fn(tcs->last_fn_timer.fn, fn);
#ifdef DEBUG_CLOCK
printf("%s(): LAST_TIMER %9ld, elapsed_us=%7d, elapsed_fn=%+3d\n", __func__,
tv_now.tv_nsec, elapsed_us, elapsed_fn);
#endif
/* negative elapsed_fn values mean that we've already processed
* more FN based on the local interval timer than what the TRX
* now reports in the clock indication. Positive elapsed_fn
* values mean we still have a backlog to process */
/* calculate elapsed time +fn since last clk ind */
elapsed_us_since_clk = compute_elapsed_us(&tcs->last_clk_ind.tv, &tv_now);
elapsed_fn_since_clk = compute_elapsed_fn(tcs->last_clk_ind.fn, fn);
/* error (delta) between local clock since last CLK and CLK based on FN clock at TRX */
error_us_since_clk = elapsed_us_since_clk - (GSM_TDMA_FN_DURATION_uS * elapsed_fn_since_clk);
LOGP(DL1C, LOGL_INFO, "TRX Clock Ind: elapsed_us=%7"PRId64", "
"elapsed_fn=%3"PRId64", error_us=%+5"PRId64"\n",
elapsed_us_since_clk, elapsed_fn_since_clk, error_us_since_clk);
/* TODO: put this computed error_us_since_clk into some filter
* function and use that to adjust our regular timer interval to
* compensate for clock drift between the PC clock and the
* TRX/SDR clock */
tcs->last_clk_ind.tv = tv_now;
tcs->last_clk_ind.fn = fn;
/* check for max clock skew */
if (elapsed_fn > MAX_FN_SKEW || elapsed_fn < -MAX_FN_SKEW) {
LOGP(DL1C, LOGL_NOTICE, "GSM clock skew: old fn=%u, "
"new fn=%u\n", tcs->last_fn_timer.fn, fn);
return trx_setup_clock(bts, tcs, &tv_now, &interval, fn);
}
LOGP(DL1C, LOGL_INFO, "GSM clock jitter: %" PRId64 "us (elapsed_fn=%d)\n",
elapsed_fn * GSM_TDMA_FN_DURATION_uS - elapsed_us, elapsed_fn);
/* too many frames have been processed already */
if (elapsed_fn < 0) {
struct timespec first = interval;
/* set clock to the time or last FN should have been
* transmitted. */
first.tv_nsec += (0 - elapsed_fn) * GSM_TDMA_FN_DURATION_nS;
normalize_timespec(&first);
LOGP(DL1C, LOGL_NOTICE, "We were %d FN faster than TRX, compensating\n", -elapsed_fn);
/* set time to the time our next FN has to be transmitted */
osmo_timerfd_schedule(&tcs->fn_timer_ofd, &first, &interval);
return 0;
}
/* transmit what we still need to transmit */
while (fn != tcs->last_fn_timer.fn) {
bts_sched_fn(bts, GSM_TDMA_FN_INC(tcs->last_fn_timer.fn));
fn_caught_up++;
}
if (fn_caught_up) {
LOGP(DL1C, LOGL_NOTICE, "We were %d FN slower than TRX, compensated\n", elapsed_fn);
tcs->last_fn_timer.tv = tv_now;
}
return 0;
}
[VAMOS] Re-organize osmo-bts-trx specific structures 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
2021-05-07 13:47:57 +00:00
void _sched_act_rach_det(struct gsm_bts_trx *trx, uint8_t tn, uint8_t ss, int activate)
{
[VAMOS] Re-organize osmo-bts-trx specific structures 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
2021-05-07 13:47:57 +00:00
struct phy_instance *pinst = trx_phy_instance(trx);
struct trx_l1h *l1h = pinst->u.osmotrx.hdl;
if (activate)
trx_if_cmd_handover(l1h, tn, ss);
else
trx_if_cmd_nohandover(l1h, tn, ss);
}
/* Add a set of UL burst measurements to the history */
void trx_sched_meas_push(struct l1sched_chan_state *chan_state,
const struct trx_ul_burst_ind *bi)
{
unsigned int hist_size = ARRAY_SIZE(chan_state->meas.buf);
unsigned int current = chan_state->meas.current;
chan_state->meas.buf[current] = (struct l1sched_meas_set) {
.ci_cb = (bi->flags & TRX_BI_F_CI_CB) ? bi->ci_cb : 0,
.toa256 = bi->toa256,
.rssi = bi->rssi,
};
chan_state->meas.current = (current + 1) % hist_size;
}
/* Calculate the AVG of n measurements from the history */
void trx_sched_meas_avg(const struct l1sched_chan_state *chan_state,
struct l1sched_meas_set *avg,
enum sched_meas_avg_mode mode)
{
unsigned int hist_size = ARRAY_SIZE(chan_state->meas.buf);
unsigned int current = chan_state->meas.current;
const struct l1sched_meas_set *set;
unsigned int shift, pos, i, n;
float rssi_sum = 0;
int toa256_sum = 0;
int ci_cb_sum = 0;
switch (mode) {
/* last 4 bursts (default for xCCH, TCH/H, PTCCH and PDTCH) */
case SCHED_MEAS_AVG_M_QUAD:
n = 4; shift = n;
break;
/* last 8 bursts (default for TCH/F and FACCH/F) */
case SCHED_MEAS_AVG_M_OCTO:
n = 8; shift = n;
break;
/* last 6 bursts (default for FACCH/H) */
case SCHED_MEAS_AVG_M_SIX:
n = 6; shift = n;
break;
/* first 4 of last 8 bursts */
case SCHED_MEAS_AVG_M8_FIRST_QUAD:
n = 4; shift = 8;
break;
/* first 2 of last 6 bursts */
case SCHED_MEAS_AVG_M6_FIRST_TWO:
n = 2; shift = 6;
break;
/* middle 2 of last 6 bursts */
case SCHED_MEAS_AVG_M6_MIDDLE_TWO:
n = 2; shift = 4;
break;
default:
/* Shall not happen */
OSMO_ASSERT(false);
}
/* Calculate the sum of n entries starting from pos */
for (i = 0; i < n; i++) {
pos = (current + hist_size - shift + i) % hist_size;
set = &chan_state->meas.buf[pos];
rssi_sum += set->rssi;
toa256_sum += set->toa256;
ci_cb_sum += set->ci_cb;
}
/* Calculate the average for each value */
*avg = (struct l1sched_meas_set) {
.rssi = (rssi_sum / n),
.toa256 = (toa256_sum / n),
.ci_cb = (ci_cb_sum / n),
};
LOGP(DMEAS, LOGL_DEBUG, "Measurement AVG (num=%u, shift=%u): "
"RSSI %f, ToA256 %d, C/I %d cB\n", n, shift,
avg->rssi, avg->toa256, avg->ci_cb);
}