... in the absence of valid Uplink TCH/A[FH]S or FACCH frames.
Change-Id: I26205e8672cb2849ea79bd6206c1eff1172bd9d9
Related: libosmocore.git I82ce2adf995a4b42d1f378c5819f88d773b9104a
Related: OS#6049
In tx_pdtch_fn(), delay sending DATA.cnf until bid=3. Otherwise we
send it too early (at bid=0) and trick the upper layers (RLC/MAC)
to believe that the whole block (all bursts) has been transmitted.
Change-Id: If32fafeef0ea347ed3800e6b67349bf12e66047f
In accordance with 3GPP TS 44.021, sections 8.1.6 and 10.2.3, the
transmission of idle frames to the DTE is mandated when no data is
received from the radio interface. An idle frame has all data,
status, and E-bits to binary '1' (excluding the alignment pattern).
This requirement is currently implemented by osmo-bts for the Uplink,
and is going to be adopted for the Downlink (see the related patch).
This patch brings trxcon/l1sched in sync with osmo-bts-trx.
Change-Id: I7dea3dde46bc02814e99c3e873298cc7ed045a51
Related: osmo-bts.git I0b25cfac41b6d8dcf3bfd9d46d51a9665f1b047a
Related: OS#1572, OS#4396
When an UL BLOCK.req is received late, i.e. after the first Tx burst
of the respective TDMA Fn was requested by the PHY, a domino effect
can be observed: the stale Tx primitive remains in the queue and
prevents transmission of the next primitive, even if the later was
received in time. This breaks transmission of consecutive UL blocks.
Don't let stale primitives poison the Tx queue: drop them like before,
but keep looking for a primitive with the matching TDMA Fn. If found
a primitive with TDMA Fn past the current one, stop the iteration.
Change-Id: I439615639b8e840b9fd4f3af6934d9f298f32216
Depends: libosmocore.git I9590f2e836fc48650decf1564b6ab46306c4fe2d
Depends: libosmocore.git Ie8bb9c49c6f81b8f4a1766547d6943f9880d1186
Related: OS#5500
Before this patch, the RTS:ind was crafted up in the stack when
receiving the DL_BLOCK.ind. This created some problems since the
internal low level state has to be updated in between signalling
DL_BLOCK.ind and RTS.ind, as there's a fn-advnace of one block between
those 2 signals (hence the timeslot allocation has to be applied at the
time when the fn-advance is applied).
This is actually not fixing the whole issue, since there's several
timeslots and hence the following events will have the internal timeslot updated
during the event in the middle, hence potentially causing problems in the
remaining TS:
DL_BLOCK.ind(FN=N, TS=1), RTS.ind(FN=N+4, TS=1), DL_BLOCK.ind(FN=N, TS=2)
In any case, this decoupling already improves the situation and is step
needed anyway towards fully fixing the problem (by, for instance,
maintaining a timeslot state duplicated both for DL and Ul directions,
since they drive based on differnet FN time (1 PDCH block).
Change-Id: I1494e0aac7555f6e01b4b435b77140afc42c098e
This patch adds support for TCH/[FH]2.4, TCH/[FH]4.8, TCH/F9.6 and
TCH/F14.4 (including FACCH). Additional changes made:
* enlarge the maximum TCH burst buffer size to 24 * (2 * 58) bytes;
* enlarge per-l1cs UL/DL burst masks to hold up to 32 bits;
* enlarge per-l1cs DL meas ring buffer to 24 entries;
* enlarge L1SCHED_PRIM_TAILROOM from 256 to 512 bytes;
* enlarge L1CTL_LENGTH from 256 to 512 bytes;
Change-Id: I0d7389a9a5f7019b9316ab1c0115797ff54a0e41
Depends: libosmocore.git Ib482817b5f6a4e3c7299f6e0b3841143b60fc93d
Depends: libosmocore.git I0c7a9c180dcafe64e6aebe53518d3d11e1f29886
Depends: libosmocore.git I4685376c8deb04db670684c9ebf685ad6fc989fa
Related: OS#4396, OS#1572
trxcon's scheduler is currently emitting DATA.cnf whenever the last
burst of a DATA.req has been transmitted. This sounds logical, but
makes the implementation quite complex. It's even harder to implement
sending of DATA.cnf properly for CSD specific channel modes, which are
to be implemented in a follow-up patch.
The DATA.cnf prims trigger sending of L1CTL DATA.cnf/TRAFFIC.cnf,
which are interpreted as Ready-to-Send by the upper layers (layer23).
Additionally DATA.cnf prims trigger sending of GSMTAP PDUs containing
the respective Uplink frames.
This patch changes the l1sched logic, so that a DATA.cnf primitive
is emitted whenever the respective DATA.req is dequeued and encoded
using the lchan specific channel coding function. This simplifies
the code a lot and prepares for the upcoming CSD support.
As a bonus, this patch fixes an inconsistency between TDMA FNs reported
in Uplink and Downlink GSMTAP PDUs. Now we're indicating the first Fn
in both cases, so Uplink is consistent with Downlink.
Change-Id: Ie09a24cd950a93edd871a9fbc5b47ec96c24cceb
Related: OS#4396, OS#1572
This works-around a race condition happening when the upper layers
are sending L1CTL RESET.req immediately followed by L1CTL FBSB.req.
The problem is that the TRXC logic is considering the transceiver
powered on until a response to CMD POWEROFF is received.
Change-Id: I967ce047eb198f1eaf8446bb4c1f87a98d3de264
Related: OS#5500
In case when an Uplink TCH/[FH]S frame needs to be transmitted, but
there is no frame available in the Tx queue, transmit an intentionally
invalid block with inverted CRC3. This will induce a BFI condition in
the BTS side receiver. See also the related osmo-bts-trx patch.
Change-Id: I16ff09a220da13c2c76538bc43354afc4e688794
Depends: libosmocore.git Iade3310e16b906efb6892d28f474a0d15204e861
Related: osmo-bts.git I78106802a0aa4af39859c75d29fe0e77037899fe
Whenever decoding fails or a FACCH setaling happens, simply send an
empty DATA.ind to the upper layers. On the Uplink path, use a dummy
LAPDm func=UI frame (with random padding) whenever possible.
Crafting TCH frames with zeroes is not really needed and moreover makes
it hard to distinguish between valid speech frames and BFIs. This also
used to be the case for osmo-bts-trx, but not anymore (see the related
patch).
Change-Id: I20391b860fbc2ce8f0f03d7ba95ef7a098c0f9db
Related: osmo-bts.git I8f9fb5b8c5b2cad4b92ac693c0040779f811981a
Unlike FACCH/F, which steals one TCH frame, FACCH/H steals two TCH
frames. This is what prim_dequeue_tchh() aims to implement, but
the current implementation is not 100% correct.
The problem is that we're attempting to dequeue and drop two TCH frames
in one go, whenever we get a FACCH/H frame. Most likely, there will be
no 2nd TCH frame in the Tx queue at that time, so it will never be
dropped and will clog the queue.
Let's replicate what osmo-bts-trx does:
* dequeue and drop the 1st TCH frame when sending 1st/6 burst of FACCH,
* dequeue and drop the 2nd TCH frame when sending 3rd/6 burst of FACCH.
Change-Id: I513d6805ddf97783c002be285fb3ca7893e42377
Related: OS#4396, OS#1572
Centralized dequeueing of Tx prims in l1sched_pull_burst() is a working
approach, but doing this in each logical channel handler individually
is a lot more flexible. This is how it's done in osmo-bts-trx, and
this allows implementing FACCH support for CSD channels.
Change-Id: I3d6c2136ff1855ab0aa9062b20b2a64fd0e5fe28
Related: OS#4396, OS#1572
In ad8f7794 I changed both tx_tch[fh]_fn() to use a switch statement
and introduced a regression by removing special treatment of FACCH:
@@ -238,10 +237,16 @@ int tx_tchf_fn(struct l1sched_lchan_state *lchan,
- if (msgb_l2len(lchan->prim) == GSM_MACBLOCK_LEN) {
- /* Encode payload */
- rc = gsm0503_tch_fr_encode(buffer, msgb_l2(lchan->prim), GSM_MACBLOCK_LEN, 1);
- } else if (lchan->tch_mode == GSM48_CMODE_SPEECH_AMR) {
@@ -459,10 +458,15 @@ int tx_tchh_fn(struct l1sched_lchan_state *lchan,
- if (msgb_l2len(lchan->prim) == GSM_MACBLOCK_LEN) {
- rc = gsm0503_tch_hr_encode(buffer, msgb_l2(lchan->prim), GSM_MACBLOCK_LEN);
- lchan->ul_facch_blocks = 6;
- } else if (lchan->tch_mode == GSM48_CMODE_SPEECH_AMR) {
Now if the channel mode is GSM48_CMODE_SPEECH_AMR, UL FACCH/[FH] frames
will be fed to osmo_amr_rtp_dec(), which is definitely wrong. Fix this
by doing all AMR specific checks in a separate function, which is
called only for speech frames.
Change-Id: Ie217bbb389b5abb95d241781ffe3f5c7b1c188c0
Fixes: ad8f7794 "trxcon/l1sched: remove redundant TCH/[FH] prim length checks"
Related: OS#4396
The idea behind advancing Uplink TDMA Fn is to give the transceiver,
which is usually a separate process, some additional time to receive
and prepare Uplink bursts for transmission. This comes at a price
of having an additional delay between Uplink and Downlink.
Given that trxcon, as a standalone application, is primarily used in
conjunction with fake_trx.py for running ttcn3-bts-test against
osmo-bts-trx, there is no reason to advance the Uplink TDMA Fn.
Change-Id: I838b1ebc54e4c5d116f8af2155d97215a6133ba4
Related: OS#5500
trxcon was heavily inspired by osmo-bts-trx, and among with many other
scheduling related parts also inherited the timer driven clock module.
This clock module is driving the Uplink burst scheduling, just like it
does drive the Downlink burst scheduling in osmo-bts-trx. Just like
in osmo-bts-trx, the clock module relies on periodic CLCK indications
from the PHY, which are needed to compensate for the clock drifting.
The key difference is that trxcon is using Downlink bursts as the CLCK
indications, see 'bi.fn % 51' in trx_data_rx_cb(). This is possible
because the MS is a clock slave of the BTS: the MS PHY needs to sync
its freq. and clock first, and only after that it can Rx and Tx.
So far we've had no problems with the clock module in trxcon until we
started adding GPRS support and integrated the l1gprs. While the CS
domain is quite flexible in terms of timings and delays, the PS domain
is a lot more sensetive to the timing issues.
Sometimes it happens that the trxcon's clock module is ticking quicker
than it should, resulting in Uplink PDCH blocks being scheduled earlier
than the respective Downlink PDCH blocks are received:
20230502021957724 l1sched_pull_burst(): PDTCH/U Tx time (fn=56103)
20230502021957744 (PDCH-7) Rx DL BLOCK.ind (fn=56103, len=23): ...
20230502021957747 l1sched_pull_burst(): PDTCH/U Tx time (fn=56108)
20230502021957765 l1sched_pull_burst(): PDTCH/U Tx time (fn=56112)
20230502021957767 (PDCH-7) Rx DL BLOCK.ind (fn=56108, len=23): ...
20230502021957768 (PDCH-7) Rx UL BLOCK.req (fn=56112, len=54): ...
20230502021957784 l1sched_pull_burst(): PDTCH/U Tx time (fn=56116)
20230502021957784 TS7-PDTCH dropping Tx primitive (current Fn=56116, prim Fn=56112)
This is impossible in reality, because Uplink is intentionally lagging
behind Downlink by 3 TDMA timeslot periods. In a virtual setup this
causes sporadic dropping of Uplink PDCH blocks, as can be seen from
the logging snippet above, and significantly degrades the RLC/MAC
performance for GPRS.
Let's remove the internal clock module and trigger the Uplink burst
transmission each time we receive a Downlink burst. This helps to
overcome the GPRS scheduling issues and replicates the approach of
osmo-trx-ms more closely.
Change-Id: Ic8a5b6277c6b16392026e0557376257d71c9d230
Related: OS#5500
The PTCCH/U primitives are basically Access Bursts. The TDMA Fn in
such primitives is always 0, because there's currently no way to
indicate TDMA Fn in L1CTL_RACH_REQ (only the offset).
Change-Id: I54ba9b5d9c3eba4aeabf9ed6fcf1e8d09f21cce1
Fixes: BTS_Tests.TC_pcu_ptcch (UL part)
Related: OS#5500, OS#5955
This is how the buffer shifting is implemented in osmo-bts-trx. Keep
trxcon's l1sched implementation as close to osmo-bts-trx as possible
in order to simplify the integration of CSD support.
Change-Id: Idb6e415f37f41b8ab92a3864962dac0a40c2fbaa
Related: OS#4396
This is no longer needed thanks to recent patch b0be904b.
Change-Id: Ia397cbe16f719729a814b7ef0b7035c7fe8ba165
Related: b0be904b "trxcon: do not call l1sched_prim_dequeue() at ul_bid != 0"
In ad8f7794 I introduced a regression by removing the line setting
lchan->ul_facch_blocks, breaking transmission of Uplink FACCH/H.
Change-Id: I4f2bbbd30c7d5dbb979b54455561df3c0cc12aac
Fixes: ad8f7794 "trxcon/l1sched: remove redundant TCH/[FH] prim length checks"
This is a more effecient way to check if FACCH/H is allowed. The
mapping was added in a53e93fe9 and is already used for AMR.
Change-Id: Ib4b409956326480679a436d28224b539d00779e2
Related: a53e93fe9 "trxcon: Initial support for forwarding AMR"
Related: OS#4396
Both gsm0503_tch_[fh]r_encode() do check the given payload length in
order to determine the payload and/or codec type. The same applies
to gsm0503_tch_a[fh]s_encode(). There is no real need to implement
additional length checks on top of that - drop them.
Change-Id: Ib1adf4945fb762bc2a51a1008f6bef6784fb7833
Related: OS#4396
When running trxcon with GSMTAP Um logging enabled (-g cmd line arg),
in handle_prim_rach_cnf() we msgb_put() one or two bytes to the given
msgb. This causes a segfault, because the L1SCHED_PRIM_T_RACH prims
have 0 tailroom bytes available.
While we could allocate L1SCHED_PRIM_T_RACH with a few extra bytes,
a more fundamental approach is to allocate all l1sched primitives with
a fixed tailroom.
Change-Id: Ica87b147e11744a69dcd7c056376dcf6b98f9ca6
Fixes: ff9db9de "trxcon/l1sched: rework the primitive API"
Related: OS#5500
It may happen that the Tx queue is empty at TDMA Fn corresponding to
ul_bid == 0, and then shortly after something appears at ul_bid != 0.
The lchan Tx handlers call the encoding functions from libosmocoding
only at bid == 0, so dequeueing at ul_bid != 0 makes no sense.
Change-Id: Ic0bbe2ab6c0ccd96c1f8af8aa17ac88adf7f88ed
Related: OS#5500
The logging in trxcon is initialized by calling osmo_init_logging2(),
which creates an stderr target in *blocking* mode. Blocking write()s
may cause random burst scheduling delays (due to the whole process
being stuck). This is not desired and becomes even more critical
when operating in PS doman, which imposes strict timing requirements.
trxcon does not have its own VTY interface yet, so there's currently
no easy way to switch to non-blocking mode like in other osmo-apps.
Let's enable it by default in trxcon_logging_init().
Change-Id: I8cbfd9b4644f8442cbedc7e452ba79816923fc10
Related: OS#5500
The goal is to simplify primitive management, and allow passing data
between different components without having to re-allocate memory and
copy it over several times. This patch has been tested by running
ttcn3-bts-test, no regressions observed.
* Use msgb and prim API from libosmocore,
* Move l1sched_prim definitions to its own header file,
* Move Tx queue from per-timeslot to per-lchan state,
* Route prims via l1sched_prim_{to,from}_user() functions,
* Remove GSMTAP stuff from sched_lchan_desc[].
Change-Id: I73576bd0ea10a5663ba6254283812c275cc3fa46
Related: OS#5500
An upcoming patch will add a similar function taking chan_nr/link_id
as the search criteria, so let's clarify the existing API first.
Change-Id: Ib9f733c22d7fc6bd933219906ca680f246b07f4b
Related: OS#5500
Make it clear that this function operates on a logical channel.
Also take a chance to remove redundant comments and ws.
Change-Id: I0517bba2be5403d437d3879b2332196d872e11f2
Related: OS#5500
We shall never be transmitting Uplink PDCH blocks if the current
TDMA Fn does not match the requested TDMA Fn, because Tx timing
is critical for PDCH timeslots. Drop and log an error message.
Change-Id: I6b2d9cc93ce266524f56a1b6a97beecfc0ad042d
Related: OS#5500
Unlike the other more mature Osmocom projects, trxcon does not have its
own VTY interface and thus does not support the config file parsing,
so currently it's impossible to configure additional logging targets.
There is a command line option '-g', which enables GSMTAP Um logging.
Let's also add a GSMTAP logging target if it's given. This is a quick
hack, but good enough for occasional debugging.
Change-Id: I2c5e630dd508dff12d0116bdc0a4cc1276cac5ed
Related: OS#5500
The event TRXCON_EV_TX_DATA_CNF is not premitted in state
TRXCON_ST_PACKET_DATA, and is not of any use for l1gprs.
Change-Id: Iee5ee404f1eb77091c388a641d0a78d01a8d7e7f
Related: OS#5500
Vadim Yanitskiy
Pau Espin