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
This commit fixes recent previous commit filling in the fn field. The
dl->frame_nr is network order, and we want to pass a host order integer
in the primitive. Use the tm.fn which already includes the proper value
calculated from dl->frame_nr.
Fixes: d524c17d90
Related: OS#3626
Change-Id: Id96015c8b419932abb8095c6cb85aceef34e366f
The pointer and size must given for the SV portion of the character
array only.
Fixes: CID#314049, CID#314048
Change-Id: Ieff4ca886dec71aae1b6ecf2b623d600426580da
During initial GMM Attach, the GMM layer generates an internal
local TLLI and uses it to do the GMM Attach. Only at the time it
receives the GMM Attach Accept with the assigned TLLI from the network
then explicitly informs other layers about the TLLI update.
Hence, the GMMREG user doesn't really know about the TLLI in use until
the GMM Attach success happens (gmmreg-attach.cnf).
During that time, the TLLI at the app is basically unassigned
(0xffffffff). Hence, during that same time a TLLI update hook in
GMMRR-Assign.req will not work since the app is unaware of the remporary
local TLLI, so no match can be done.
In that specific scenario, that's fine, since anyway it is waiting to
receive the GMMREG-Attach.cnf, which will indicate the assigned TLLI to
it.
In summary, not being able to match the TLLI in GMMRR-Assign.req is not
bad per se, so soften the log error there.
Change-Id: I31c04288789393391084000fbdbcdcedb11d0b68
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
Right now the existing code is switching to state IDLE and hence running
grr_st_packet_idle_onenter() which attempts stuff like starting an attach.
This is all done while the L1CTL RESET + FBSB is still in progress. We
should instead wait to receive confirmation from those.
As an easy implementation for now, simply switch to the
GRR_ST_PACKET_NOT_READY state, which will move to GRR_ST_PACKET_IDLE
once it starts receiving CCCH blocks (aka it will already have gone
through L1CTL RESET + FBSB completely).
Change-Id: Ie797b36701d10c6052500c637a08b061bb1e4bd7
Signal RLC/MAC layer that the lower layers is in packet idle mode ready
to use CCCH (such as packet-access-procedure).
Change-Id: I05050e840a3b267b3b3a278588ee113b45bfbd4c
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
This is needed in order to provide updated TLLI when submitting new user
data from the tundev to the SNDCP layer.
Change-Id: I5c6a2c371ae6d65bf4fe23e665ec939da37112be
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
We need to distinguish between Uplink and Downlink TBF assignment in
grr_rx_imm_ass(), because matching the Request Reference IE makes
sense only for the Uplink TBF assignment.
Uplink TBFs are requested by the UEs by sending RACH, while Downlink
TBFs are assigned by the network itself. The Request Reference IE
is only valid for Uplink assignments and shall be ignored in messages
assigning Downlink TBFs.
Change-Id: Idb9b3203147be3b42256c0bcab3ecdabcf2d2fa9
Related: OS#5500
In change 67943df4 I broke handling of the logging category mask in
the mobile app. Adding this option results in a segfault:
ERROR: osmo_log_info == NULL! You must call log_init() before
using logging in log_parse_category_mask()!
Assert failed osmo_log_info src/libosmocore/src/core/logging.c:329
As can be seen, the problem is that we are calling
log_parse_category_mask() before initializing the logging.
As possible solution, I could rearrange the code to parse command
line options after calling osmo_init_logging2(). This would fix
the segfault, but would not fully solve the problem.
If we call log_parse_category_mask() before parsing the config file,
then logging configuration in the config file overwrites the logging
configuration specified via the command line. But we want the
opposite: the command line setting should overwrite the config file
parameters. This is handy because there is no need to edit the
config file if you quickly need to test something.
So let's call log_parse_category_mask() after parsing the config file.
Change-Id: I1b2b7804bf99b71f96e9197f7824cfd20431e8a1
Fixes: 67943df4 "layer23: fix parsing of command line options"
libosmogsm has recently deprecated the use of osmo_auth_gen_vec
and the osmo_sub_auth_data structure in favor of newer versions
of this API. Let's migrate to it
Change-Id: I1d9751c5f74a59e7310d07d54a3fdbac213324bd
Depends: libosmocore.git Ie775fedba4a3fa12314c0f7c8a369662ef6a40df
Found by clang:
gsm48_cc.c:54:6: warning: logical not is only applied to the left
hand side of this comparison [-Wlogical-not-parentheses]
if (!cc->mncc_upqueue.next == 0)
^ ~~
Change-Id: Ic7ffd3aa25339e24a31bae1b7428f1f93e261858
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
For the sake of simplicity and due to some performance limitations,
fake_trx.py does not generate TRXD NOPE indications for osmo-bts-trx
on its own. It's actually trxcon sending NOPE.req (empty Tx PDUs)
when it has nothing to send, and fake_trx.py simply converting them.
In a follow-up change [1] we remove trxcon's internal clock module,
making the Uplink burst scheduling being driven by Downlink bursts
with the respective TDMA Fn/Tn values. Given that fake_trx.py is
currently dropping bursts received for inactive timeslots, we would
get NOPE.req only for a single timeslot, the one being currently
active. This would break several testcases in ttcn3-bts-test.
Remove SETSLOT based burst filtering, so that trxcon would still be
able to generate NOPE.req for all, active and inactive timeslots.
Downlink bursts for inactive timeslots are discarded anyway.
Change-Id: Ia42550d5c2d8b49efbdf8ef0ce46b26afd1c464e
Related: [1] 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
Unconditionally forward PTCCH/D blocks towards the upper layers.
Calling l1gprs_pdch_filter_dl_block() on them makes no sense.
Change-Id: Ifcc53d442426c8bfdacd3d179e20bb45c43f4644
Fixes: BTS_Tests.TC_pcu_ptcch (DL part)
Related: OS#5500, OS#5955
Pau Espin
Vadim Yanitskiy
Andreas Eversberg
Harald Welte