2020-06-05 17:56:29 +00:00
|
|
|
/*
|
|
|
|
* (C) 2013 by Andreas Eversberg <jolly@eversberg.eu>
|
|
|
|
* (C) 2015-2017 by Harald Welte <laforge@gnumonks.org>
|
[VAMOS] osmo-bts-trx: move {chan,bid} to trx_{dl,ul}_burst_{req,ind}
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
2021-05-07 14:20:58 +00:00
|
|
|
* Contributions by sysmocom - s.f.m.c. GmbH
|
2020-06-05 17:56:29 +00:00
|
|
|
*
|
|
|
|
* 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 <stdint.h>
|
|
|
|
#include <errno.h>
|
|
|
|
|
|
|
|
#include <osmocom/core/bits.h>
|
|
|
|
#include <osmocom/core/utils.h>
|
|
|
|
#include <osmocom/coding/gsm0503_coding.h>
|
|
|
|
|
|
|
|
#include <osmo-bts/bts.h>
|
|
|
|
#include <osmo-bts/l1sap.h>
|
|
|
|
#include <osmo-bts/logging.h>
|
|
|
|
#include <osmo-bts/scheduler.h>
|
|
|
|
#include <osmo-bts/scheduler_backend.h>
|
|
|
|
|
|
|
|
#include <sched_utils.h>
|
|
|
|
|
|
|
|
/* Maximum size of a EGPRS message in bytes */
|
|
|
|
#define EGPRS_0503_MAX_BYTES 155
|
|
|
|
|
|
|
|
/*! \brief a single PDTCH burst was received by the PHY, process it */
|
[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 rx_pdtch_fn(struct l1sched_ts *l1ts, const struct trx_ul_burst_ind *bi)
|
2020-06-05 17:56:29 +00:00
|
|
|
{
|
[VAMOS] osmo-bts-trx: move {chan,bid} to trx_{dl,ul}_burst_{req,ind}
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
2021-05-07 14:20:58 +00:00
|
|
|
struct l1sched_chan_state *chan_state = &l1ts->chan_state[bi->chan];
|
2023-05-14 15:05:17 +00:00
|
|
|
sbit_t *burst, *bursts_p = chan_state->ul_bursts;
|
2021-03-11 17:37:46 +00:00
|
|
|
uint32_t first_fn;
|
2023-05-15 09:37:49 +00:00
|
|
|
uint32_t *mask = &chan_state->ul_mask;
|
2020-06-22 22:44:48 +00:00
|
|
|
struct l1sched_meas_set meas_avg;
|
2020-06-05 17:56:29 +00:00
|
|
|
uint8_t l2[EGPRS_0503_MAX_BYTES];
|
|
|
|
int n_errors = 0;
|
|
|
|
int n_bursts_bits = 0;
|
|
|
|
int n_bits_total = 0;
|
|
|
|
uint16_t ber10k;
|
|
|
|
int rc;
|
2021-03-05 16:33:24 +00:00
|
|
|
enum osmo_ph_pres_info_type presence_info;
|
2020-06-05 17:56:29 +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
|
|
|
LOGL1SB(DL1P, LOGL_DEBUG, l1ts, bi, "Received PDTCH bid=%u\n", bi->bid);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
2022-10-03 15:26:00 +00:00
|
|
|
/* An MS may be polled to send an ACK in form of four Access Bursts */
|
|
|
|
if (bi->flags & TRX_BI_F_ACCESS_BURST)
|
|
|
|
return rx_rach_fn(l1ts, bi);
|
|
|
|
|
2020-06-05 17:56:29 +00:00
|
|
|
/* clear burst */
|
[VAMOS] osmo-bts-trx: move {chan,bid} to trx_{dl,ul}_burst_{req,ind}
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
2021-05-07 14:20:58 +00:00
|
|
|
if (bi->bid == 0) {
|
2023-05-14 15:05:17 +00:00
|
|
|
memset(bursts_p, 0, GSM0503_EGPRS_BURSTS_NBITS);
|
2020-06-05 17:56:29 +00:00
|
|
|
*mask = 0x0;
|
|
|
|
}
|
|
|
|
|
2020-06-22 22:44:48 +00:00
|
|
|
/* update mask */
|
[VAMOS] osmo-bts-trx: move {chan,bid} to trx_{dl,ul}_burst_{req,ind}
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
2021-05-07 14:20:58 +00:00
|
|
|
*mask |= (1 << bi->bid);
|
2020-06-22 22:44:48 +00:00
|
|
|
|
|
|
|
/* store measurements */
|
|
|
|
trx_sched_meas_push(chan_state, bi);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* copy burst to buffer of 4 bursts */
|
2021-03-05 16:33:24 +00:00
|
|
|
switch (bi->burst_len) {
|
|
|
|
case EGPRS_BURST_LEN:
|
2023-05-14 15:05:17 +00:00
|
|
|
burst = bursts_p + bi->bid * 348;
|
2020-06-05 17:56:29 +00:00
|
|
|
memcpy(burst, bi->burst + 9, 174);
|
|
|
|
memcpy(burst + 174, bi->burst + 261, 174);
|
|
|
|
n_bursts_bits = GSM0503_EGPRS_BURSTS_NBITS;
|
2021-03-05 16:33:24 +00:00
|
|
|
break;
|
|
|
|
case GSM_BURST_LEN:
|
2023-05-14 15:05:17 +00:00
|
|
|
burst = bursts_p + bi->bid * 116;
|
2020-06-05 17:56:29 +00:00
|
|
|
memcpy(burst, bi->burst + 3, 58);
|
|
|
|
memcpy(burst + 58, bi->burst + 87, 58);
|
|
|
|
n_bursts_bits = GSM0503_GPRS_BURSTS_NBITS;
|
2021-03-05 16:33:24 +00:00
|
|
|
break;
|
|
|
|
case 0:
|
|
|
|
/* NOPE.ind, assume GPRS? */
|
|
|
|
n_bursts_bits = GSM0503_GPRS_BURSTS_NBITS;
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* wait until complete set of bursts */
|
[VAMOS] osmo-bts-trx: move {chan,bid} to trx_{dl,ul}_burst_{req,ind}
Historically the logical channel handlers like rx_data_fn() used to accept
quite a lot of arguments. With the introduction of additional measurement
parameters it has become clear that we need to group the arguments into
structures. This is why both 'trx_{dl,ul}_burst_{req,ind}' structures
were introduced.
However, both channel type and burst ID were kept untouched, so until
now we had them being passed between the scheduler functions here and
there. This change is a logical conclusion of the original change
mentioned above.
As a part of this change, the new LOGL1SB() macro is introduced. It
does accept a pointer to 'trx_{dl,ul}_burst_{req,ind}' and expands the
context information for the old LOGL1S() macro.
Change-Id: Ic5a02b074662b3e429bf18e05a982f3f3e7b7444
2021-05-07 14:20:58 +00:00
|
|
|
if (bi->bid != 3)
|
2020-06-05 17:56:29 +00:00
|
|
|
return 0;
|
|
|
|
|
2020-06-22 22:44:48 +00:00
|
|
|
/* average measurements of the last 4 bursts */
|
2022-03-17 15:36:36 +00:00
|
|
|
trx_sched_meas_avg(chan_state, &meas_avg, SCHED_MEAS_AVG_M_S4N4);
|
2020-06-22 22:44:48 +00:00
|
|
|
|
2020-06-05 17:56:29 +00:00
|
|
|
/* check for complete set of bursts */
|
|
|
|
if ((*mask & 0xf) != 0xf) {
|
[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
|
|
|
LOGL1SB(DL1P, LOGL_DEBUG, l1ts, bi, "Received incomplete frame (%u/%u)\n",
|
2020-06-05 17:56:29 +00:00
|
|
|
bi->fn % l1ts->mf_period, l1ts->mf_period);
|
|
|
|
}
|
|
|
|
*mask = 0x0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Attempt to decode EGPRS bursts first. For 8-PSK EGPRS this is all we
|
|
|
|
* do. Attempt GPRS decoding on EGPRS failure. If the burst is GPRS,
|
|
|
|
* then we incur decoding overhead of 31 bits on the Type 3 EGPRS
|
|
|
|
* header, which is tolerable.
|
|
|
|
*/
|
2023-05-14 15:05:17 +00:00
|
|
|
rc = gsm0503_pdtch_egprs_decode(l2, bursts_p, n_bursts_bits,
|
2020-06-05 17:56:29 +00:00
|
|
|
NULL, &n_errors, &n_bits_total);
|
|
|
|
|
|
|
|
if ((bi->burst_len == GSM_BURST_LEN) && (rc < 0)) {
|
2023-05-14 15:05:17 +00:00
|
|
|
rc = gsm0503_pdtch_decode(l2, bursts_p, NULL,
|
2020-06-05 17:56:29 +00:00
|
|
|
&n_errors, &n_bits_total);
|
|
|
|
}
|
|
|
|
|
2021-03-05 16:33:24 +00:00
|
|
|
if (rc > 0) {
|
|
|
|
presence_info = PRES_INFO_BOTH;
|
|
|
|
} else {
|
[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
|
|
|
LOGL1SB(DL1P, LOGL_DEBUG, l1ts, bi, "Received bad PDTCH (%u/%u)\n",
|
2020-06-05 17:56:29 +00:00
|
|
|
bi->fn % l1ts->mf_period, l1ts->mf_period);
|
2021-03-05 16:33:24 +00:00
|
|
|
rc = 0;
|
|
|
|
presence_info = PRES_INFO_INVALID;
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ber10k = compute_ber10k(n_bits_total, n_errors);
|
2021-03-05 16:33:24 +00:00
|
|
|
|
2021-03-11 17:37:46 +00:00
|
|
|
first_fn = GSM_TDMA_FN_SUB(bi->fn, 3);
|
2023-07-05 17:43:21 +00:00
|
|
|
return _sched_compose_ph_data_ind(l1ts, first_fn, bi->chan,
|
|
|
|
&l2[0], rc,
|
|
|
|
ber10k,
|
|
|
|
meas_avg.rssi,
|
|
|
|
meas_avg.toa256,
|
|
|
|
meas_avg.ci_cb,
|
2021-03-05 16:33:24 +00:00
|
|
|
presence_info);
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* obtain a to-be-transmitted PDTCH (packet data) burst */
|
[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 tx_pdtch_fn(struct l1sched_ts *l1ts, struct trx_dl_burst_req *br)
|
2020-06-05 17:56:29 +00:00
|
|
|
{
|
|
|
|
struct msgb *msg = NULL; /* make GCC happy */
|
osmo-bts-trx: fix recent regression in Tx lchan handlers
In my recent patch a0770250, among with the new burst buffer
allocation/release strategy, I introduced a regression:
/* send burst, if we already got a frame */
- if (br->bid > 0) {
- if (!*bursts_p)
- return -ENODEV;
+ if (br->bid > 0)
goto send_burst;
- }
We used to allocate the burst buffers in Rx/Tx lchan handlers, and
release them in case of an error, e.g. when no block is available
for transmission. In the case of Tx burst buffers, the state of
Tx burst buffer was additionally used to check if we have a valid
Tx block for transmission, as can be seen in the code snippet above.
As a side effect of my patch, osmo-bts-trx now keeps transmitting
3 out of 4 bursts (br->bid > 0) of the last valid block, until the
next valid Tx block is available for transmission.
This problem was not affecting the CS domain, where it's expected to
have a more or less constant pressure of Tx blocks. However it did
show up in the PS domain, where in the absence of active TBFs the
PCU may omit DL blocks.
Add a new field 'dl_mask' to struct l1sched_chan_state, similar to
the existing 'ul_mask', and use it to reconstruct the removed logic.
Change-Id: I4538a8fe6b29f8d6eca33ad27d4a9852e3a3e86c
Fixes: a0770250 "osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()"
2023-06-02 12:00:49 +00:00
|
|
|
struct l1sched_chan_state *chan_state = &l1ts->chan_state[br->chan];
|
|
|
|
ubit_t *burst, *bursts_p = chan_state->dl_bursts;
|
|
|
|
enum trx_mod_type *mod = &chan_state->dl_mod_type;
|
|
|
|
uint8_t *mask = &chan_state->dl_mask;
|
2020-06-05 17:56:29 +00:00
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
/* send burst, if we already got a frame */
|
osmo-bts-trx: fix recent regression in Tx lchan handlers
In my recent patch a0770250, among with the new burst buffer
allocation/release strategy, I introduced a regression:
/* send burst, if we already got a frame */
- if (br->bid > 0) {
- if (!*bursts_p)
- return -ENODEV;
+ if (br->bid > 0)
goto send_burst;
- }
We used to allocate the burst buffers in Rx/Tx lchan handlers, and
release them in case of an error, e.g. when no block is available
for transmission. In the case of Tx burst buffers, the state of
Tx burst buffer was additionally used to check if we have a valid
Tx block for transmission, as can be seen in the code snippet above.
As a side effect of my patch, osmo-bts-trx now keeps transmitting
3 out of 4 bursts (br->bid > 0) of the last valid block, until the
next valid Tx block is available for transmission.
This problem was not affecting the CS domain, where it's expected to
have a more or less constant pressure of Tx blocks. However it did
show up in the PS domain, where in the absence of active TBFs the
PCU may omit DL blocks.
Add a new field 'dl_mask' to struct l1sched_chan_state, similar to
the existing 'ul_mask', and use it to reconstruct the removed logic.
Change-Id: I4538a8fe6b29f8d6eca33ad27d4a9852e3a3e86c
Fixes: a0770250 "osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()"
2023-06-02 12:00:49 +00:00
|
|
|
if (br->bid > 0) {
|
|
|
|
if ((*mask & 0x01) != 0x01)
|
|
|
|
return -ENOMSG;
|
2020-06-05 17:56:29 +00:00
|
|
|
goto send_burst;
|
osmo-bts-trx: fix recent regression in Tx lchan handlers
In my recent patch a0770250, among with the new burst buffer
allocation/release strategy, I introduced a regression:
/* send burst, if we already got a frame */
- if (br->bid > 0) {
- if (!*bursts_p)
- return -ENODEV;
+ if (br->bid > 0)
goto send_burst;
- }
We used to allocate the burst buffers in Rx/Tx lchan handlers, and
release them in case of an error, e.g. when no block is available
for transmission. In the case of Tx burst buffers, the state of
Tx burst buffer was additionally used to check if we have a valid
Tx block for transmission, as can be seen in the code snippet above.
As a side effect of my patch, osmo-bts-trx now keeps transmitting
3 out of 4 bursts (br->bid > 0) of the last valid block, until the
next valid Tx block is available for transmission.
This problem was not affecting the CS domain, where it's expected to
have a more or less constant pressure of Tx blocks. However it did
show up in the PS domain, where in the absence of active TBFs the
PCU may omit DL blocks.
Add a new field 'dl_mask' to struct l1sched_chan_state, similar to
the existing 'ul_mask', and use it to reconstruct the removed logic.
Change-Id: I4538a8fe6b29f8d6eca33ad27d4a9852e3a3e86c
Fixes: a0770250 "osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()"
2023-06-02 12:00:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
*mask = *mask << 4;
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* get mac block from queue */
|
[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
|
|
|
msg = _sched_dequeue_prim(l1ts, br);
|
2021-10-25 16:25:21 +00:00
|
|
|
if (!msg) {
|
2021-10-25 16:31:11 +00:00
|
|
|
/* It's totally fine to get no block here, since PCU may submit
|
|
|
|
* empty blocks when there's no MS listening. The scheduler will
|
|
|
|
* take care of filling C0 with dummy bursts to keep expected
|
|
|
|
* power transmit levels
|
|
|
|
*/
|
2023-03-05 22:35:16 +00:00
|
|
|
return -ENODEV;
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* BURST BYPASS */
|
|
|
|
|
|
|
|
/* encode bursts */
|
2023-06-02 11:50:40 +00:00
|
|
|
rc = gsm0503_pdtch_egprs_encode(bursts_p, msg->l2h, msgb_l2len(msg));
|
2020-06-05 17:56:29 +00:00
|
|
|
if (rc < 0)
|
2023-06-02 11:50:40 +00:00
|
|
|
rc = gsm0503_pdtch_encode(bursts_p, msg->l2h, msgb_l2len(msg));
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* check validity of message */
|
|
|
|
if (rc < 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
|
|
|
LOGL1SB(DL1P, LOGL_FATAL, l1ts, br, "Prim invalid length, please FIX! "
|
2023-06-02 11:50:40 +00:00
|
|
|
"(len=%u)\n", msgb_l2len(msg));
|
2020-06-05 17:56:29 +00:00
|
|
|
/* free message */
|
|
|
|
msgb_free(msg);
|
2023-03-05 22:35:16 +00:00
|
|
|
return -EINVAL;
|
2020-06-05 17:56:29 +00:00
|
|
|
} else if (rc == GSM0503_EGPRS_BURSTS_NBITS) {
|
2021-04-15 03:54:07 +00:00
|
|
|
*mod = TRX_MOD_T_8PSK;
|
2020-06-05 17:56:29 +00:00
|
|
|
} else {
|
2021-04-15 03:54:07 +00:00
|
|
|
*mod = TRX_MOD_T_GMSK;
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* free message */
|
|
|
|
msgb_free(msg);
|
|
|
|
|
|
|
|
send_burst:
|
|
|
|
/* compose burst */
|
2021-04-15 03:54:07 +00:00
|
|
|
if (*mod == TRX_MOD_T_8PSK) {
|
2023-05-14 15:05:17 +00:00
|
|
|
burst = bursts_p + br->bid * 348;
|
2020-06-13 14:45:33 +00:00
|
|
|
memset(br->burst, 1, 9);
|
|
|
|
memcpy(br->burst + 9, burst, 174);
|
2021-05-22 01:33:13 +00:00
|
|
|
memcpy(br->burst + 183, TRX_8PSK_NB_TSC(br), 78);
|
2020-06-13 14:45:33 +00:00
|
|
|
memcpy(br->burst + 261, burst + 174, 174);
|
|
|
|
memset(br->burst + 435, 1, 9);
|
|
|
|
|
|
|
|
br->burst_len = EGPRS_BURST_LEN;
|
2020-06-05 17:56:29 +00:00
|
|
|
} else {
|
2023-05-14 15:05:17 +00:00
|
|
|
burst = bursts_p + br->bid * 116;
|
2020-06-13 14:45:33 +00:00
|
|
|
memcpy(br->burst + 3, burst, 58);
|
2021-05-22 01:33:13 +00:00
|
|
|
memcpy(br->burst + 61, TRX_GMSK_NB_TSC(br), 26);
|
2020-06-13 14:45:33 +00:00
|
|
|
memcpy(br->burst + 87, burst + 58, 58);
|
|
|
|
|
|
|
|
br->burst_len = GSM_BURST_LEN;
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|
|
|
|
|
osmo-bts-trx: fix recent regression in Tx lchan handlers
In my recent patch a0770250, among with the new burst buffer
allocation/release strategy, I introduced a regression:
/* send burst, if we already got a frame */
- if (br->bid > 0) {
- if (!*bursts_p)
- return -ENODEV;
+ if (br->bid > 0)
goto send_burst;
- }
We used to allocate the burst buffers in Rx/Tx lchan handlers, and
release them in case of an error, e.g. when no block is available
for transmission. In the case of Tx burst buffers, the state of
Tx burst buffer was additionally used to check if we have a valid
Tx block for transmission, as can be seen in the code snippet above.
As a side effect of my patch, osmo-bts-trx now keeps transmitting
3 out of 4 bursts (br->bid > 0) of the last valid block, until the
next valid Tx block is available for transmission.
This problem was not affecting the CS domain, where it's expected to
have a more or less constant pressure of Tx blocks. However it did
show up in the PS domain, where in the absence of active TBFs the
PCU may omit DL blocks.
Add a new field 'dl_mask' to struct l1sched_chan_state, similar to
the existing 'ul_mask', and use it to reconstruct the removed logic.
Change-Id: I4538a8fe6b29f8d6eca33ad27d4a9852e3a3e86c
Fixes: a0770250 "osmo-bts-trx: alloc/free burst buffers in trx_sched_set_lchan()"
2023-06-02 12:00:49 +00:00
|
|
|
*mask |= (1 << br->bid);
|
|
|
|
|
[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
|
|
|
LOGL1SB(DL1P, LOGL_DEBUG, l1ts, br, "Transmitting burst=%u.\n", br->bid);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
2020-06-13 14:45:33 +00:00
|
|
|
return 0;
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|