2021-05-15 13:00:15 +00:00
|
|
|
#pragma once
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2017-01-09 12:37:02 +00:00
|
|
|
#include <osmocom/core/utils.h>
|
2020-06-16 14:02:55 +00:00
|
|
|
#include <osmocom/core/rate_ctr.h>
|
2017-01-09 12:37:02 +00:00
|
|
|
|
2016-01-09 12:13:37 +00:00
|
|
|
#include <osmo-bts/gsm_data.h>
|
|
|
|
|
2021-05-22 01:33:13 +00:00
|
|
|
#define TRX_GMSK_NB_TSC(br) \
|
2021-05-20 00:27:47 +00:00
|
|
|
_sched_train_seq_gmsk_nb[(br)->tsc_set][(br)->tsc]
|
2021-05-22 01:33:13 +00:00
|
|
|
|
|
|
|
#define TRX_8PSK_NB_TSC(br) \
|
|
|
|
_sched_train_seq_8psk_nb[(br)->tsc]
|
|
|
|
|
2021-06-09 21:00:18 +00:00
|
|
|
#define TRX_CHAN_IS_DEDIC(chan) \
|
|
|
|
(chan >= TRXC_TCHF)
|
|
|
|
|
2016-01-09 20:33:58 +00:00
|
|
|
/* These types define the different channels on a multiframe.
|
|
|
|
* Each channel has queues and can be activated individually.
|
|
|
|
*/
|
|
|
|
enum trx_chan_type {
|
|
|
|
TRXC_IDLE = 0,
|
|
|
|
TRXC_FCCH,
|
|
|
|
TRXC_SCH,
|
|
|
|
TRXC_BCCH,
|
|
|
|
TRXC_RACH,
|
|
|
|
TRXC_CCCH,
|
2021-06-09 21:00:18 +00:00
|
|
|
TRXC_CBCH,
|
|
|
|
TRXC_PDTCH,
|
|
|
|
TRXC_PTCCH,
|
|
|
|
/* Dedicated channels start here */
|
2016-01-09 20:33:58 +00:00
|
|
|
TRXC_TCHF,
|
|
|
|
TRXC_TCHH_0,
|
|
|
|
TRXC_TCHH_1,
|
|
|
|
TRXC_SDCCH4_0,
|
|
|
|
TRXC_SDCCH4_1,
|
|
|
|
TRXC_SDCCH4_2,
|
|
|
|
TRXC_SDCCH4_3,
|
|
|
|
TRXC_SDCCH8_0,
|
|
|
|
TRXC_SDCCH8_1,
|
|
|
|
TRXC_SDCCH8_2,
|
|
|
|
TRXC_SDCCH8_3,
|
|
|
|
TRXC_SDCCH8_4,
|
|
|
|
TRXC_SDCCH8_5,
|
|
|
|
TRXC_SDCCH8_6,
|
|
|
|
TRXC_SDCCH8_7,
|
|
|
|
TRXC_SACCHTF,
|
|
|
|
TRXC_SACCHTH_0,
|
|
|
|
TRXC_SACCHTH_1,
|
|
|
|
TRXC_SACCH4_0,
|
|
|
|
TRXC_SACCH4_1,
|
|
|
|
TRXC_SACCH4_2,
|
|
|
|
TRXC_SACCH4_3,
|
|
|
|
TRXC_SACCH8_0,
|
|
|
|
TRXC_SACCH8_1,
|
|
|
|
TRXC_SACCH8_2,
|
|
|
|
TRXC_SACCH8_3,
|
|
|
|
TRXC_SACCH8_4,
|
|
|
|
TRXC_SACCH8_5,
|
|
|
|
TRXC_SACCH8_6,
|
|
|
|
TRXC_SACCH8_7,
|
|
|
|
_TRX_CHAN_MAX
|
|
|
|
};
|
|
|
|
|
2016-07-01 07:10:31 +00:00
|
|
|
#define GSM_BURST_LEN 148
|
|
|
|
#define GPRS_BURST_LEN GSM_BURST_LEN
|
|
|
|
#define EGPRS_BURST_LEN 444
|
|
|
|
|
2021-04-15 03:54:07 +00:00
|
|
|
enum trx_mod_type {
|
|
|
|
TRX_MOD_T_GMSK,
|
|
|
|
TRX_MOD_T_8PSK,
|
2021-05-27 19:51:44 +00:00
|
|
|
TRX_MOD_T_AQPSK,
|
2016-07-01 07:10:31 +00:00
|
|
|
};
|
|
|
|
|
2020-06-22 22:44:48 +00:00
|
|
|
/* A set of measurements belonging to one Uplink burst */
|
|
|
|
struct l1sched_meas_set {
|
2022-03-20 00:22:14 +00:00
|
|
|
uint32_t fn; /* TDMA frame number */
|
2020-06-22 22:44:48 +00:00
|
|
|
int16_t toa256; /* Timing of Arrival (1/256 of a symbol) */
|
|
|
|
int16_t ci_cb; /* Carrier-to-Interference (cB) */
|
|
|
|
float rssi; /* RSSI (dBm) */
|
|
|
|
};
|
|
|
|
|
2016-01-09 20:33:58 +00:00
|
|
|
/* States each channel on a multiframe */
|
|
|
|
struct l1sched_chan_state {
|
2020-06-15 13:19:08 +00:00
|
|
|
/* Pointer to the associated logical channel state from gsm_data_shared.
|
|
|
|
* Initialized during channel activation, thus may be NULL for inactive
|
|
|
|
* or auto-active channels. Always check before dereferencing! */
|
|
|
|
struct gsm_lchan *lchan;
|
|
|
|
|
2016-01-09 20:33:58 +00:00
|
|
|
/* scheduler */
|
2020-06-05 20:05:02 +00:00
|
|
|
bool active; /* Channel is active */
|
2016-01-09 20:33:58 +00:00
|
|
|
ubit_t *dl_bursts; /* burst buffer for TX */
|
2021-04-15 03:54:07 +00:00
|
|
|
enum trx_mod_type dl_mod_type; /* Downlink modulation type */
|
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
|
|
|
uint8_t dl_mask; /* mask of transmitted bursts */
|
2016-01-09 20:33:58 +00:00
|
|
|
sbit_t *ul_bursts; /* burst buffer for RX */
|
|
|
|
uint32_t ul_first_fn; /* fn of first burst */
|
2023-05-15 09:37:49 +00:00
|
|
|
uint32_t ul_mask; /* mask of received bursts */
|
2016-01-09 20:33:58 +00:00
|
|
|
|
|
|
|
/* loss detection */
|
common/scheduler.c: track TDMA frame loss per logical channels
This change modifies the logic of TDMA frame loss tracking. To
be more precise, the tracking logic was moved from per timeslot
level to per logical channel level, what makes OsmoBTS more
accurate in its measurements.
But before getting into details, it's important to clarify some
things about the Uplink burst processing in transceiver (OsmoTRX).
If an Uplink burst is detected, OsmoTRX demodulates it and sends
to OsmoBTS. If nothing is detected on a particular timeslot,
OsmoTRX will do nothing. In other words, it will not
notify OsmoBTS about this.
Meanwhile, there are usually a few logical channels mapped to a
single TDMA timeslot. Let's use SDCCH8 channel configuration as
an example (simplified layout):
/* SDCCH/8 (ss=0), subscriber A (active) */
{ TRXC_SDCCH8_0, bid=0 },
{ TRXC_SDCCH8_0, bid=1 },
{ TRXC_SDCCH8_0, bid=2 },
{ TRXC_SDCCH8_0, bid=3 }, // <-- last_fn=X
/* SDCCH/8 (ss=1), subscriber B (inactive) */
{ TRXC_SDCCH8_1, bid=0 },
{ TRXC_SDCCH8_1, bid=1 },
{ TRXC_SDCCH8_1, bid=2 },
{ TRXC_SDCCH8_1, bid=3 },
/* SDCCH/8 (ss=2), subscriber C (active) */
{ TRXC_SDCCH8_2, bid=0 }, // <-- current_fn=X+5
{ TRXC_SDCCH8_2, bid=1 },
{ TRXC_SDCCH8_2, bid=2 },
{ TRXC_SDCCH8_2, bid=3 },
SDCCH8 has 8 sub-slots, so up to 8 subscribers can use a single
timeslot. Let's imagine there are three subscribers: A, B, and C.
Both A and C are active subscribers, i.e. they are continuously
transmitting UL bursts, while B is not using ss=1 anymore.
The original way of TDMA frame loss tracking was the following:
- when an UL burst is received, store it's frame number in
the timeslot state structure (last_fn);
- when the next UL burst is received on same timeslot, compute
how many frames elapsed since the last_fn;
- if elapsed = (current_fn - last_fn) is lower than 10, then
iterate from (last_fn + 1) until the current_fn and send
dummy zero-filled bursts to the higher layers;
- otherwise (elapsed > 10), process the current burst,
and do nothing :/
According to our example, subscriber A is sending 4 bursts, then
nobody is sending anything, and then subscriber C is sending
4 bursts. So, there is a 4 frames long gap between the both
transmissions, which is being substituted by dummy bursts. But,
as the logical channel on ss=1 is not active, they are dropped.
This is not that scary, but the current algorithm produces lots
of false-positives, and moreover is not able to track real frame
drops in longer periods (i.e. >10). So, tracking the frame loss
per individual logical channels makes much more sense.
Let's finally drop this hackish 'while (42) { ... }', and track
the amount of lost / received TDMA frames (bursts) individually
per logical channels. Let's also use the multiframe period as
the loss detection period, instead of hardcoded 10. And finally,
let's print more informative debug messages.
Also, it makes sense to use the amount of lost / received bursts
during the calculation of the measurement reports, instead of
sending dummy bursts, but let's do this separately.
Change-Id: I70d05b67a35ddcbdd1b6394dbd7198404a440e76
Related: OS#3428
2018-08-02 09:22:17 +00:00
|
|
|
uint32_t last_tdma_fn; /* last processed TDMA frame number */
|
|
|
|
uint32_t proc_tdma_fs; /* how many TDMA frames were processed */
|
|
|
|
uint32_t lost_tdma_fs; /* how many TDMA frames were lost */
|
2016-01-09 20:33:58 +00:00
|
|
|
|
|
|
|
/* mode */
|
|
|
|
uint8_t rsl_cmode, tch_mode; /* mode for TCH channels */
|
|
|
|
|
|
|
|
/* AMR */
|
|
|
|
uint8_t codec[4]; /* 4 possible codecs for amr */
|
|
|
|
int codecs; /* number of possible codecs */
|
2022-04-12 13:12:41 +00:00
|
|
|
int lqual_cb_sum; /* sum of link quality samples (in cB) */
|
|
|
|
int lqual_cb_num; /* number of link quality samples */
|
2016-01-09 20:33:58 +00:00
|
|
|
uint8_t ul_ft; /* current uplink FT index */
|
|
|
|
uint8_t dl_ft; /* current downlink FT index */
|
|
|
|
uint8_t ul_cmr; /* current uplink CMR index */
|
|
|
|
uint8_t dl_cmr; /* current downlink CMR index */
|
2020-02-06 13:31:22 +00:00
|
|
|
uint8_t amr_last_dtx; /* last received dtx frame type */
|
2016-01-09 20:33:58 +00:00
|
|
|
|
|
|
|
/* TCH/H */
|
|
|
|
uint8_t dl_ongoing_facch; /* FACCH/H on downlink */
|
|
|
|
uint8_t ul_ongoing_facch; /* FACCH/H on uplink */
|
|
|
|
|
2021-08-29 13:32:51 +00:00
|
|
|
uint8_t dl_facch_bursts; /* number of remaining DL FACCH bursts */
|
|
|
|
|
2016-01-09 20:33:58 +00:00
|
|
|
/* encryption */
|
|
|
|
int ul_encr_algo; /* A5/x encry algo downlink */
|
|
|
|
int dl_encr_algo; /* A5/x encry algo uplink */
|
|
|
|
int ul_encr_key_len;
|
|
|
|
int dl_encr_key_len;
|
|
|
|
uint8_t ul_encr_key[MAX_A5_KEY_LEN];
|
|
|
|
uint8_t dl_encr_key[MAX_A5_KEY_LEN];
|
|
|
|
|
2021-06-08 15:54:24 +00:00
|
|
|
/* Uplink measurements */
|
2020-06-22 22:44:48 +00:00
|
|
|
struct {
|
2021-06-08 15:54:24 +00:00
|
|
|
/* Active channel measurements (simple ring buffer) */
|
2023-07-12 20:42:03 +00:00
|
|
|
struct l1sched_meas_set buf[24]; /* up to 24 (BUFMAX) entries */
|
2020-06-22 22:44:48 +00:00
|
|
|
unsigned int current; /* current position */
|
2021-06-08 15:54:24 +00:00
|
|
|
|
|
|
|
/* Interference measurements */
|
|
|
|
int interf_avg; /* sliding average */
|
2020-06-22 22:44:48 +00:00
|
|
|
} meas;
|
2016-01-09 20:33:58 +00:00
|
|
|
|
|
|
|
/* handover */
|
2019-06-01 14:27:02 +00:00
|
|
|
bool ho_rach_detect; /* if rach detection is on */
|
2016-01-09 20:33:58 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct l1sched_ts {
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
struct gsm_bts_trx_ts *ts; /* timeslot we belong to */
|
|
|
|
|
2016-01-09 20:33:58 +00:00
|
|
|
uint8_t mf_index; /* selected multiframe index */
|
|
|
|
uint8_t mf_period; /* period of multiframe */
|
|
|
|
const struct trx_sched_frame *mf_frames; /* pointer to frame layout */
|
|
|
|
|
2017-06-04 11:26:00 +00:00
|
|
|
struct llist_head dl_prims; /* Queue primitives for TX */
|
2016-01-09 20:33:58 +00:00
|
|
|
|
2020-06-16 14:02:55 +00:00
|
|
|
struct rate_ctr_group *ctrs; /* rate counters */
|
|
|
|
|
2016-01-09 20:33:58 +00:00
|
|
|
/* Channel states for all logical channels */
|
|
|
|
struct l1sched_chan_state chan_state[_TRX_CHAN_MAX];
|
|
|
|
};
|
|
|
|
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2016-07-06 12:05:08 +00:00
|
|
|
/*! \brief Initialize the scheduler data structures */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
void trx_sched_init(struct gsm_bts_trx *trx);
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2016-07-06 12:05:08 +00:00
|
|
|
/*! \brief De-initialize the scheduler data structures */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
void trx_sched_clean(struct gsm_bts_trx *trx);
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2016-01-09 12:26:14 +00:00
|
|
|
/*! \brief Handle a PH-DATA.req from L2 down to L1 */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
int trx_sched_ph_data_req(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap);
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2016-01-09 12:26:14 +00:00
|
|
|
/*! \brief Handle a PH-TCH.req from L2 down to L1 */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
int trx_sched_tch_req(struct gsm_bts_trx *trx, struct osmo_phsap_prim *l1sap);
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2017-06-04 11:26:00 +00:00
|
|
|
/*! \brief PHY informs us of new (current) GSM frame number */
|
2016-01-09 22:15:41 +00:00
|
|
|
int trx_sched_clock(struct gsm_bts *bts, uint32_t fn);
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2019-10-08 16:30:43 +00:00
|
|
|
/*! \brief PHY informs us clock indications should start to be received */
|
|
|
|
int trx_sched_clock_started(struct gsm_bts *bts);
|
|
|
|
|
|
|
|
/*! \brief PHY informs us no more clock indications should be received anymore */
|
|
|
|
int trx_sched_clock_stopped(struct gsm_bts *bts);
|
|
|
|
|
2016-01-09 12:26:14 +00:00
|
|
|
/*! \brief set multiframe scheduler to given physical channel config */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
int trx_sched_set_pchan(struct gsm_bts_trx_ts *ts, enum gsm_phys_chan_config pchan);
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2016-01-09 12:26:14 +00:00
|
|
|
/*! \brief set all matching logical channels active/inactive */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
int trx_sched_set_lchan(struct gsm_lchan *lchan, uint8_t chan_nr, uint8_t link_id, bool active);
|
2013-02-05 10:45:28 +00:00
|
|
|
|
2023-10-24 15:49:01 +00:00
|
|
|
/*! \brief set uplink access on given logical channels active/inactive */
|
|
|
|
int trx_sched_set_ul_access(struct gsm_lchan *lchan, uint8_t chan_nr, bool active);
|
|
|
|
|
2023-03-07 01:52:25 +00:00
|
|
|
/*! \brief set all logical channels of BCCH/CCCH active/inactive */
|
|
|
|
int trx_sched_set_bcch_ccch(struct gsm_lchan *lchan, bool active);
|
|
|
|
|
2016-01-09 12:26:14 +00:00
|
|
|
/*! \brief set mode of all matching logical channels to given mode(s) */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
int trx_sched_set_mode(struct gsm_bts_trx_ts *ts, uint8_t chan_nr, uint8_t rsl_cmode,
|
2013-03-26 08:05:14 +00:00
|
|
|
uint8_t tch_mode, int codecs, uint8_t codec0, uint8_t codec1,
|
2013-06-12 07:12:04 +00:00
|
|
|
uint8_t codec2, uint8_t codec3, uint8_t initial_codec,
|
|
|
|
uint8_t handover);
|
2013-02-14 10:21:13 +00:00
|
|
|
|
2016-01-09 12:26:14 +00:00
|
|
|
/*! \brief set ciphering on given logical channels */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
int trx_sched_set_cipher(struct gsm_lchan *lchan, uint8_t chan_nr, bool downlink);
|
2013-02-21 08:27:52 +00:00
|
|
|
|
2018-02-23 12:37:45 +00:00
|
|
|
/* frame structures */
|
|
|
|
struct trx_sched_frame {
|
|
|
|
/*! \brief downlink TRX channel type */
|
|
|
|
enum trx_chan_type dl_chan;
|
|
|
|
/*! \brief downlink block ID */
|
|
|
|
uint8_t dl_bid;
|
|
|
|
/*! \brief uplink TRX channel type */
|
|
|
|
enum trx_chan_type ul_chan;
|
|
|
|
/*! \brief uplink block ID */
|
|
|
|
uint8_t ul_bid;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* multiframe structure */
|
|
|
|
struct trx_sched_multiframe {
|
|
|
|
/*! \brief physical channel config (channel combination) */
|
|
|
|
enum gsm_phys_chan_config pchan;
|
|
|
|
/*! \brief applies to which timeslots? */
|
|
|
|
uint8_t slotmask;
|
|
|
|
/*! \brief repeats how many frames */
|
|
|
|
uint8_t period;
|
|
|
|
/*! \brief pointer to scheduling structure */
|
|
|
|
const struct trx_sched_frame *frames;
|
|
|
|
/*! \brief human-readable name */
|
|
|
|
const char *name;
|
|
|
|
};
|
|
|
|
|
|
|
|
int find_sched_mframe_idx(enum gsm_phys_chan_config pchan, uint8_t tn);
|
|
|
|
|
2018-02-23 12:29:05 +00:00
|
|
|
/*! Determine if given frame number contains SACCH (true) or other (false) burst */
|
2022-04-26 20:34:51 +00:00
|
|
|
bool trx_sched_is_sacch_fn(const struct gsm_bts_trx_ts *ts, uint32_t fn, bool uplink);
|
2018-02-23 12:37:45 +00:00
|
|
|
extern const struct trx_sched_multiframe trx_sched_multiframes[];
|
2018-02-23 12:29:05 +00:00
|
|
|
|
osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 support
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
2019-07-03 18:08:48 +00:00
|
|
|
#define TRX_BI_F_NOPE_IND (1 << 0)
|
|
|
|
#define TRX_BI_F_MOD_TYPE (1 << 1)
|
|
|
|
#define TRX_BI_F_TS_INFO (1 << 2)
|
|
|
|
#define TRX_BI_F_CI_CB (1 << 3)
|
2021-04-17 04:48:13 +00:00
|
|
|
#define TRX_BI_F_TRX_NUM (1 << 4)
|
|
|
|
#define TRX_BI_F_BATCH_IND (1 << 5)
|
2021-05-27 19:51:44 +00:00
|
|
|
#define TRX_BI_F_SHADOW_IND (1 << 6)
|
2022-10-03 15:26:00 +00:00
|
|
|
#define TRX_BI_F_ACCESS_BURST (1 << 7)
|
osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 support
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
2019-07-03 18:08:48 +00:00
|
|
|
|
osmo-bts-trx/trx_if.c: introduce TRXD header version handling
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
2019-06-25 11:23:14 +00:00
|
|
|
/*! UL burst indication with the corresponding meta info */
|
|
|
|
struct trx_ul_burst_ind {
|
osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 support
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
2019-07-03 18:08:48 +00:00
|
|
|
/* Field presence bitmask (see TRX_BI_F_*) */
|
|
|
|
uint8_t flags;
|
|
|
|
|
osmo-bts-trx/trx_if.c: introduce TRXD header version handling
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
2019-06-25 11:23:14 +00:00
|
|
|
/* Mandatory fields */
|
|
|
|
uint32_t fn; /*!< TDMA frame number */
|
|
|
|
uint8_t tn; /*!< TDMA time-slot number */
|
|
|
|
int16_t toa256; /*!< Timing of Arrival in units of 1/256 of symbol */
|
|
|
|
int8_t rssi; /*!< Received Signal Strength Indication */
|
|
|
|
|
osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 support
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
2019-07-03 18:08:48 +00:00
|
|
|
/* Optional fields (defined by flags) */
|
2021-04-15 03:54:07 +00:00
|
|
|
enum trx_mod_type mod; /*!< Modulation type */
|
osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 support
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
2019-07-03 18:08:48 +00:00
|
|
|
uint8_t tsc_set; /*!< Training Sequence Set */
|
|
|
|
uint8_t tsc; /*!< Training Sequence Code */
|
|
|
|
int16_t ci_cb; /*!< Carrier-to-Interference ratio (in centiBels) */
|
2021-04-17 04:48:13 +00:00
|
|
|
uint8_t trx_num; /*!< TRX (RF channel) number */
|
|
|
|
|
|
|
|
/* Used internally by the PDU parser */
|
|
|
|
uint8_t _num_pdus; /*!< Number of processed PDUs */
|
osmo-bts-trx/trx_if.c: introduce TRXD header version 0x01 support
The new version adds the following fields to the TRX2L1 message,
keeping the L12TRX message unchanged:
+------+-----+-----+-----+--------------------+
| RSSI | ToA | MTS | C/I | soft-bits (254..0) |
+------+-----+-----+-----+--------------------+
- MTS (1 octet) - Modulation and Training Sequence info, and
- C/I (2 octets) - Carrier-to-Interference ratio (big endian).
== Coding of MTS: Modulation and Training Sequence info
3GPP TS 45.002 version 15.1.0 defines several modulation types,
and a few sets of training sequences for each type. The most
common are GMSK and 8-PSK (which is used in EDGE).
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . . . . . X X X | Training Sequence Code (0..7) |
+-----------------+---------------------------------------+
| . X X X X . . . | Modulation, TS set number (see below) |
+-----------------+---------------------------------------+
| X . . . . . . . | IDLE / nope frame indication (0 or 1) |
+-----------------+---------------------------------------+
The bit number 7 (MSB) is set to high when either nothing has been
detected, or during IDLE frames, so we can deliver noise levels,
and avoid clock gaps on the L1 side. Other bits are ignored,
and should be set to low (0) in this case.
== Coding of modulation and TS set number
GMSK has 4 sets of training sequences (see tables 5.2.3a-d),
while 8-PSK (see tables 5.2.3f-g) and the others have 2 sets.
Access and Synchronization bursts also have several synch.
sequences.
+-----------------+---------------------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------------------+
| . 0 0 X X . . . | GMSK, 4 TS sets (0..3) |
+-----------------+---------------------------------------+
| . 0 1 0 X . . . | 8-PSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 0 1 1 X . . . | AQPSK, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 0 X . . . | 16QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 0 1 X . . . | 32QAM, 2 TS sets (0..1) |
+-----------------+---------------------------------------+
| . 1 1 1 X . . . | RESERVED (0) |
+-----------------+---------------------------------------+
== C/I: Carrier-to-Interference ratio
The C/I value is computed from the training sequence of each burst,
where we can compare the "ideal" training sequence with the actual
training sequence, and then express that difference in centiBels.
== Limitations
- The only supported modulation types are GMSK and 8-PSK.
Messages with other modulation types will be rejected.
- IDLE / NOPE indications are not (yet) handled.
- The logical channel handlers do not (yet) handle optional
fields, such as TSC and C/I. This will be implemented
in the follow-up changes.
Change-Id: If61c71d20d590bf07bfd019afb33000a0b6135bd
Related: OS#4006
2019-07-03 18:08:48 +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
|
|
|
/* Internally used by the scheduler */
|
|
|
|
enum trx_chan_type chan;
|
|
|
|
uint8_t bid;
|
|
|
|
|
osmo-bts-trx/trx_if.c: introduce TRXD header version handling
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
2019-06-25 11:23:14 +00:00
|
|
|
/*! Burst soft-bits buffer */
|
|
|
|
sbit_t burst[EGPRS_BURST_LEN];
|
|
|
|
size_t burst_len;
|
|
|
|
};
|
|
|
|
|
2021-08-29 13:32:51 +00:00
|
|
|
#define TRX_BR_F_FACCH (1 << 0)
|
|
|
|
|
2020-06-13 14:45:33 +00:00
|
|
|
/*! DL burst request with the corresponding meta info */
|
|
|
|
struct trx_dl_burst_req {
|
2021-04-17 04:48:13 +00:00
|
|
|
uint8_t flags; /*!< see TRX_BR_F_* */
|
|
|
|
|
|
|
|
/* Mandatory fields */
|
2020-06-13 14:45:33 +00:00
|
|
|
uint32_t fn; /*!< TDMA frame number */
|
|
|
|
uint8_t tn; /*!< TDMA timeslot number */
|
|
|
|
uint8_t att; /*!< Tx power attenuation */
|
2021-04-17 04:48:13 +00:00
|
|
|
int8_t scpir; /*!< SCPIR (for AQPSK only) */
|
|
|
|
uint8_t trx_num; /*!< TRX (RF channel) number */
|
2020-06-13 14:45:33 +00:00
|
|
|
|
2021-05-19 00:50:30 +00:00
|
|
|
enum trx_mod_type mod; /*!< Modulation type */
|
|
|
|
uint8_t tsc_set; /*!< Training Sequence Set */
|
|
|
|
uint8_t tsc; /*!< Training Sequence Code */
|
|
|
|
|
[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
|
|
|
/* Internally used by the scheduler */
|
|
|
|
enum trx_chan_type chan;
|
|
|
|
uint8_t bid;
|
|
|
|
|
2020-06-13 14:45:33 +00:00
|
|
|
/*! Burst hard-bits buffer */
|
|
|
|
ubit_t burst[EGPRS_BURST_LEN];
|
|
|
|
size_t burst_len;
|
|
|
|
};
|
|
|
|
|
osmo-bts-trx/trx_if.c: introduce TRXD header version handling
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
2019-06-25 11:23:14 +00:00
|
|
|
/*! Handle an UL burst received by PHY */
|
[VAMOS] Re-organize osmo-bts-trx specific structures
Together with the 'generic' structures which used to be shared between
osmo-bsc and osmo-bts some time ago, we also have the following
osmo-bts-trx specific structures (in hierarchical order):
- struct l1sched_trx (struct gsm_bts_trx),
- struct l1sched_ts (struct gsm_bts_trx_ts),
- struct l1sched_chan_state (struct gsm_lchan).
These structures are not integrated into the tree of the generic
structures, but maintained in a _separate tree_ instead. Until
recently, only the 'l1sched_trx' had a pointer to generic
'gsm_bts_trx', so in order to find the corresponding 'gsm_lchan' for
'l1sched_chan_state' one would need to traverse all the way up to
'l1sched_trx' and then tracerse another three backwards.
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ l1sched_trx --------------------> gsm_bts_trx (0..255)
| |
--+ l1sched_trx_ts --+ gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
I find this architecture a bit over-complicated, especially given
that 'l1sched_trx' is kind of a dummy node containing nothing else
than a pointer to 'gsm_bts_trx' and the list of 'l1sched_trx_ts'.
In this path I slightly change the architecture as follows:
+ gsm_network
|
--+ gsm_bts (0..255)
|
--+ gsm_bts_trx (0..255)
|
--+ l1sched_trx_ts <----------------> gsm_bts_trx_ts (8)
| |
--+ l1sched_chan_state --+ gsm_lchan (up to 8)
Note that unfortunately we cannot 1:1 map 'l1sched_chan_state' to
'gsm_lchan' (like we do for 'l1sched_trx_ts' and 'gsm_bts_trx_ts')
because there is no direct mapping. The former is a higl-level
representation of a logical channel, while the later represents
one specific logical channel type like FCCH, SDCCH/0 or SACCH/0.
osmo-bts-virtual re-uses the osmo-bts-trx hierarchy, so it's also
affected by this change.
Change-Id: I7c4379e43a25e9d858d582a99bf6c4b65c9af481
2021-05-07 13:47:57 +00:00
|
|
|
int trx_sched_route_burst_ind(const struct gsm_bts_trx *trx, struct trx_ul_burst_ind *bi);
|
|
|
|
int trx_sched_ul_burst(struct l1sched_ts *l1ts, struct trx_ul_burst_ind *bi);
|
osmo-bts-trx/trx_if.c: introduce TRXD header version handling
It may be necessary to extend the message specific header with
more information. Since this is not a TLV-based protocol, we
need to include the header format version.
+-----------------+---------------------------+
| 7 6 5 4 3 2 1 0 | bit numbers (value range) |
+-----------------+---------------------------+
| X X X X . . . . | header version (0..15) |
+-----------------+---------------------------+
| . . . . . X X X | TDMA TN (0..7) |
+-----------------+---------------------------+
| . . . . X . . . | RESERVED (0) |
+-----------------+---------------------------+
Instead of prepending an additional byte, it was decided to use
4 MSB bits of the first octet, which used to be zero-initialized
due to the value range of TDMA TN (0..7). Therefore the current
header format has implicit version 0.
Otherwise Wireshark (or trx_sniff.py) would have to guess the
header version, or alternatively follow the control channel
looking for the version setting command.
This change introduces a new structure 'trx_ul_burst_ind', which
represents an Uplink burst and the corresponding meta info. The
purpose of this structure is to avoid overloading the existing
functions, such as trx_sched_ul_burst(), with more and more
arguments every time we bump the version.
On receipt of a TRXD message, trx_data_read_cb() now parses
the header version, and calls the corresponding dissector
functions, e.g. trx_data_handle_(hdr|burst)_v0().
Change-Id: I171c18229ca3e5cab70de0064a31e47c78602c0c
Related: OS#4006
2019-06-25 11:23:14 +00:00
|
|
|
|
2020-06-22 22:44:48 +00:00
|
|
|
/* Averaging mode for trx_sched_meas_avg() */
|
|
|
|
enum sched_meas_avg_mode {
|
2023-05-15 09:37:49 +00:00
|
|
|
/* first 22 of last 24 bursts (for TCH/F14.4, TCH/F9.6, TCH/F4.8) */
|
|
|
|
SCHED_MEAS_AVG_M_S24N22,
|
|
|
|
/* last 22 bursts (for TCH/H4.8, TCH/H2.4) */
|
|
|
|
SCHED_MEAS_AVG_M_S22N22,
|
osmo-bts-trx: rx_tchh_fn(): use proper meas averaging mode
Compared to TCH/F, TCH/H is a bit special in a way that:
* speech frames are interleaved over 4 consecutive bursts,
* while FACCH frames are interleaved over 6 consecutive bursts.
This is why in rx_tchh_fn() we allocate a buffer large enough to
store up to 6 bursts. Let's say we have that buffer filled up
completely with all 6 bursts (from 'a' to 'f'). Now attempting
to decode them may yield either a speech frame or a FACCH frame:
+---+---+---+---+---+---+
| a | b | c | d | e | f | Burst 'a' received first, 'f' last
+---+---+---+---+---+---+
^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd')
^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f')
For FACCH we use measurement averaging mode SCHED_MEAS_AVG_M_S6N6,
so that 6 last samples are averaged - so far so good. For speech
we use SCHED_MEAS_AVG_M_S4N4, so that 4 last samples corresponding
to bursts 'c', 'd', 'e', 'f' are averaged - this is wrong.
We actually need to average the *first* 4 samples corresponding to
bursts 'a', 'b', 'c', 'd' in the case of speech. Let's add and use
a new averaging mode SCHED_MEAS_AVG_M_S6N4 for that.
Change-Id: Iea6f4e5471550f4c2b57aaebeac83c80e879489d
2022-03-17 15:46:46 +00:00
|
|
|
/* last 4 bursts (default for xCCH, PTCCH and PDTCH) */
|
2022-03-17 15:36:36 +00:00
|
|
|
SCHED_MEAS_AVG_M_S4N4,
|
2020-06-22 22:44:48 +00:00
|
|
|
/* last 8 bursts (default for TCH/F and FACCH/F) */
|
2022-03-17 15:36:36 +00:00
|
|
|
SCHED_MEAS_AVG_M_S8N8,
|
osmo-bts-trx: rx_tchh_fn(): use proper meas averaging mode
Compared to TCH/F, TCH/H is a bit special in a way that:
* speech frames are interleaved over 4 consecutive bursts,
* while FACCH frames are interleaved over 6 consecutive bursts.
This is why in rx_tchh_fn() we allocate a buffer large enough to
store up to 6 bursts. Let's say we have that buffer filled up
completely with all 6 bursts (from 'a' to 'f'). Now attempting
to decode them may yield either a speech frame or a FACCH frame:
+---+---+---+---+---+---+
| a | b | c | d | e | f | Burst 'a' received first, 'f' last
+---+---+---+---+---+---+
^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd')
^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f')
For FACCH we use measurement averaging mode SCHED_MEAS_AVG_M_S6N6,
so that 6 last samples are averaged - so far so good. For speech
we use SCHED_MEAS_AVG_M_S4N4, so that 4 last samples corresponding
to bursts 'c', 'd', 'e', 'f' are averaged - this is wrong.
We actually need to average the *first* 4 samples corresponding to
bursts 'a', 'b', 'c', 'd' in the case of speech. Let's add and use
a new averaging mode SCHED_MEAS_AVG_M_S6N4 for that.
Change-Id: Iea6f4e5471550f4c2b57aaebeac83c80e879489d
2022-03-17 15:46:46 +00:00
|
|
|
/* first 4 of last 6 bursts (default for TCH/H) */
|
|
|
|
SCHED_MEAS_AVG_M_S6N4,
|
2020-06-22 22:44:48 +00:00
|
|
|
/* last 6 bursts (default for FACCH/H) */
|
2022-03-17 15:36:36 +00:00
|
|
|
SCHED_MEAS_AVG_M_S6N6,
|
2020-06-22 23:11:20 +00:00
|
|
|
/* first 4 of last 8 bursts */
|
2022-03-17 15:36:36 +00:00
|
|
|
SCHED_MEAS_AVG_M_S8N4,
|
2020-06-22 23:11:20 +00:00
|
|
|
/* first 2 of last 6 bursts */
|
2022-03-17 15:36:36 +00:00
|
|
|
SCHED_MEAS_AVG_M_S6N2,
|
2020-06-22 23:11:20 +00:00
|
|
|
/* middle 2 of last 6 bursts */
|
2022-03-17 15:36:36 +00:00
|
|
|
SCHED_MEAS_AVG_M_S4N2,
|
2020-06-22 22:44:48 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
void trx_sched_meas_push(struct l1sched_chan_state *chan_state,
|
|
|
|
const struct trx_ul_burst_ind *bi);
|
|
|
|
void trx_sched_meas_avg(const struct l1sched_chan_state *chan_state,
|
|
|
|
struct l1sched_meas_set *avg,
|
|
|
|
enum sched_meas_avg_mode mode);
|
2022-03-20 00:22:14 +00:00
|
|
|
uint32_t trx_sched_lookup_fn(const struct l1sched_chan_state *chan_state,
|
|
|
|
const unsigned int shift);
|