2017-12-17 19:13:41 +00:00
|
|
|
/*
|
|
|
|
* OsmocomBB <-> SDR connection bridge
|
|
|
|
* TDMA scheduler: primitive management
|
|
|
|
*
|
2022-07-11 20:02:31 +00:00
|
|
|
* (C) 2017-2022 by Vadim Yanitskiy <axilirator@gmail.com>
|
|
|
|
* Contributions by sysmocom - s.f.m.c. GmbH
|
2017-12-17 19:13:41 +00:00
|
|
|
*
|
|
|
|
* All Rights Reserved
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 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.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <errno.h>
|
2018-03-10 21:18:06 +00:00
|
|
|
#include <stdlib.h>
|
2017-12-17 19:13:41 +00:00
|
|
|
#include <string.h>
|
|
|
|
#include <talloc.h>
|
|
|
|
|
|
|
|
#include <osmocom/core/msgb.h>
|
|
|
|
#include <osmocom/core/logging.h>
|
|
|
|
#include <osmocom/core/linuxlist.h>
|
|
|
|
|
|
|
|
#include <osmocom/gsm/protocol/gsm_04_08.h>
|
|
|
|
|
2022-07-22 12:54:14 +00:00
|
|
|
#include <osmocom/bb/l1sched/l1sched.h>
|
2022-07-01 10:45:12 +00:00
|
|
|
#include <osmocom/bb/trxcon/logging.h>
|
2017-12-17 19:13:41 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Initializes a new primitive by allocating memory
|
|
|
|
* and filling some meta-information (e.g. lchan type).
|
|
|
|
*
|
2018-09-27 22:28:36 +00:00
|
|
|
* @param ctx parent talloc context
|
2017-12-17 19:13:41 +00:00
|
|
|
* @param pl_len prim payload length
|
2022-07-09 15:33:59 +00:00
|
|
|
* @param type prim payload type
|
2017-12-17 19:13:41 +00:00
|
|
|
* @param chan_nr RSL channel description (used to set a proper chan)
|
|
|
|
* @param link_id RSL link description (used to set a proper chan)
|
2022-07-11 20:02:31 +00:00
|
|
|
* @return allocated primitive or NULL
|
2017-12-17 19:13:41 +00:00
|
|
|
*/
|
2022-07-09 14:41:53 +00:00
|
|
|
static struct l1sched_ts_prim *prim_alloc(void *ctx, size_t pl_len,
|
2022-07-09 15:33:59 +00:00
|
|
|
enum l1sched_ts_prim_type type,
|
2022-07-09 14:41:53 +00:00
|
|
|
uint8_t chan_nr, uint8_t link_id)
|
2017-12-17 19:13:41 +00:00
|
|
|
{
|
2022-07-02 12:00:53 +00:00
|
|
|
enum l1sched_lchan_type lchan_type;
|
2022-07-11 20:02:31 +00:00
|
|
|
struct l1sched_ts_prim *prim;
|
2017-12-17 19:13:41 +00:00
|
|
|
|
|
|
|
/* Determine lchan type */
|
2022-07-01 18:42:26 +00:00
|
|
|
lchan_type = l1sched_chan_nr2lchan_type(chan_nr, link_id);
|
2017-12-17 19:13:41 +00:00
|
|
|
if (!lchan_type) {
|
|
|
|
LOGP(DSCH, LOGL_ERROR, "Couldn't determine lchan type "
|
|
|
|
"for chan_nr=%02x and link_id=%02x\n", chan_nr, link_id);
|
2022-07-11 20:02:31 +00:00
|
|
|
return NULL;
|
2017-12-17 19:13:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate a new primitive */
|
2022-07-09 10:32:50 +00:00
|
|
|
prim = talloc_zero_size(ctx, sizeof(*prim) + pl_len);
|
2022-07-11 20:02:31 +00:00
|
|
|
if (prim == NULL) {
|
2017-12-17 19:13:41 +00:00
|
|
|
LOGP(DSCH, LOGL_ERROR, "Failed to allocate memory\n");
|
2022-07-11 20:02:31 +00:00
|
|
|
return NULL;
|
2017-12-17 19:13:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Init primitive header */
|
2022-07-11 20:02:31 +00:00
|
|
|
prim->payload_len = pl_len;
|
|
|
|
prim->chan = lchan_type;
|
2022-07-09 15:33:59 +00:00
|
|
|
prim->type = type;
|
2017-12-17 19:13:41 +00:00
|
|
|
|
2022-07-11 20:02:31 +00:00
|
|
|
return prim;
|
2017-12-17 19:13:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Adds a primitive to the end of transmit queue of a particular
|
|
|
|
* timeslot, whose index is parsed from chan_nr.
|
|
|
|
*
|
2022-07-06 11:06:07 +00:00
|
|
|
* @param sched scheduler instance
|
2017-12-17 19:13:41 +00:00
|
|
|
* @param chan_nr RSL channel description
|
2022-07-09 14:41:53 +00:00
|
|
|
* @param link_id RSL link description
|
|
|
|
* @param pl Payload data
|
|
|
|
* @param pl_len Payload length
|
|
|
|
* @return queued primitive or NULL
|
2017-12-17 19:13:41 +00:00
|
|
|
*/
|
2022-07-06 11:06:07 +00:00
|
|
|
struct l1sched_ts_prim *l1sched_prim_push(struct l1sched_state *sched,
|
2022-07-09 15:33:59 +00:00
|
|
|
enum l1sched_ts_prim_type type,
|
2022-07-09 14:41:53 +00:00
|
|
|
uint8_t chan_nr, uint8_t link_id,
|
|
|
|
const uint8_t *pl, size_t pl_len)
|
2017-12-17 19:13:41 +00:00
|
|
|
{
|
2022-07-09 14:41:53 +00:00
|
|
|
struct l1sched_ts_prim *prim;
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts *ts;
|
2017-12-17 19:13:41 +00:00
|
|
|
uint8_t tn;
|
|
|
|
|
|
|
|
/* Determine TS index */
|
|
|
|
tn = chan_nr & 0x7;
|
|
|
|
|
|
|
|
/* Check whether required timeslot is allocated and configured */
|
2022-07-15 21:33:03 +00:00
|
|
|
ts = sched->ts[tn];
|
2017-12-17 19:13:41 +00:00
|
|
|
if (ts == NULL || ts->mf_layout == NULL) {
|
|
|
|
LOGP(DSCH, LOGL_ERROR, "Timeslot %u isn't configured\n", tn);
|
2022-07-09 14:41:53 +00:00
|
|
|
return NULL;
|
2017-12-17 19:13:41 +00:00
|
|
|
}
|
|
|
|
|
2022-07-09 15:33:59 +00:00
|
|
|
prim = prim_alloc(ts, pl_len, type, chan_nr, link_id);
|
2022-07-09 14:41:53 +00:00
|
|
|
if (prim == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
memcpy(&prim->payload[0], pl, pl_len);
|
2017-12-17 19:13:41 +00:00
|
|
|
|
|
|
|
/* Add primitive to TS transmit queue */
|
|
|
|
llist_add_tail(&prim->list, &ts->tx_prims);
|
|
|
|
|
2022-07-09 14:41:53 +00:00
|
|
|
return prim;
|
2017-12-17 19:13:41 +00:00
|
|
|
}
|
|
|
|
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
/**
|
|
|
|
* Composes a new primitive using either cached (if populated),
|
|
|
|
* or "dummy" Measurement Report message.
|
|
|
|
*
|
|
|
|
* @param lchan lchan to assign a primitive
|
|
|
|
* @return SACCH primitive to be transmitted
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
static struct l1sched_ts_prim *prim_compose_mr(struct l1sched_lchan_state *lchan)
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
{
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *prim;
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
uint8_t *mr_src_ptr;
|
|
|
|
bool cached;
|
|
|
|
|
|
|
|
/* "Dummy" Measurement Report */
|
|
|
|
static const uint8_t meas_rep_dummy[] = {
|
|
|
|
/* L1 SACCH pseudo-header */
|
|
|
|
0x0f, 0x00,
|
|
|
|
|
|
|
|
/* LAPDm header */
|
|
|
|
0x01, 0x03, 0x49,
|
|
|
|
|
2020-11-30 15:00:13 +00:00
|
|
|
/* RR Management messages, Measurement Report */
|
|
|
|
0x06, 0x15,
|
|
|
|
|
|
|
|
/* Measurement results (see 3GPP TS 44.018, section 10.5.2.20):
|
|
|
|
* 0... .... = BA-USED: 0
|
|
|
|
* .0.. .... = DTX-USED: DTX was not used
|
|
|
|
* ..11 0110 = RXLEV-FULL-SERVING-CELL: -57 <= x < -56 dBm (54)
|
|
|
|
* 0... .... = 3G-BA-USED: 0
|
2020-11-30 15:01:25 +00:00
|
|
|
* .1.. .... = MEAS-VALID: The measurement results are not valid
|
2020-11-30 15:00:13 +00:00
|
|
|
* ..11 0110 = RXLEV-SUB-SERVING-CELL: -57 <= x < -56 dBm (54)
|
|
|
|
* 0... .... = SI23_BA_USED: 0
|
|
|
|
* .000 .... = RXQUAL-FULL-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0)
|
|
|
|
* .... 000. = RXQUAL-SUB-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0)
|
|
|
|
* .... ...1 11.. .... = NO-NCELL-M: Neighbour cell information not available */
|
2020-11-30 15:01:25 +00:00
|
|
|
0x36, 0x76, 0x01, 0xc0,
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
|
2020-11-30 13:33:04 +00:00
|
|
|
/* 0** -- Padding with zeroes */
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
|
|
|
0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Allocate a new primitive */
|
2022-07-09 15:33:59 +00:00
|
|
|
prim = prim_alloc(lchan, GSM_MACBLOCK_LEN, L1SCHED_PRIM_DATA,
|
2022-07-09 14:41:53 +00:00
|
|
|
l1sched_lchan_desc[lchan->type].chan_nr,
|
|
|
|
L1SCHED_CH_LID_SACCH);
|
2022-07-11 20:02:31 +00:00
|
|
|
OSMO_ASSERT(prim != NULL);
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
|
|
|
|
/* Check if the MR cache is populated (verify LAPDm header) */
|
|
|
|
cached = (lchan->sacch.mr_cache[2] != 0x00
|
|
|
|
&& lchan->sacch.mr_cache[3] != 0x00
|
|
|
|
&& lchan->sacch.mr_cache[4] != 0x00);
|
|
|
|
if (cached) { /* Use the cached one */
|
|
|
|
mr_src_ptr = lchan->sacch.mr_cache;
|
|
|
|
lchan->sacch.mr_cache_usage++;
|
|
|
|
} else { /* Use "dummy" one */
|
|
|
|
mr_src_ptr = (uint8_t *) meas_rep_dummy;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Compose a new Measurement Report primitive */
|
|
|
|
memcpy(prim->payload, mr_src_ptr, GSM_MACBLOCK_LEN);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Update the L1 SACCH pseudo-header (only for cached MRs)
|
|
|
|
*
|
|
|
|
* TODO: filling of the actual values into cached Measurement
|
|
|
|
* Reports would break the distance spoofing feature. If it
|
|
|
|
* were known whether the spoofing is enabled or not, we could
|
|
|
|
* decide whether to update the cached L1 SACCH header here.
|
|
|
|
*/
|
|
|
|
if (!cached) {
|
2022-07-06 11:06:07 +00:00
|
|
|
#warning "FIXME: no direct access to trx->{tx_power,ta}"
|
|
|
|
#if 0
|
|
|
|
prim->payload[0] = lchan->ts->sched->trx->tx_power;
|
|
|
|
prim->payload[1] = lchan->ts->sched->trx->ta;
|
|
|
|
#endif
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Inform about the cache usage count */
|
|
|
|
if (cached && lchan->sacch.mr_cache_usage > 5) {
|
|
|
|
LOGP(DSCHD, LOGL_NOTICE, "SACCH MR cache usage count=%u > 5 "
|
|
|
|
"on lchan=%s => ancient measurements, please fix!\n",
|
|
|
|
lchan->sacch.mr_cache_usage,
|
2022-07-01 18:42:26 +00:00
|
|
|
l1sched_lchan_desc[lchan->type].name);
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
LOGP(DSCHD, LOGL_NOTICE, "Using a %s Measurement Report "
|
|
|
|
"on lchan=%s\n", (cached ? "cached" : "dummy"),
|
2022-07-01 18:42:26 +00:00
|
|
|
l1sched_lchan_desc[lchan->type].name);
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
|
|
|
|
return prim;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Dequeues a SACCH primitive from transmit queue, if present.
|
|
|
|
* Otherwise dequeues a cached Measurement Report (the last
|
|
|
|
* received one). Finally, if the cache is empty, a "dummy"
|
|
|
|
* measurement report is used.
|
|
|
|
*
|
|
|
|
* According to 3GPP TS 04.08, section 3.4.1, SACCH channel
|
|
|
|
* accompanies either a traffic or a signaling channel. It
|
|
|
|
* has the particularity that continuous transmission must
|
|
|
|
* occur in both directions, so on the Uplink direction
|
|
|
|
* measurement result messages are sent at each possible
|
|
|
|
* occasion when nothing else has to be sent. The LAPDm
|
|
|
|
* fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
|
|
|
|
* applicable on SACCH channels!
|
|
|
|
*
|
|
|
|
* Unfortunately, 3GPP TS 04.08 doesn't clearly state
|
|
|
|
* which "else messages" besides Measurement Reports
|
|
|
|
* can be send by the MS on SACCH channels. However,
|
|
|
|
* in sub-clause 3.4.1 it's stated that the interval
|
|
|
|
* between two successive measurement result messages
|
|
|
|
* shall not exceed one L2 frame.
|
|
|
|
*
|
|
|
|
* @param queue transmit queue to take a prim from
|
|
|
|
* @param lchan lchan to assign a primitive
|
|
|
|
* @return SACCH primitive to be transmitted
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
static struct l1sched_ts_prim *prim_dequeue_sacch(struct llist_head *queue,
|
|
|
|
struct l1sched_lchan_state *lchan)
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
{
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *prim_nmr = NULL;
|
|
|
|
struct l1sched_ts_prim *prim_mr = NULL;
|
|
|
|
struct l1sched_ts_prim *prim;
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
bool mr_now;
|
|
|
|
|
|
|
|
/* Shall we transmit MR now? */
|
|
|
|
mr_now = !lchan->sacch.mr_tx_last;
|
|
|
|
|
|
|
|
#define PRIM_IS_MR(prim) \
|
|
|
|
(prim->payload[5] == GSM48_PDISC_RR \
|
|
|
|
&& prim->payload[6] == GSM48_MT_RR_MEAS_REP)
|
|
|
|
|
|
|
|
/* Iterate over all primitives in the queue */
|
|
|
|
llist_for_each_entry(prim, queue, list) {
|
|
|
|
/* We are looking for particular channel */
|
|
|
|
if (prim->chan != lchan->type)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Look for a Measurement Report */
|
|
|
|
if (!prim_mr && PRIM_IS_MR(prim))
|
|
|
|
prim_mr = prim;
|
|
|
|
|
|
|
|
/* Look for anything else */
|
|
|
|
if (!prim_nmr && !PRIM_IS_MR(prim))
|
|
|
|
prim_nmr = prim;
|
|
|
|
|
|
|
|
/* Should we look further? */
|
|
|
|
if (mr_now && prim_mr)
|
|
|
|
break; /* MR was found */
|
|
|
|
else if (!mr_now && prim_nmr)
|
|
|
|
break; /* something else was found */
|
|
|
|
}
|
|
|
|
|
|
|
|
LOGP(DSCHD, LOGL_DEBUG, "SACCH MR selection on lchan=%s: "
|
|
|
|
"mr_tx_last=%d prim_mr=%p prim_nmr=%p\n",
|
2022-07-01 18:42:26 +00:00
|
|
|
l1sched_lchan_desc[lchan->type].name,
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
lchan->sacch.mr_tx_last,
|
|
|
|
prim_mr, prim_nmr);
|
|
|
|
|
|
|
|
/* Prioritize non-MR prim if possible */
|
|
|
|
if (mr_now && prim_mr)
|
|
|
|
prim = prim_mr;
|
|
|
|
else if (!mr_now && prim_nmr)
|
|
|
|
prim = prim_nmr;
|
|
|
|
else if (!mr_now && prim_mr)
|
|
|
|
prim = prim_mr;
|
|
|
|
else /* Nothing was found */
|
|
|
|
prim = NULL;
|
|
|
|
|
|
|
|
/* Have we found what we were looking for? */
|
|
|
|
if (prim) /* Dequeue if so */
|
|
|
|
llist_del(&prim->list);
|
|
|
|
else /* Otherwise compose a new MR */
|
|
|
|
prim = prim_compose_mr(lchan);
|
|
|
|
|
|
|
|
/* Update the cached report */
|
|
|
|
if (prim == prim_mr) {
|
|
|
|
memcpy(lchan->sacch.mr_cache,
|
|
|
|
prim->payload, GSM_MACBLOCK_LEN);
|
|
|
|
lchan->sacch.mr_cache_usage = 0;
|
|
|
|
|
|
|
|
LOGP(DSCHD, LOGL_DEBUG, "SACCH MR cache has been updated "
|
2022-07-01 18:42:26 +00:00
|
|
|
"for lchan=%s\n", l1sched_lchan_desc[lchan->type].name);
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Update the MR transmission state */
|
|
|
|
lchan->sacch.mr_tx_last = PRIM_IS_MR(prim);
|
|
|
|
|
2019-06-01 20:36:19 +00:00
|
|
|
LOGP(DSCHD, LOGL_DEBUG, "SACCH decision on lchan=%s: %s\n",
|
2022-07-01 18:42:26 +00:00
|
|
|
l1sched_lchan_desc[lchan->type].name, PRIM_IS_MR(prim) ?
|
2019-06-01 20:36:19 +00:00
|
|
|
"Measurement Report" : "data frame");
|
|
|
|
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
return prim;
|
|
|
|
}
|
|
|
|
|
2018-08-13 21:46:48 +00:00
|
|
|
/* Dequeues a primitive of a given channel type */
|
2022-07-01 18:42:26 +00:00
|
|
|
static struct l1sched_ts_prim *prim_dequeue_one(struct llist_head *queue,
|
2022-07-02 12:00:53 +00:00
|
|
|
enum l1sched_lchan_type lchan_type)
|
2018-08-13 21:46:48 +00:00
|
|
|
{
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *prim;
|
2018-08-13 21:46:48 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* There is no need to use the 'safe' list iteration here
|
|
|
|
* as an item removal is immediately followed by return.
|
|
|
|
*/
|
|
|
|
llist_for_each_entry(prim, queue, list) {
|
|
|
|
if (prim->chan == lchan_type) {
|
|
|
|
llist_del(&prim->list);
|
|
|
|
return prim;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2017-12-17 19:13:41 +00:00
|
|
|
/**
|
2018-08-13 21:46:48 +00:00
|
|
|
* Dequeues either a FACCH, or a speech TCH primitive
|
|
|
|
* of a given channel type (Lm or Bm).
|
2017-12-17 19:13:41 +00:00
|
|
|
*
|
2018-08-13 21:46:48 +00:00
|
|
|
* Note: we could avoid 'lchan_type' parameter and just
|
2022-07-01 18:42:26 +00:00
|
|
|
* check the prim's channel type using L1SCHED_CHAN_IS_TCH(),
|
2018-08-13 21:46:48 +00:00
|
|
|
* but the current approach is a bit more flexible,
|
|
|
|
* and allows one to have both sub-slots of TCH/H
|
|
|
|
* enabled on same timeslot e.g. for testing...
|
|
|
|
*
|
|
|
|
* @param queue transmit queue to take a prim from
|
|
|
|
* @param lchan_type required channel type of a primitive,
|
2022-07-02 12:00:53 +00:00
|
|
|
* e.g. L1SCHED_TCHF, L1SCHED_TCHH_0, or L1SCHED_TCHH_1
|
2018-08-13 21:46:48 +00:00
|
|
|
* @param facch FACCH (true) or speech (false) prim?
|
|
|
|
* @return either a FACCH, or a TCH primitive if found,
|
|
|
|
* otherwise NULL
|
2017-12-17 19:13:41 +00:00
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
static struct l1sched_ts_prim *prim_dequeue_tch(struct llist_head *queue,
|
2022-07-02 12:00:53 +00:00
|
|
|
enum l1sched_lchan_type lchan_type, bool facch)
|
2017-12-17 19:13:41 +00:00
|
|
|
{
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *prim;
|
2017-12-17 21:39:27 +00:00
|
|
|
|
2018-08-13 21:46:48 +00:00
|
|
|
/**
|
|
|
|
* There is no need to use the 'safe' list iteration here
|
|
|
|
* as an item removal is immediately followed by return.
|
|
|
|
*/
|
|
|
|
llist_for_each_entry(prim, queue, list) {
|
|
|
|
if (prim->chan != lchan_type)
|
|
|
|
continue;
|
2017-12-17 21:39:27 +00:00
|
|
|
|
2018-08-13 21:46:48 +00:00
|
|
|
/* Either FACCH, or not FACCH */
|
2022-07-01 18:42:26 +00:00
|
|
|
if (L1SCHED_PRIM_IS_FACCH(prim) != facch)
|
2018-08-13 21:46:48 +00:00
|
|
|
continue;
|
2017-12-17 21:39:27 +00:00
|
|
|
|
2018-08-13 21:46:48 +00:00
|
|
|
llist_del(&prim->list);
|
|
|
|
return prim;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Dequeues either a TCH/F, or a FACCH/F prim (preferred).
|
|
|
|
* If a FACCH/F prim is found, one TCH/F prim is being
|
|
|
|
* dropped (i.e. replaced).
|
|
|
|
*
|
|
|
|
* @param queue a transmit queue to take a prim from
|
|
|
|
* @return either a FACCH/F, or a TCH/F primitive,
|
|
|
|
* otherwise NULL
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
static struct l1sched_ts_prim *prim_dequeue_tch_f(struct llist_head *queue)
|
2018-08-13 21:46:48 +00:00
|
|
|
{
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *facch;
|
|
|
|
struct l1sched_ts_prim *tch;
|
2018-08-13 21:46:48 +00:00
|
|
|
|
|
|
|
/* Attempt to find a pair of both FACCH/F and TCH/F frames */
|
2022-07-02 12:00:53 +00:00
|
|
|
facch = prim_dequeue_tch(queue, L1SCHED_TCHF, true);
|
|
|
|
tch = prim_dequeue_tch(queue, L1SCHED_TCHF, false);
|
2018-08-13 21:46:48 +00:00
|
|
|
|
|
|
|
/* Prioritize FACCH/F, if found */
|
|
|
|
if (facch) {
|
|
|
|
/* One TCH/F prim is replaced */
|
|
|
|
if (tch)
|
|
|
|
talloc_free(tch);
|
2017-12-17 21:39:27 +00:00
|
|
|
return facch;
|
|
|
|
} else if (tch) {
|
2018-08-13 21:46:48 +00:00
|
|
|
/* Only TCH/F prim was found */
|
2017-12-17 21:39:27 +00:00
|
|
|
return tch;
|
2018-08-13 21:46:48 +00:00
|
|
|
} else {
|
|
|
|
/* Nothing was found, e.g. when only SACCH frames are in queue */
|
|
|
|
return NULL;
|
2017-12-17 21:39:27 +00:00
|
|
|
}
|
2017-12-17 19:13:41 +00:00
|
|
|
}
|
|
|
|
|
2018-08-12 21:45:22 +00:00
|
|
|
/**
|
|
|
|
* Dequeues either a TCH/H, or a FACCH/H prim (preferred).
|
|
|
|
* If a FACCH/H prim is found, two TCH/H prims are being
|
|
|
|
* dropped (i.e. replaced).
|
|
|
|
*
|
|
|
|
* According to GSM 05.02, the following blocks can be used
|
|
|
|
* to carry FACCH/H data (see clause 7, table 1 of 9):
|
|
|
|
*
|
|
|
|
* UL FACCH/H0:
|
|
|
|
* B0(0,2,4,6,8,10), B1(8,10,13,15,17,19), B2(17,19,21,23,0,2)
|
|
|
|
*
|
|
|
|
* UL FACCH/H1:
|
|
|
|
* B0(1,3,5,7,9,11), B1(9,11,14,16,18,20), B2(18,20,22,24,1,3)
|
|
|
|
*
|
|
|
|
* where the numbers within brackets are fn % 26.
|
|
|
|
*
|
|
|
|
* @param queue transmit queue to take a prim from
|
|
|
|
* @param fn the current frame number
|
|
|
|
* @param lchan_type required channel type of a primitive,
|
|
|
|
* @return either a FACCH/H, or a TCH/H primitive,
|
|
|
|
* otherwise NULL
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
static struct l1sched_ts_prim *prim_dequeue_tch_h(struct llist_head *queue,
|
2022-07-02 12:00:53 +00:00
|
|
|
uint32_t fn, enum l1sched_lchan_type lchan_type)
|
2018-08-12 21:45:22 +00:00
|
|
|
{
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *facch;
|
|
|
|
struct l1sched_ts_prim *tch;
|
2018-08-14 18:17:10 +00:00
|
|
|
bool facch_now;
|
2018-08-12 21:45:22 +00:00
|
|
|
|
2018-08-14 18:17:10 +00:00
|
|
|
/* May we initiate an UL FACCH/H frame transmission now? */
|
2022-07-01 18:42:26 +00:00
|
|
|
facch_now = l1sched_tchh_facch_start(lchan_type, fn, true);
|
2018-08-12 21:45:22 +00:00
|
|
|
if (!facch_now) /* Just dequeue a TCH/H prim */
|
|
|
|
goto no_facch;
|
|
|
|
|
|
|
|
/* If there are no FACCH/H prims in the queue */
|
|
|
|
facch = prim_dequeue_tch(queue, lchan_type, true);
|
|
|
|
if (!facch) /* Just dequeue a TCH/H prim */
|
|
|
|
goto no_facch;
|
|
|
|
|
|
|
|
/* FACCH/H prim replaces two TCH/F prims */
|
|
|
|
tch = prim_dequeue_tch(queue, lchan_type, false);
|
|
|
|
if (tch) {
|
|
|
|
/* At least one TCH/H prim is dropped */
|
|
|
|
talloc_free(tch);
|
|
|
|
|
|
|
|
/* Attempt to find another */
|
|
|
|
tch = prim_dequeue_tch(queue, lchan_type, false);
|
|
|
|
if (tch) /* Drop the second TCH/H prim */
|
|
|
|
talloc_free(tch);
|
|
|
|
}
|
|
|
|
|
|
|
|
return facch;
|
|
|
|
|
|
|
|
no_facch:
|
|
|
|
return prim_dequeue_tch(queue, lchan_type, false);
|
|
|
|
}
|
|
|
|
|
2017-12-17 20:47:23 +00:00
|
|
|
/**
|
|
|
|
* Dequeues a single primitive of required type
|
|
|
|
* from a specified transmit queue.
|
|
|
|
*
|
|
|
|
* @param queue a transmit queue to take a prim from
|
2018-08-12 21:45:22 +00:00
|
|
|
* @param fn the current frame number (used for FACCH/H)
|
2018-09-27 19:47:54 +00:00
|
|
|
* @param lchan logical channel state
|
2017-12-17 20:47:23 +00:00
|
|
|
* @return a primitive or NULL if not found
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *l1sched_prim_dequeue(struct llist_head *queue,
|
|
|
|
uint32_t fn, struct l1sched_lchan_state *lchan)
|
2017-12-17 20:47:23 +00:00
|
|
|
{
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
/* SACCH is unorthodox, see 3GPP TS 04.08, section 3.4.1 */
|
2022-07-01 18:42:26 +00:00
|
|
|
if (L1SCHED_CHAN_IS_SACCH(lchan->type))
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
return prim_dequeue_sacch(queue, lchan);
|
|
|
|
|
2017-12-17 20:47:23 +00:00
|
|
|
/* There is nothing to dequeue */
|
|
|
|
if (llist_empty(queue))
|
|
|
|
return NULL;
|
|
|
|
|
2018-09-27 19:47:54 +00:00
|
|
|
switch (lchan->type) {
|
2018-08-12 21:45:22 +00:00
|
|
|
/* TCH/F requires FACCH/F prioritization */
|
2022-07-02 12:00:53 +00:00
|
|
|
case L1SCHED_TCHF:
|
2018-08-13 21:46:48 +00:00
|
|
|
return prim_dequeue_tch_f(queue);
|
2017-12-17 20:47:23 +00:00
|
|
|
|
2018-08-12 21:45:22 +00:00
|
|
|
/* FACCH/H prioritization is a bit more complex */
|
2022-07-02 12:00:53 +00:00
|
|
|
case L1SCHED_TCHH_0:
|
|
|
|
case L1SCHED_TCHH_1:
|
2018-09-27 19:47:54 +00:00
|
|
|
return prim_dequeue_tch_h(queue, fn, lchan->type);
|
2018-08-12 21:45:22 +00:00
|
|
|
|
|
|
|
/* Other kinds of logical channels */
|
|
|
|
default:
|
2018-09-27 19:47:54 +00:00
|
|
|
return prim_dequeue_one(queue, lchan->type);
|
2018-08-12 21:45:22 +00:00
|
|
|
}
|
2017-12-17 20:47:23 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Drops the current primitive of specified logical channel
|
|
|
|
*
|
|
|
|
* @param lchan a logical channel to drop prim from
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
void l1sched_prim_drop(struct l1sched_lchan_state *lchan)
|
2017-12-17 20:47:23 +00:00
|
|
|
{
|
|
|
|
/* Forget this primitive */
|
|
|
|
talloc_free(lchan->prim);
|
|
|
|
lchan->prim = NULL;
|
|
|
|
}
|
|
|
|
|
2018-03-10 21:18:06 +00:00
|
|
|
/**
|
|
|
|
* Assigns a dummy primitive to a lchan depending on its type.
|
|
|
|
* Could be used when there is nothing to transmit, but
|
|
|
|
* CBTX (Continuous Burst Transmission) is assumed.
|
|
|
|
*
|
|
|
|
* @param lchan lchan to assign a primitive
|
|
|
|
* @return zero in case of success, otherwise a error code
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
int l1sched_prim_dummy(struct l1sched_lchan_state *lchan)
|
2018-03-10 21:18:06 +00:00
|
|
|
{
|
2022-07-02 12:00:53 +00:00
|
|
|
enum l1sched_lchan_type chan = lchan->type;
|
2018-03-10 21:18:06 +00:00
|
|
|
uint8_t tch_mode = lchan->tch_mode;
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *prim;
|
2018-03-10 21:18:06 +00:00
|
|
|
uint8_t prim_buffer[40];
|
|
|
|
size_t prim_len = 0;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* TS 144.006, section 8.4.2.3 "Fill frames"
|
|
|
|
* A fill frame is a UI command frame for SAPI 0, P=0
|
|
|
|
* and with an information field of 0 octet length.
|
|
|
|
*/
|
|
|
|
static const uint8_t lapdm_fill_frame[] = {
|
2018-03-22 13:33:04 +00:00
|
|
|
0x01, 0x03, 0x01, 0x2b,
|
2018-03-10 21:18:06 +00:00
|
|
|
/* Pending part is to be randomized */
|
|
|
|
};
|
|
|
|
|
|
|
|
/* Make sure that there is no existing primitive */
|
|
|
|
OSMO_ASSERT(lchan->prim == NULL);
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
/* Not applicable for SACCH! */
|
2022-07-01 18:42:26 +00:00
|
|
|
OSMO_ASSERT(!L1SCHED_CHAN_IS_SACCH(lchan->type));
|
2018-03-10 21:18:06 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Determine what actually should be generated:
|
|
|
|
* TCH in GSM48_CMODE_SIGN: LAPDm fill frame;
|
|
|
|
* TCH in other modes: silence frame;
|
|
|
|
* other channels: LAPDm fill frame.
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
if (L1SCHED_CHAN_IS_TCH(chan) && L1SCHED_TCH_MODE_IS_SPEECH(tch_mode)) {
|
2018-08-15 00:56:42 +00:00
|
|
|
/* Bad frame indication */
|
2022-07-01 18:42:26 +00:00
|
|
|
prim_len = l1sched_bad_frame_ind(prim_buffer, lchan);
|
|
|
|
} else if (L1SCHED_CHAN_IS_TCH(chan) && L1SCHED_TCH_MODE_IS_DATA(tch_mode)) {
|
2018-03-10 21:18:06 +00:00
|
|
|
/* FIXME: should we do anything for CSD? */
|
|
|
|
return 0;
|
|
|
|
} else {
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
/* Copy LAPDm fill frame's header */
|
|
|
|
memcpy(prim_buffer, lapdm_fill_frame, sizeof(lapdm_fill_frame));
|
2018-03-22 13:33:04 +00:00
|
|
|
|
2018-03-10 21:18:06 +00:00
|
|
|
/**
|
2018-03-22 13:33:04 +00:00
|
|
|
* TS 144.006, section 5.2 "Frame delimitation and fill bits"
|
|
|
|
* Except for the first octet containing fill bits which shall
|
|
|
|
* be set to the binary value "00101011", each fill bit should
|
|
|
|
* be set to a random value when sent by the network.
|
2018-03-10 21:18:06 +00:00
|
|
|
*/
|
trxcon/scheduler: fix Measurement Reporting on SACCH
According to 3GPP TS 04.08, section 3.4.1, SACCH logical channel
accompanies either a traffic or a signaling channel. It has the
particularity that continuous transmission must occur in both
directions, so on the Uplink direction measurement result messages
are sent at each possible occasion when nothing else has to be sent.
The LAPDm fill frames (0x01, 0x03, 0x01, 0x2b, ...) are not
applicable on SACCH channels!
Unfortunately, 3GPP TS 04.08 doesn't clearly state which "else
messages" besides Measurement Reports can be send by the MS on
SACCH channels. However, in sub-clause 3.4.1 it's stated that
the interval between two successive measurement result messages
shall not exceed one L2 frame.
This change introduces a separate handler for SACCH primitives,
which dequeues a SACCH primitive from transmit queue, if present.
Otherwise it dequeues a cached Measurement Report (the last
received one). Finally, if the cache is empty, a "dummy"
measurement report is used. When it's possible,
a non-MR primitive is prioritized.
Change-Id: If1b8dc74ced746d6270676fdde75fcda32f91a3d
Related: OS#2988
2018-03-22 18:40:03 +00:00
|
|
|
for (i = sizeof(lapdm_fill_frame); i < GSM_MACBLOCK_LEN; i++)
|
2018-03-10 21:18:06 +00:00
|
|
|
prim_buffer[i] = (uint8_t) rand();
|
|
|
|
|
|
|
|
/* Define a prim length */
|
|
|
|
prim_len = GSM_MACBLOCK_LEN;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Nothing to allocate / assign */
|
|
|
|
if (!prim_len)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* Allocate a new primitive */
|
2022-07-01 18:42:26 +00:00
|
|
|
prim = talloc_zero_size(lchan, sizeof(struct l1sched_ts_prim) + prim_len);
|
2018-03-10 21:18:06 +00:00
|
|
|
if (prim == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/* Init primitive header */
|
|
|
|
prim->payload_len = prim_len;
|
|
|
|
prim->chan = lchan->type;
|
|
|
|
|
|
|
|
/* Fill in the payload */
|
|
|
|
memcpy(prim->payload, prim_buffer, prim_len);
|
|
|
|
|
|
|
|
/* Assign the current prim */
|
|
|
|
lchan->prim = prim;
|
|
|
|
|
|
|
|
LOGP(DSCHD, LOGL_DEBUG, "Transmitting a dummy / silence frame "
|
2022-07-01 18:42:26 +00:00
|
|
|
"on lchan=%s\n", l1sched_lchan_desc[chan].name);
|
2018-03-10 21:18:06 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-12-17 19:13:41 +00:00
|
|
|
/**
|
|
|
|
* Flushes a queue of primitives
|
|
|
|
*
|
|
|
|
* @param list list of prims going to be flushed
|
|
|
|
*/
|
2022-07-01 18:42:26 +00:00
|
|
|
void l1sched_prim_flush_queue(struct llist_head *list)
|
2017-12-17 19:13:41 +00:00
|
|
|
{
|
2022-07-01 18:42:26 +00:00
|
|
|
struct l1sched_ts_prim *prim, *prim_next;
|
2017-12-17 19:13:41 +00:00
|
|
|
|
|
|
|
llist_for_each_entry_safe(prim, prim_next, list, list) {
|
|
|
|
llist_del(&prim->list);
|
|
|
|
talloc_free(prim);
|
|
|
|
}
|
|
|
|
}
|