In all Uplink lchan handlers we do memset() the Rx burst buffer on
bid=0 and there is no need to do that again for NOPE.ind.
Change-Id: Ia6803b8606d86bd2d011fe21f7a540d2115aa654
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()"
In speech TCH operation, there will always be times when a speech frame
needs to be transmitted on the downlink, but there is no frame available
to transmit (gap in the incoming RTP stream), or the logic of DTXd says
that no frame shall be transmitted at this FN, but we are not doing
physical DTXd. Previous osmo-bts-trx code sent dummy FACCH during such
conditions, but this approach is bad for TCH/HS where we would like to
transmit good speech frames or speech frame gaps one 20 ms frame at a
time, rather than take out pairs of frames for dummy FACCH/H. Other
BTS models (sysmoBTS PHY) send out invalid speech blocks with inverted
CRC3 under the conditions in question - do the same in osmo-bts-trx.
The present change modifies osmo-bts-trx TCH DL frame gap behavior
only for TCH/FS, TCH/HS and TCH/EFS; for all other channel modes,
including AMR speech, the previous behavior of sending dummy FACCH
is left unchanged.
Depends: Iade3310e16b906efb6892d28f474a0d15204e861 (libosmocore)
Change-Id: I78106802a0aa4af39859c75d29fe0e77037899fe
There is no more need to access the UL/DL buffers via pointer to pointer
thanks to the previous patch [1] moving the memory management routines
out of the logical channel specific Rx/Tx handlers.
Change-Id: Ib1e8e86ac60a7ac9b0415ef66b609eaa33443c19
Related: [1] c45e03726af8a2b46b7166b3c47bc666ba933a69
It's a lot cleaner if the Rx/Tx burst buffers are allocated and free()d
in one place rather than in each lchan handler individually. Allocate
the buffer(s) during the lchan activation, free() on deactivation.
Regardless of lchan type, allocate the maximim size of 4 * (3 * 2 * 58)
bytes, which is sufficient to store 4 8PSK modulated bursts. This way
we reduce the load on the memory allocator at the cost of memory
consumption, what should not be a big problem.
Change-Id: I6a5f76023fc492786076a63016f81285b3576c33
Depends: libosmocore.git I1c38ccc2b64ba9046bb3b1221d99cc55ec493802
Related: OS#1572
As a preliminary step before making the RTP output format from
OsmoBTS configurable with a vty option, we need to make the internal
format consistent across all models. The "natural" output from a
"pure" GSM 05.03 channel decoder is TS 101 318, which is also the
output format of all currently supported proprietary PHYs - adopt
it as our internal format.
Related: OS#5688
Depends: I6e75ca95409b5c368e8e04d0e0aba41e0331d9e6 (libosmocore)
Change-Id: I41bce6226964975cb85aea89e4c0f9e11e4929b8
As detailed in OS#6033, osmo-bts-trx was emitting its own invented
packet formats to signal BFIs (bad frame indications), different
from the vty-configured ("rtp continuous-streaming" or not) BFI
signaling method implemented in l1sap and used by all other BTS models.
In the case of EFR codec, the made-up BFI format previously used by
osmo-bts-trx caused EFR operation to be broken: a spec-compliant EFR
decoder on the receiving end of the RTP stream (a network transcoder
or the MS on the other GSM call leg) would receive and decode garbage
EFR frames of 244 zero bits instead of invoking the spec-defined bad
frame handler, causing bad audio artifacts for the user. The same
situation would also happen for FR1 codec, but the application of
ECU masked this bug: with the ECU invoked in the UL output path,
the BFI emitting code for FR1 never executed.
In the case of AMR and HR1 codecs, the model-specific BFI packet
format of osmo-bts-trx is currently harmless, but:
* The extra code adds unnecessary complexity;
* BFI packet formats are inconsistent between osmo-bts-trx and
other OsmoBTS models;
* BFI format is even inconsistent within osmo-bts-trx itself, as
under certain conditions the common code in l1sap will override
the UL payload from the BTS model and emit its own form of BFI
instead.
Fix all of the above by removing trx model-specific BFI formats
for all codecs, and let l1sap handle all BFIs.
Related: OS#6033
Change-Id: I8f9fb5b8c5b2cad4b92ac693c0040779f811981a
osmo-bts-trx uses the RFC5993 RTP payload format, so when handling the
RTP payload use GSM_HR_BYTES_RTP_RFC5993, instead of GSM_HR_BYTES + 1
Depends: libosmocore.git I125ef9cdab98c073971841c175b1a7dcd927f9c2
Related: OS#5688
Change-Id: I54dd3adab88e2262913f7b1e89340a0246c88a8a
This helps understand the origin/purpose of those 2 bytes and
what's contained in them.
Related: SYS#5987
Change-Id: I607fdf6d627242e010fba35be1b9b0ffde820d08
Currently (without this patch) if tch_dl_dequeue() yields nothing we're
scheduling dummy FACCH/H *regardless* if it's permitted to start at the
given TDMA FN or not. This may result in misaligned FACCH transmission,
so the MS will not able to decode anything and will report BER>0.
With this patch applied we schedule FACCH/H if it's allowed to start
at the current TDMA FN; otherwise send half-filled bursts with even
numbered bits contaning 232 encoded bits of the previous L2 frame
and 232 odd numbered bits all set to 0.
This patch does not guard against sporadic gaps in the Downlink TCH
queue. However when tch_dl_dequeue() constantly yields nothing, e.g.
when we end up with a codec mismatch, then this additional check saves
us from starting misaligned FACCH/H transmission. If we start at a wrong
TDMA offset, then all subsequent FACCH frames will be scheduled at wrong
offsets and thus none of them will be decoded by the MS.
Change-Id: I6f8af140a6ccf3d5fd7b98f6cb5c18e2c5e2f61b
Related: SYS#5919, OS#4823
* dl_ongoing_facch must be set for correct FACCH/H scheduling;
* dl_facch_bursts must be set for FACCH overpower to work.
Change-Id: Ief12eb67ad80de3b71f5226858dc2e0c8ae76948
Related: SYS#5919, OS#4823
If set, chan_state->dl_ongoing_facch indicates that we're sending
the 2 (out of 6) middle bursts of FACCH/H. In this case there is
no room for encoding an additional frame, because both even and
odd numbered bits are occupied by a previously encoded FACCH/H.
Right after calling tch_dl_dequeue():
* do not check the dequeued message against NULL,
* do not compare the message length to GSM_MACBLOCK_LEN,
* immediately free() it and jump to the sending part.
Change-Id: Ib923b8f5cc1063e9fc18acd2bdd003fd09f4b70f
Related: SYS#5919, OS#4823
Unlike SACCH, FACCH has no dedicated slots on the multiframe layout.
It's multiplexed together with TCH (speech or data) frames basically
by replacing (stealing) them. This is common for both TCH/F and
TCH/H, with the only difference that FACCH/H steals two TCH frames
(not just one) due to a longer interleaving period.
Let's implement the multiplexing in the common function, which is
used to dequeue to be transmitted frames - this slightly reduces
code duplication. Use a new name, so that it's clear what it does.
Change-Id: I9822b1a17185d5487f0f6d3ed0203e806c053d7d
Related: SYS#5919, OS#4823
Manual analysis of code didn't end up in finding any issue, so this
seems a false positive (I can really understand gcc failing to do proper
job here, this function has way to many jumps here and there.
"""
/sched_lchan_tchh.c:88:13: error: ‘rc’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
88 | int rc, amr = 0;
| ^~
"""
Change-Id: Ifebaee63a9dad04976ffb4438c32360687ef095a
There is nothing else except the AMR link adaptation loop in these files.
Change-Id: Iff2c0d32da5cd89824197d05f4732ce974c12f28
Related: SYS#5917, OS#4984
This check is redundant because it's guaranteed in rts_tchh_fn()
that FACCH/H is always scheduled at the correct frame offset.
Change-Id: I2f0c26f6007455aa1e3e8b27bc9d173f6b1f8c38
Related: SYS#5916, OS#5518
Since change [1], in rts_tchh_fn() we're using a lookup table for
DL FACCH/H. Let's do the same for UL FACCH/H in rx_tchh_fn().
Change-Id: I7c4e3befdd33bef4d89a04a4c7cb1a2d4078c156
Related: [1] I3dba243e5a1b7c8008ef0178ea18ed885256c50d
Related: SYS#5916, OS#5518
In change [1] I didn't take into account that the TCH/H burst buffer
is 6 bursts wide, and that we're decoding 2 bursts late:
+---+---+---+---+---+---+
| a | b | c | d | e | f | Burst 'a' received first, 'f' last
+---+---+---+---+---+---+
^^^^^^^^^^^^^^^ Speech frame (bursts 'a' .. 'd')
^^^^^^^^^^^^^^^^^^^^^^^ FACCH frame (bursts 'a' .. 'f')
The lookup table for TCH/H was calculated with the assumption that
in rx_tchh_fn() the 'bi->fn' indicates TDMA frame number for burst
'd', but in reality it holds the frame number of burst 'f'.
Change-Id: I4f22cf49fd52ed26f8017f76461059a701c181e1
Fixes: [1] I46def864729c8f9063af201750456771ea5558d5
Related: SYS#5916
It makes no sense to have these tables in the header file, because
they're not used anywhere outside of the respective lchan handlers.
Change-Id: Ibdebfb9b1ef78c960b08240ebdb4c7af92cbed11
Related: SYS#5916
In change [1] I broke measurement reporting for TCH/H in signalling
mode. The problem is that in rx_tchh_fn() we started to invalidate
the Uplink RSSI for FACCH regardless of the channel mode: speech or
signalling. In speech mode, the averaged measurements are carried
over by the two BFIs. In signalling mode we send no BFIs, so:
* let's use the proper averaging mode S6N6 (not S6N4), and
* send the averaged measurements together with the FACCH.
This change fixes BTS_Tests.TC_meas_res_sign_tchh[_toa256].
Change-Id: If98aa1f0f7255f20344460bdd07e2c896dd6e56f
Fixes: [1] I7902b4709bc3f418174e8373f52e87bb31cdc826
Related: SYS#5853
There is no reason not to use 'chan_state->tch_mode' directly in
the 'switch' statement. If a logical channel is in signalling
mode, then both 'chan_state->{rsl,tch}_cmode' are set to
RSL_CMOD_SPD_SIGN and GSM48_CMODE_SIGN, respectively.
Change-Id: I9e5e2c891c80c32fc522b53c9371b71ea32dd54d
Related: SYS#5853
3GPP TS 45.009 defines that Codec Mode Indications shall be sent
with speech frames having specific TDMA frame numbers of their
*first* bursts, which are defined in tables 3.2.1.3-{1,2,3,4}.
Performance-wise it's batter to have these tables implemented as
arrays, rather then using the 'switch' statement. We can simplify
things even further and have TDMA frame numbers corresponding to
the *last* bursts in them. This eliminates the need of doing an
additional last-to-first mapping, so that bi->fn can be used.
Change-Id: I46def864729c8f9063af201750456771ea5558d5
Once we have an Uplink speech or FACCH frame decoded, we need to
hand it over to the upper layers indicating TDMA frame number of
the *first* burst corresponding to the beginning of a block.
Currently we use libosmogsm's gsm0502_fn_remap() API to calculate
the first TDMA frame number from the given last frame number.
This API involves iterating over the pre-calculated offset tables
for different channel and payload types, and thus imposes some
additional CPU cycles. Another downside of the current approach
is that we have to perform such lookups several times for each
decoded L2 frame, e.g. for FACCH on TCH/AHS we do it three times!
In this patch I propose an alternative approach of storing TDMA
frame numbers in the measurement history, together with the
associated samples. This way we can easily get N-th frame number
from there without performing any additional computations, other
than what we already do during the measurement processing.
Change-Id: Id9a2b7b0f1a1ad7cfbbab862faf521e135c90605
The idea of this change is to avoid attempting to decode the burst
buffer unless it's filled up completely. This eliminates expected
decoding errors in the beginning of lchan's lifetime. Moreover
this allows us to be sure that the measurement history is complete,
so that we can abuse it to store TDMA frame numbers later.
Note that even in the absence of NOPE indications (TRXDv0 case)
we can still be sure that the burst mask has no gaps due to lost
bursts, because they are compensated by trx_sched_calc_frame_loss().
Change-Id: I56bebe1374eb803e3c1e9f08dda4da50a074ab0b
For both TCH/F and TCH/H, the receive burst buffer needs to be
periodically shifted leftwards due to the nature of block-diagonal
interleaving. Currently we do this on receipt of bid=3 for TCH/F
and bid=1 for TCH/H, right after attempting to decode the buffer.
If for some reason we return early before attempting to decode the
buffer, the content of that buffer might not be shifted and some
bursts might be overwritten. This can be easily avoided by doing
the shifting on receipt of bid=0 for both TCH/H and TCH/F.
Change-Id: I0bd69f5a8f5c665fb5f00c127bc3fe1d91167abb
In the current implementation of both TCH/F and TCH/H lchans, we
set the 'bfi_flag' to true only if decoding fails. Perhaps this
was not the case when I wrote [1], so using meas_avg might result
in using uninitialized memory. This is not the case anymore.
Pass the *averaged* measurememnts regardless of decoding result.
Change-Id: I23f767364a018d30d04885990adf69b50b2c9738
Related: [1] I2b02b51fea5664f161382a4ddc63dbf14ffc9ac5
FACCH/H takes out two speech frames, so we send two BFIs once we
have received it in rx_tchh_fn(). The upper layers responsible
for handling of the Uplink measurements expect a fixed amount of
measurement samples, so currently we do:
* send a FACCH frame with the associated measurememnts (S6N6),
* send the 1st BFI with invalidated measurements (RSSI=0),
* send the 2nd BFI with the stored measurememnts of FACCH.
This is achieved by preserving a copy of the FACCH measurememnts
in chan_state->meas_avg_facch and then using it two bursts later.
The same goal can be achieved a lot easier by sending the associated
measurements with both BFIs as if no FACCH was received:
* send a FACCH frame with invalidated measurememnts (RSSI=0),
* send the 1st BFI with the associated measurememnts (S6N4),
* send the 2nd BFI with the associated measurememnts (S6N4).
This eliminates the need to store anything outside of the existing
measurement history and simplifies the code a lot. Also, this
eliminates the need for using a dedicated averaging mode S6N6.
Varified by running BTS_Tests.TC_meas_res_speech_tchh_facch.
Change-Id: I7902b4709bc3f418174e8373f52e87bb31cdc826
Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
It makes no sense to store BER10k value of an Uplink FACCH frame
in order to indicate it in a BFI later on. Given that these BFIs
are generated artificially, it's fine to indicate BER10k=0.
Change-Id: I24d12892760dca0ad0a5c2abca9fc66523d9e614
Related: I1ad9fa3815feb2b4da608ab7df716a87ba1f2f91
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
This is a purely cosmetic change. The new naming clearly indicates
how deep to go back in the measurement history (S) and how many
samples to average (N). For example:
* SCHED_MEAS_AVG_M_S4N4 - go S=4 steps back and average N=4 samples;
* SCHED_MEAS_AVG_M_S6N2 - go S=6 steps back and average N=2 samples.
Change-Id: I96a8dd08084c7c179f879fc00e75c5edcfb11caa
Set the FT (Frame Type) in the ToC (Type-of-Content) section as
defined in section 5.2 of RFC 5993. Before this change SID frames
had FT = 000 (Good Speech frame), because gsm0503_tch_hr_decode()
does not distinguish between speech and SID frames internally.
Change-Id: I09cec984bb60c754908126acf0300a2cc602485c
Related: SYS#5853
According to RFC5993, which is referenced by 3GPP TS 48.103, the
complete RTP HR payload consists of a Table-of-Contents (ToC) byte
followed by the 14 bytes of the HR codec frame. See section 5.2.
gsm0503_tch_hr_decode() outputs frames in the RTP format with
length of 15 bytes (120 bits): 1 (ToC) + 14 (HR frame):
+-------------+-------------------------
| ToC section | HR codec frame ...
+-------------+-------------------------
osmo_hr_check_sid() expects a HR codec frame of 14 bytes (112 bits)
as the input, so we should skip the ToC section when calling it.
Change-Id: Ie5fa776dcb2b2203a97aed56ecbf2450af7d87c1
Related: SYS#5853
We already have BER10k calculated in the generic code path, so do
not calculate it once again in the FACCH specific branch.
Change-Id: I5d3955d09990e280d11d687385eeaf5edf437395
It makes no sense to perform the SID codeword lookup in signalling
frames (FACCH), because it can be present only in speech frames.
Change-Id: I2f8137993acfe8a8add3fc2af276e5eb4da1605e
Related: SYS#5853
Before a massive refactoring of the scheduler structures [1] it was
impossible to have a clean hierarchy, in which the burst buffers
get allocated as children of their parent timeslot structures.
This change makes it easier to read talloc reports and simplifies
memory management, offloading free()ing of the burst bufferes to
talloc.
Change-Id: Idb1ceaf83c433d2d0eb84d77c2187a00a657905c
Related: [1] I7c4379e43a25e9d858d582a99bf6c4b65c9af481
GSM/EDGE Evolution and Performance, Section 12.3 suggests Temporary
Overpower as another solution to improve SACCH/FACCH performance in
case of bad C/I. The idea here is that you increment the DL transmit
power by 2..4dB only for FACCH/SACCH bursts, while keeping all voice
bursts at the lower (normal) level as determined by BS power control.
SACCH blocks can be recognized by the channel type, since they're
always transmitted in specific frames of a multiframe. FACCH blocks,
however, are not predictable and can substitute voice blocks at
(almost) any time. Thus we need to mark FACCH bursts as such in
the logical channel handlers (using TRX_BR_F_FACCH).
Change-Id: Ie8a626fefccf1eb07271058e5126ec106cb1abcf
Related: SYS#5319
In functions responsible for Downlink burst scheduling, it may happen
that the buffer, containing a complete set of to be transmitted bursts,
a) is not yet allocated or b) was de-allocated intentionally. In this
case, we return early to avoid NULL pointer dereference. The returned
value is then checked against 0 in _sched_dl_burst().
Returning 0 makes _sched_dl_burst() apply per-burst attenuation, as
well as the A5/x encryption (if enabled). And this makes no sense
in either of the cases mentioned above.
Moreover, in the BCCH power reduction mode, this causes some bursts
(bid > 0) of idle PDTCH/PTCCH blocks to be transmitted at full power,
breaking the energy saving feature.
Change-Id: I18aa73cc950fdfac030b63f7a434a71b4596095d
Related: SYS#4919
All generated RTP that originates from the BTS relates to uplink. When
generating AMR BAD frame RTP packets, we must use ul_cmr/ul_ft and not
dl_cmr/dl_ft.
Change-Id: Ifa009819791cf7df2dd8201f442b0dae06f622a4
Related: SYS#5549
The AMR transmission phase directly depends on the frame number. The
transmission phase is used to tell if a received AMR frame contains a
CMI (frame type that is currently used) or CMR (frame type that the
receiver should use) codec identifier. The formulas in the present
implementation seem to be correct but they do not reflect the numbers in
the spec very well, nor do they have unit-tests. Lets replace them with
more readble functions and test those functions with unit-tests.
Change-Id: I94a934a6b3b397b4cd0e9da3577325de58814335
Related: SYS#5549
CMR and FT are updated each time an AMR voice frame is received from the
radio interface. The transmission phase decides whether the voice frame
contains CMR or FT. The code follows the transmission phase and keeps
ul_cmr and ul_ft up to date.
In contrast to the AMR frames on the radio interface, an AMR RTP packet
always contains the CMR and the FT value.
When generating the RTP payloed, The present implementation uses the CMR
in the position where the FT should be and the FT is ignored. This is not
correct.
Change-Id: I6bb10ff3c76f67b9830787497653b546cf27fe8e
Related: SYS#5549
If for whatever reason the transmit queue of a TCH/{F,H} contains
neither speech frames nor signalling blocks, osmo-bts-trx would
currently transmit garbage. Of course, this causes decoding
errors at the MS side.
Ideally, we should employ an ECU (Error Concealment Unit) for the
given codec in use. However, a simpler solution is to transmit
dummy LAPDm frames over FACCH. This is what e.g. nanoBTS does.
Change-Id: I868afecbcb6890f40c8f146e3ce00e836b794dd3
Related: OS#4823
The TSC (Training Sequence Code) value in 'struct gsm_bts_trx_ts'
is always initialized in oml_rx_set_chan_attr() during the OML
bootstrapping, so there is no need for gsm_ts_tsc() - remove it.
Store the initial TSC value in 'struct gsm_bts_trx_ts', so we can
apply a different TSC value during the RSL CHANnel ACTIVation.
Store the Training Sequence Code/Set in 'struct trx_dl_burst_req'.
These values are indicated to the transceiver (TRXDv2 PDUs, 'MTS'
field) and used by the new TRX_{GMSK,8PSK}_NB_TSC macros.
Change-Id: I3744bc308b99ef941e6e9d139444e414abebc14b
Related: SYS#4895, OS#4941
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
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
Vadim Yanitskiy
Mychaela N. Falconia
Philipp Maier
Pau Espin