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/msgb.h>
|
|
|
|
#include <osmocom/core/utils.h>
|
|
|
|
|
|
|
|
#include <osmocom/gsm/gsm0502.h>
|
|
|
|
|
|
|
|
#include <osmocom/codec/codec.h>
|
|
|
|
#include <osmocom/codec/ecu.h>
|
|
|
|
|
|
|
|
#include <osmocom/coding/gsm0503_coding.h>
|
|
|
|
#include <osmocom/coding/gsm0503_amr_dtx.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 <osmo-bts/msg_utils.h>
|
|
|
|
|
|
|
|
#include <sched_utils.h>
|
|
|
|
#include <loops.h>
|
|
|
|
|
|
|
|
/*! \brief a single TCH/H 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_tchh_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];
|
2020-06-15 13:19:08 +00:00
|
|
|
struct gsm_lchan *lchan = chan_state->lchan;
|
2020-06-05 17:56:29 +00:00
|
|
|
sbit_t *burst, **bursts_p = &chan_state->ul_bursts;
|
|
|
|
uint8_t *mask = &chan_state->ul_mask;
|
|
|
|
uint8_t rsl_cmode = chan_state->rsl_cmode;
|
|
|
|
uint8_t tch_mode = chan_state->tch_mode;
|
|
|
|
uint8_t tch_data[128]; /* just to be safe */
|
|
|
|
int rc, amr = 0;
|
|
|
|
int n_errors = 0;
|
|
|
|
int n_bits_total = 0;
|
|
|
|
bool bfi_flag = false;
|
|
|
|
/* Note on FN-10: If we are at FN 10, we decoded an even aligned
|
|
|
|
* TCH/FACCH frame, because our burst buffer carries 6 bursts.
|
|
|
|
* Even FN ending at: 10,11,19,20,2,3
|
|
|
|
*/
|
|
|
|
int fn_is_odd = (((bi->fn + 26 - 10) % 26) >> 2) & 1;
|
2020-06-22 22:44:48 +00:00
|
|
|
enum sched_meas_avg_mode meas_avg_mode = SCHED_MEAS_AVG_M_QUAD;
|
|
|
|
struct l1sched_meas_set meas_avg;
|
2020-06-05 17:56:29 +00:00
|
|
|
unsigned int fn_begin;
|
2020-11-24 22:54:37 +00:00
|
|
|
unsigned int fn_tch_end;
|
2020-06-05 17:56:29 +00:00
|
|
|
uint16_t ber10k;
|
|
|
|
uint8_t is_sub = 0;
|
|
|
|
uint8_t ft;
|
2020-11-24 22:54:37 +00:00
|
|
|
bool mask_stolen_tch_block = false;
|
2021-08-26 11:55:27 +00:00
|
|
|
bool fn_is_cmi;
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* If handover RACH detection is turned on, treat this burst as an Access Burst.
|
|
|
|
* Handle NOPE.ind as usually to ensure proper Uplink measurement reporting. */
|
|
|
|
if (chan_state->ho_rach_detect == 1 && ~bi->flags & TRX_BI_F_NOPE_IND)
|
[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 rx_rach_fn(l1ts, bi);
|
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 TCH/H, bid=%u\n", bi->bid);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* allocate burst memory, if not already */
|
|
|
|
if (!*bursts_p) {
|
|
|
|
*bursts_p = talloc_zero_size(tall_bts_ctx, 696);
|
|
|
|
if (!*bursts_p)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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) {
|
2020-06-05 17:56:29 +00:00
|
|
|
memset(*bursts_p + 464, 0, 232);
|
|
|
|
*mask = 0x0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* 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-05 17:56:29 +00:00
|
|
|
|
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 end of buffer of 6 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
|
|
|
burst = *bursts_p + bi->bid * 116 + 464;
|
2020-06-05 17:56:29 +00:00
|
|
|
if (bi->burst_len > 0) {
|
|
|
|
memcpy(burst, bi->burst + 3, 58);
|
|
|
|
memcpy(burst + 58, bi->burst + 87, 58);
|
|
|
|
} else
|
|
|
|
memset(burst, 0, 116);
|
|
|
|
|
|
|
|
/* 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 != 1)
|
2020-06-05 17:56:29 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* check for complete set of bursts */
|
|
|
|
if ((*mask & 0x3) != 0x3) {
|
[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_NOTICE, l1ts, bi,
|
2020-06-05 17:56:29 +00:00
|
|
|
"Received incomplete frame (%u/%u)\n",
|
|
|
|
bi->fn % l1ts->mf_period, l1ts->mf_period);
|
|
|
|
}
|
|
|
|
*mask = 0x0;
|
|
|
|
|
2020-10-30 09:44:55 +00:00
|
|
|
/* skip decoding of the last 4 bursts of FACCH/H */
|
2020-06-05 17:56:29 +00:00
|
|
|
if (chan_state->ul_ongoing_facch) {
|
|
|
|
chan_state->ul_ongoing_facch = 0;
|
|
|
|
memcpy(*bursts_p, *bursts_p + 232, 232);
|
|
|
|
memcpy(*bursts_p + 232, *bursts_p + 464, 232);
|
2020-10-30 09:44:55 +00:00
|
|
|
/* we have already sent the first BFI when a FACCH/H frame
|
|
|
|
* was decoded (see below), now send the second one. */
|
2020-06-05 17:56:29 +00:00
|
|
|
ber10k = 0;
|
2020-09-25 13:44:08 +00:00
|
|
|
memset(&meas_avg, 0, sizeof(meas_avg));
|
2020-11-24 22:54:37 +00:00
|
|
|
/* In order to provide an even stream of measurement reports
|
|
|
|
* we ask the code below to mask the missing TCH/H block
|
|
|
|
* measurement report with the FACCH measurement results. */
|
|
|
|
mask_stolen_tch_block = true;
|
2020-06-05 17:56:29 +00:00
|
|
|
goto bfi;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* decode
|
|
|
|
* also shift buffer by 4 bursts for interleaving */
|
|
|
|
switch ((rsl_cmode != RSL_CMOD_SPD_SPEECH) ? GSM48_CMODE_SPEECH_V1
|
|
|
|
: tch_mode) {
|
|
|
|
case GSM48_CMODE_SPEECH_V1: /* HR or signalling */
|
|
|
|
/* Note on FN-10: If we are at FN 10, we decoded an even aligned
|
|
|
|
* TCH/FACCH frame, because our burst buffer carries 6 bursts.
|
|
|
|
* Even FN ending at: 10,11,19,20,2,3
|
|
|
|
*/
|
|
|
|
rc = gsm0503_tch_hr_decode(tch_data, *bursts_p,
|
|
|
|
fn_is_odd, &n_errors, &n_bits_total);
|
|
|
|
if (rc >= 0) /* DTXu */
|
|
|
|
lchan_set_marker(osmo_hr_check_sid(tch_data, rc), lchan);
|
|
|
|
break;
|
|
|
|
case GSM48_CMODE_SPEECH_AMR: /* AMR */
|
|
|
|
/* the first FN 0,8,17 or 1,9,18 defines that CMI is included
|
|
|
|
* in frame, the first FN 4,13,21 or 5,14,22 defines that CMR
|
|
|
|
* is included in frame.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* See comment in function rx_tchf_fn() */
|
|
|
|
switch (chan_state->amr_last_dtx) {
|
|
|
|
case AHS_ONSET:
|
|
|
|
case AHS_SID_FIRST_INH:
|
|
|
|
case AHS_SID_UPDATE_INH:
|
|
|
|
lchan_set_marker(false, lchan);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2021-08-26 11:55:27 +00:00
|
|
|
/* Calculate the frame number where the block begins */
|
|
|
|
if (bi->fn % 13 < 4)
|
|
|
|
fn_tch_end = GSM_TDMA_FN_SUB(bi->fn, 5);
|
|
|
|
else
|
|
|
|
fn_tch_end = GSM_TDMA_FN_SUB(bi->fn, 4);
|
|
|
|
if (lchan->nr == 0)
|
|
|
|
fn_begin = gsm0502_fn_remap(fn_tch_end, FN_REMAP_TCH_H0);
|
|
|
|
else
|
|
|
|
fn_begin = gsm0502_fn_remap(fn_tch_end, FN_REMAP_TCH_H1);
|
|
|
|
fn_is_cmi = ul_amr_fn_is_cmi(fn_begin);
|
|
|
|
|
2020-06-05 17:56:29 +00:00
|
|
|
/* See comment in function rx_tchf_fn() */
|
|
|
|
amr = 2;
|
|
|
|
rc = gsm0503_tch_ahs_decode_dtx(tch_data + amr, *bursts_p,
|
2021-08-26 11:55:27 +00:00
|
|
|
fn_is_odd, !fn_is_cmi, chan_state->codec,
|
2020-06-05 17:56:29 +00:00
|
|
|
chan_state->codecs, &chan_state->ul_ft,
|
|
|
|
&chan_state->ul_cmr, &n_errors, &n_bits_total, &chan_state->amr_last_dtx);
|
|
|
|
|
|
|
|
/* Tag all frames that are not regular AMR voice frames
|
|
|
|
as SUB-Frames */
|
|
|
|
if (chan_state->amr_last_dtx != AMR_OTHER) {
|
[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 AMR SID frame: %s\n",
|
[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
|
|
|
gsm0503_amr_dtx_frame_name(chan_state->amr_last_dtx));
|
2020-06-05 17:56:29 +00:00
|
|
|
is_sub = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* See comment in function rx_tchf_fn() */
|
|
|
|
switch (chan_state->amr_last_dtx) {
|
|
|
|
case AHS_SID_FIRST_P1:
|
|
|
|
case AHS_SID_FIRST_P2:
|
|
|
|
case AHS_SID_UPDATE:
|
|
|
|
case AHS_SID_UPDATE_CN:
|
|
|
|
lchan_set_marker(true, lchan);
|
|
|
|
lchan->rtp_tx_marker = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-06-22 23:11:20 +00:00
|
|
|
switch (chan_state->amr_last_dtx) {
|
|
|
|
case AHS_SID_FIRST_P1:
|
|
|
|
case AHS_SID_FIRST_P2:
|
|
|
|
case AHS_SID_UPDATE:
|
|
|
|
case AHS_SID_UPDATE_CN:
|
|
|
|
case AHS_SID_FIRST_INH:
|
|
|
|
case AHS_SID_UPDATE_INH:
|
|
|
|
meas_avg_mode = SCHED_MEAS_AVG_M6_FIRST_TWO;
|
|
|
|
break;
|
|
|
|
case AHS_ONSET:
|
|
|
|
meas_avg_mode = SCHED_MEAS_AVG_M6_MIDDLE_TWO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2020-06-05 17:56:29 +00:00
|
|
|
if (rc)
|
[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_loop_amr_input(chan_state, n_errors, n_bits_total);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* only good speech frames get rtp header */
|
|
|
|
if (rc != GSM_MACBLOCK_LEN && rc >= 4) {
|
|
|
|
if (chan_state->amr_last_dtx == AMR_OTHER) {
|
2021-08-26 12:35:50 +00:00
|
|
|
ft = chan_state->codec[chan_state->ul_ft];
|
2020-06-05 17:56:29 +00:00
|
|
|
} else {
|
|
|
|
/* SID frames will always get Frame Type Index 8 (AMR_SID) */
|
|
|
|
ft = AMR_SID;
|
|
|
|
}
|
|
|
|
rc = osmo_amr_rtp_enc(tch_data,
|
|
|
|
chan_state->codec[chan_state->ul_cmr],
|
|
|
|
ft, AMR_GOOD);
|
|
|
|
}
|
|
|
|
|
|
|
|
break;
|
|
|
|
default:
|
[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_ERROR, l1ts, bi,
|
2020-06-05 17:56:29 +00:00
|
|
|
"TCH mode %u invalid, please fix!\n",
|
|
|
|
tch_mode);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
memcpy(*bursts_p, *bursts_p + 232, 232);
|
|
|
|
memcpy(*bursts_p + 232, *bursts_p + 464, 232);
|
|
|
|
ber10k = compute_ber10k(n_bits_total, n_errors);
|
|
|
|
|
2020-06-22 22:44:48 +00:00
|
|
|
/* average measurements of the last N (depends on mode) bursts */
|
|
|
|
if (rc == GSM_MACBLOCK_LEN)
|
|
|
|
meas_avg_mode = SCHED_MEAS_AVG_M_SIX;
|
|
|
|
trx_sched_meas_avg(chan_state, &meas_avg, meas_avg_mode);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* Check if the frame is bad */
|
|
|
|
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_NOTICE, l1ts, bi, "Received bad data (%u/%u)\n",
|
2020-06-05 17:56:29 +00:00
|
|
|
bi->fn % l1ts->mf_period, l1ts->mf_period);
|
|
|
|
bfi_flag = true;
|
|
|
|
} else if (rc < 4) {
|
[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_NOTICE, l1ts, bi,
|
2020-06-05 17:56:29 +00:00
|
|
|
"Received bad data (%u/%u) with invalid codec mode %d\n",
|
|
|
|
bi->fn % l1ts->mf_period, l1ts->mf_period, rc);
|
|
|
|
bfi_flag = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rc != GSM_MACBLOCK_LEN && lchan->ecu_state)
|
|
|
|
osmo_ecu_frame_in(lchan->ecu_state, bfi_flag, tch_data, rc);
|
|
|
|
|
|
|
|
if (bfi_flag)
|
|
|
|
goto bfi;
|
|
|
|
|
|
|
|
/* FACCH */
|
|
|
|
if (rc == GSM_MACBLOCK_LEN) {
|
|
|
|
chan_state->ul_ongoing_facch = 1;
|
|
|
|
uint16_t ber10k = compute_ber10k(n_bits_total, n_errors);
|
|
|
|
if (lchan->nr == 0)
|
|
|
|
fn_begin = gsm0502_fn_remap(bi->fn, FN_REMAP_FACCH_H0);
|
|
|
|
else
|
|
|
|
fn_begin = gsm0502_fn_remap(bi->fn, FN_REMAP_FACCH_H1);
|
[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
|
|
|
_sched_compose_ph_data_ind(l1ts, fn_begin, bi->chan,
|
2020-06-05 17:56:29 +00:00
|
|
|
tch_data + amr, GSM_MACBLOCK_LEN,
|
2020-06-22 22:44:48 +00:00
|
|
|
meas_avg.rssi, meas_avg.toa256,
|
|
|
|
meas_avg.ci_cb, ber10k,
|
|
|
|
PRES_INFO_UNKNOWN);
|
2020-11-24 22:54:37 +00:00
|
|
|
|
|
|
|
/* Keep a copy of the measurement results of the last FACCH
|
|
|
|
* transmission in order to be able to create a replacement
|
|
|
|
* measurement result for the one missing TCH block
|
|
|
|
* measurement */
|
|
|
|
memcpy(&chan_state->meas_avg_facch, &meas_avg, sizeof(meas_avg));
|
|
|
|
chan_state->ber10k_facch = ber10k;
|
|
|
|
|
|
|
|
/* Invalidate the current measurement result to prevent the
|
|
|
|
* code below from handing up the current measurement a second
|
|
|
|
* time. */
|
|
|
|
memset(&meas_avg, 0, sizeof(meas_avg));
|
2020-06-05 17:56:29 +00:00
|
|
|
bfi:
|
2020-10-30 09:44:55 +00:00
|
|
|
/* A FACCH/H frame replaces two speech frames, so we need to send two BFIs.
|
|
|
|
* One is sent here, another will be sent two bursts later (see above). */
|
2020-06-05 17:56:29 +00:00
|
|
|
if (rsl_cmode == RSL_CMOD_SPD_SPEECH) {
|
|
|
|
/* indicate bad frame */
|
|
|
|
if (lchan->tch.dtx.ul_sid) {
|
|
|
|
/* DTXu: pause in progress. Push empty payload to upper layers */
|
|
|
|
rc = 0;
|
|
|
|
goto compose_l1sap;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If there is an ECU active on this channel, use its output */
|
|
|
|
if (lchan->ecu_state) {
|
|
|
|
rc = osmo_ecu_frame_out(lchan->ecu_state, tch_data);
|
|
|
|
if (rc >= 0) /* Otherwise we send a BFI */
|
|
|
|
goto compose_l1sap;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (tch_mode) {
|
|
|
|
case GSM48_CMODE_SPEECH_V1: /* HR */
|
|
|
|
tch_data[0] = 0x70; /* F = 0, FT = 111 */
|
|
|
|
memset(tch_data + 1, 0, 14);
|
|
|
|
rc = 15;
|
|
|
|
break;
|
|
|
|
case GSM48_CMODE_SPEECH_AMR: /* AMR */
|
|
|
|
rc = osmo_amr_rtp_enc(tch_data,
|
|
|
|
chan_state->codec[chan_state->dl_cmr],
|
|
|
|
chan_state->codec[chan_state->dl_ft],
|
|
|
|
AMR_BAD);
|
|
|
|
if (rc < 2) {
|
[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_ERROR, l1ts, bi,
|
2020-06-05 17:56:29 +00:00
|
|
|
"Failed to encode AMR_BAD frame (rc=%d), "
|
|
|
|
"not sending BFI\n", rc);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
memset(tch_data + 2, 0, rc - 2);
|
|
|
|
break;
|
|
|
|
default:
|
[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_ERROR, l1ts, bi,
|
2020-06-05 17:56:29 +00:00
|
|
|
"TCH mode %u invalid, please fix!\n", tch_mode);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (rsl_cmode != RSL_CMOD_SPD_SPEECH)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
compose_l1sap:
|
|
|
|
/* TCH or BFI */
|
2020-11-24 22:54:37 +00:00
|
|
|
|
|
|
|
/* The input to gsm0502_fn_remap() needs to get the frame number we
|
|
|
|
* got two bursts ago. The reason for this is that the burst shift
|
|
|
|
* buffer we use for decoding is 6 bursts wide (one SACCH block) but
|
|
|
|
* TCH/H blocks are only 4 bursts wide. The decoder functions look
|
|
|
|
* at the beginning of the buffer while we shift into it at the end,
|
|
|
|
* this means that TCH/H blocks always decode delayed by two frame
|
|
|
|
* number positions late. To calculatue the ending frame number of
|
|
|
|
* the TCH/H we need to subtract 4 or 5 frames if there was a SACCH
|
|
|
|
* in between. (Note: this is TCH/H, 4 frames ==> 2 bursts) */
|
|
|
|
if (bi->fn % 13 < 4)
|
|
|
|
fn_tch_end = GSM_TDMA_FN_SUB(bi->fn, 5);
|
|
|
|
else
|
|
|
|
fn_tch_end = GSM_TDMA_FN_SUB(bi->fn, 4);
|
2020-06-05 17:56:29 +00:00
|
|
|
if (lchan->nr == 0)
|
2020-11-24 22:54:37 +00:00
|
|
|
fn_begin = gsm0502_fn_remap(fn_tch_end, FN_REMAP_TCH_H0);
|
2020-06-05 17:56:29 +00:00
|
|
|
else
|
2020-11-24 22:54:37 +00:00
|
|
|
fn_begin = gsm0502_fn_remap(fn_tch_end, FN_REMAP_TCH_H1);
|
|
|
|
|
|
|
|
/* A FACCH/H transmission takes out two TCH/H voice blocks and the
|
|
|
|
* related measurement results. The first measurement result is handed
|
|
|
|
* up directly with the FACCH (see above), the second one needs to be
|
|
|
|
* compensated by filling the gap with the measurement result we got
|
|
|
|
* from the FACCH transmission. */
|
|
|
|
if (mask_stolen_tch_block) {
|
|
|
|
memcpy(&meas_avg, &chan_state->meas_avg_facch, sizeof(meas_avg));
|
|
|
|
ber10k = chan_state->ber10k_facch;
|
|
|
|
memset(&chan_state->meas_avg_facch, 0, sizeof(meas_avg));
|
|
|
|
chan_state->ber10k_facch = 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
|
|
|
return _sched_compose_tch_ind(l1ts, fn_begin, bi->chan, tch_data, rc,
|
2020-06-22 22:44:48 +00:00
|
|
|
/* FIXME: what should we use for BFI here? */
|
|
|
|
bfi_flag ? bi->toa256 : meas_avg.toa256, ber10k,
|
|
|
|
bfi_flag ? bi->rssi : meas_avg.rssi, is_sub);
|
2020-06-05 17:56:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* common section for generation of TCH bursts (TCH/H and TCH/F).
|
|
|
|
* FIXME: this function is over-complicated, refactor / get rid of 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
|
|
|
extern void tx_tch_common(struct l1sched_ts *l1ts,
|
[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
|
|
|
const struct trx_dl_burst_req *br,
|
2020-06-05 17:56:29 +00:00
|
|
|
struct msgb **_msg_tch, struct msgb **_msg_facch);
|
|
|
|
|
|
|
|
/* obtain a to-be-transmitted TCH/H (Half Traffic Channel) 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_tchh_fn(struct l1sched_ts *l1ts, struct trx_dl_burst_req *br)
|
2020-06-05 17:56:29 +00:00
|
|
|
{
|
|
|
|
struct msgb *msg_tch = NULL, *msg_facch = NULL;
|
[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[br->chan];
|
2020-06-05 17:56:29 +00:00
|
|
|
uint8_t tch_mode = chan_state->tch_mode;
|
|
|
|
ubit_t *burst, **bursts_p = &chan_state->dl_bursts;
|
|
|
|
|
|
|
|
/* send burst, if we already got a frame */
|
[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 (br->bid > 0) {
|
2020-06-05 17:56:29 +00:00
|
|
|
if (!*bursts_p)
|
2020-06-13 14:45:33 +00:00
|
|
|
return 0;
|
2020-06-05 17:56:29 +00:00
|
|
|
goto send_burst;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* get TCH and/or FACCH */
|
[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
|
|
|
tx_tch_common(l1ts, br, &msg_tch, &msg_facch);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
|
|
|
/* check for FACCH alignment */
|
2020-06-13 14:45:33 +00:00
|
|
|
if (msg_facch && ((((br->fn + 4) % 26) >> 2) & 1)) {
|
[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_ERROR, l1ts, br,
|
[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
|
|
|
"Cannot transmit FACCH starting on even frames, please fix RTS!\n");
|
2020-06-05 17:56:29 +00:00
|
|
|
msgb_free(msg_facch);
|
|
|
|
msg_facch = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* BURST BYPASS */
|
|
|
|
|
|
|
|
/* allocate burst memory, if not already,
|
|
|
|
* otherwise shift buffer by 2 bursts for interleaving */
|
|
|
|
if (!*bursts_p) {
|
|
|
|
*bursts_p = talloc_zero_size(tall_bts_ctx, 696);
|
|
|
|
if (!*bursts_p)
|
2020-06-13 14:45:33 +00:00
|
|
|
return -ENOMEM;
|
2020-06-05 17:56:29 +00:00
|
|
|
} else {
|
|
|
|
memcpy(*bursts_p, *bursts_p + 232, 232);
|
|
|
|
if (chan_state->dl_ongoing_facch) {
|
|
|
|
memcpy(*bursts_p + 232, *bursts_p + 464, 232);
|
|
|
|
memset(*bursts_p + 464, 0, 232);
|
|
|
|
} else {
|
|
|
|
memset(*bursts_p + 232, 0, 232);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-07-04 18:06:46 +00:00
|
|
|
/* no message at all, send a dummy L2 frame on FACCH */
|
2020-06-05 17:56:29 +00:00
|
|
|
if (!msg_tch && !msg_facch && !chan_state->dl_ongoing_facch) {
|
2021-07-04 18:06:46 +00:00
|
|
|
static const uint8_t dummy[GSM_MACBLOCK_LEN] = {
|
|
|
|
0x03, 0x03, 0x01, /* TODO: use randomized padding */
|
|
|
|
0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b,
|
|
|
|
0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b, 0x2b,
|
|
|
|
};
|
|
|
|
|
[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_INFO, l1ts, br, "No TCH or FACCH prim for transmit.\n");
|
2021-07-04 18:06:46 +00:00
|
|
|
gsm0503_tch_hr_encode(*bursts_p, dummy, sizeof(dummy));
|
2020-06-05 17:56:29 +00:00
|
|
|
goto send_burst;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* encode bursts (prioritize FACCH) */
|
|
|
|
if (msg_facch) {
|
|
|
|
gsm0503_tch_hr_encode(*bursts_p, msg_facch->l2h, msgb_l2len(msg_facch));
|
|
|
|
chan_state->dl_ongoing_facch = 1; /* first of two TCH frames */
|
|
|
|
} else if (chan_state->dl_ongoing_facch) /* second of two TCH frames */
|
|
|
|
chan_state->dl_ongoing_facch = 0; /* we are done with FACCH */
|
|
|
|
else if (tch_mode == GSM48_CMODE_SPEECH_AMR)
|
|
|
|
/* the first FN 4,13,21 or 5,14,22 defines that CMI is included
|
|
|
|
* in frame, the first FN 0,8,17 or 1,9,18 defines that CMR is
|
|
|
|
* included in frame. */
|
|
|
|
gsm0503_tch_ahs_encode(*bursts_p, msg_tch->l2h + 2,
|
2021-08-26 11:55:27 +00:00
|
|
|
msgb_l2len(msg_tch) - 2, !dl_amr_fn_is_cmi(br->fn),
|
2020-06-05 17:56:29 +00:00
|
|
|
chan_state->codec, chan_state->codecs,
|
|
|
|
chan_state->dl_ft,
|
|
|
|
chan_state->dl_cmr);
|
|
|
|
else
|
|
|
|
gsm0503_tch_hr_encode(*bursts_p, msg_tch->l2h, msgb_l2len(msg_tch));
|
|
|
|
|
|
|
|
/* free message */
|
|
|
|
if (msg_tch)
|
|
|
|
msgb_free(msg_tch);
|
|
|
|
if (msg_facch)
|
|
|
|
msgb_free(msg_facch);
|
|
|
|
|
|
|
|
send_burst:
|
|
|
|
/* compose 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
|
|
|
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);
|
2020-06-05 17:56:29 +00:00
|
|
|
|
2020-06-13 14:45:33 +00:00
|
|
|
br->burst_len = GSM_BURST_LEN;
|
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, 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
|
|
|
}
|